Django: vibrant community and future? [closed] - python

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I'm in that horrible questioning state. I'm trying to decide between Django and Rails.
From what I've read, Django probably fits my needs better, both from a "cultural" and goal point of view. The baked-in admin interface pretty much sells me alone. However, I have one critical concern: it looks like the Rails community is much larger. This could be a plus OR a minus; read on.
I have experience hanging my hat on a technology that does not have as vibrant a commmunity as its "competitor." I run a Mac consulting firm in the Bay Area. Up until very, very recently (like the last year!), finding resources for very difficult issues (especially server- and network-related) was so difficult that it was often not even worth trying. This is now changing rapidly due to the Halo Effect, but if it wasn't for Steve Jobs' return to Apple and the iPhone, the future would look just as bleak as the past.
So, while Django looks awesome, I am concerned about pigeonholing myself in yet another niche. I'm less concerned with my theoretical job prospects as a Django developer (I like my job) than I am with simply having resources available to create and maintain cutting-edge projects that can evolve with the Web, and not lag too far behind.
From the above point of view, it looks like Rails has the advantage. However, here's a problem I've noticed that seems to come from the vibrancy of the Rails community: Want to accomplish a particular Rails programming task you've never done before? Google it; you'll find three to six+ different plugins, each with as many advocates as detractors. How do you decide which to use without spending hours and hours learning and prototyping? How do you know that the one you choose won't be end-of-lifed in 12 months, and you'll have to redo that part of your app in order to stay current with the latest Rails distribution?
My latter point brings me right back to where I started: Django seems like a time-saver. Except now I have two reasons to think so, not just one.
I should mention that I've already spent a significant amount of time learning Ruby and Rails, dabbled a bit in Python, and quite prefer Ruby.
Would love your thoughts.

If the size and the vibrancy of the community is the main problem, than maybe you should look at other framework stacks not just Django and Rails (those two make allot of noise and hype, but there are other much more bigger that don't get that loud - e.g. Java/JVM based framework stacks have users in a few order of magnitude higher than those two you mention).
If the game however is just between these two, when I would decide, I would take in consideration especially the available tools (how good the IDE support is) - at least for me they're very very important, since they're what make a productivity difference.
Even if on the Mac the hype is of course TextMate, with all the respect, that is just an advanced editor - not an IDE with "smart" features like error highlighting in code, smart and correct completion, etc.
The smartest existing IDE for Rails is RubyMine, so considering that for Python (Django) there's nothing not even close that advanced, I would choose Ruby on Rails even for this just only reason. Of course, another plus point for RoR is the bigger number of books available (so when in doubt, I have better chances to find a solution in one of them).

What about Pylons?

From what I have seen neither one looks like it will become a niche any time soon, both have active communities and dedicated developers. Ruby and python are both great languages, and both are being actively developed as well. At some point Django will have to migrate from python 2.x to 3.y, which may be a little bit painful, but the same sort of thing can be expected from rails at some point in the future.
I think you have narrowed it down to the right two for being main stream yet not stagnant. They both have advantages and disadvantages, and if there isn't a clear reason to chose one or the other for your project, I would say go with the language you prefer. Python is my language of choice, so baring some killer reason to chose RoR, Django is the natural way to go to continue developing the way I like to. If you prefer ruby, I would recommend going with RoR unless Django seems to fit your application in a way RoR does not.

Related

Python - Is it worthwhile to invest time in apparently stagnant modules? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
To make it quick and dirty - I'm a newb programmer who's looking hard at Pyglet, it looks like a really clean and friendly module to use, unlike something like PyGame which is, even by looking with my own inexperienced eyes, a beast.
However. PyGame is constantly being used, updated, reused by lots of people and seems to have quite a following. Pyglet hasn't been updated since January 2010. Most works of art are never finished, only abandoned - but two years and it's still on v 1.1.4 seems troubling.
So while I might be specifically asking about Pyglet vs. PyGame, I'm also not, because it leads me wonder about other ghostly modules that might be lurking out there, that had promise once upon a time but, for some reason, got dropped or shoved in a corner and aren't really relevant. Are such abandoned projects not worth the time and brain-space investment?
as the owner of a "dormant" package, my own take is:
a more popular package is going to have better support from the community. for many people i think this overrides any other consideration. it's often better to have support for a mediocre package than battle with an awesome package no-one else is using.
and it may well be popular because it's better. obviously i am biased towards the underdog (see above) here, but it has to be said that if a package never gained many users, perhaps it wasn't a good match to the market.
BUT
if the package is mature and working, and it does what you want, why not use it? especially when open source means you can fix bugs yourself, forking if necessary.
so, it depends. all other things being equal - use the popular choice. if you need support - use the popular choice. but if a package happens to exactly scratch an itch, and it's open source and out there, i would still consider it.
important qualification: this is for personal projects - for work i have a responsibility to use popular projects so that others can support the code i have written.
python specific rider: one additional thing to worry about is python 3 support. if a dormant package is stuck on python 2 i would think twice because long-term there's a real chance it will stop working on default python installs.
The answer from andrew-cooke is spot on, but I just wanted to mention that I've been using Panda3D and highly recommend it as an alternative.
It has fantastic documentation, good performance, and a nice community of users that are willing to help on the forums and IRC. It's also still in active development, with version 1.8 nearing release.
To paraphrase Monty Python
No no he's not stagnant, he's, he's restin'!
Open source maintainers move on or get busy with other things. If you feel Pyglet is a good choice for your application create a clone of the repo, put your changes up on insert code hosting flavor of the month, and get some work done. There are benefits to having a community to ask for help or fix bugs.
However, if something is open source and a good fit for your project the lack of a maintainer should be seen as an opportunity and not a problem.
Though perhaps not as active as Pygame, Pyglet is not entirely stagnant. Look at the recent commits and you'll see there are still a number of contributors, and several commits as recently as 4 days prior to time of writing.
It's true that there hasn't been an official release for a while though, and despite some lengthy discussions about a 1.2 release, obviously nothing has happened yet.
The accepted answer is certainly still spot on, but thought this was worth a mention at least.
In this case, PyGame and Pyglet are orthogonal.
PyGame is a wrapper around the SDL C++ library, which does everything game related except 3D rendering. (Does pyGame do 3d?) Pyglet is a wrapper around OpenGL, which does only 3D rendering.
So, PyGame lets you do things like capture controller input, load textures out of files, and play sounds. However, graphics are very primitive because it is unable to leverage GPU. Pyglet will let you render on the GPU, but won't help with any of that non-performance critical fiddly stuff that PyGame handles.
They are perfect to use together.

Python vs all the major professional languages [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I've been reading up a lot lately on comparisons between Python and a bunch of the more traditional professional languages - C, C++, Java, etc, mainly trying to find out if its as good as those would be for my own purposes. I can't get this thought out of my head that it isn't good for 'real' programming tasks beyond automation and macros.
Anyway, the general idea I got from about two hundred forum threads and blog posts is that for general, non-professional-level progs, scripts, and apps, and as long as it's a single programmer (you) writing it, a given program can be written quicker and more efficiently with Python than it could be with pretty much any other language. But once its big enough to require multiple programmers or more complex than a regular person (read: non-professional) would have any business making, it pretty much becomes instantly inferior to a million other languages.
Is this idea more or less accurate?
(I'm learning Python for my first language and want to be able to make any small app that I want, but I plan on learning C eventually too, because I want to get into driver writing eventually. So I've been trying to research each ones strengths and weaknesses as much as I can.)
Anyway, thanks for any input
An open source project I work on for VCS integration (RabbitVCS) is written entirely in Python/PyGTK and includes:
Two file browser extensions
A text editor extension
A backend VCS status cache running asynchronously, using DBUS for the interface
A fairly comprehensive set of dialogs, including VCS log browsers, a repository browser and a merge wizard (maybe that one isn't such a selling point).
There's no standalone app, but we're thinking about it.
Because we're always adding new features, and currently trying to adapt to new VCS', Python is ideal for the ability to quickly refactor entire layers of code without breaking our mental flow. I've also found that the syntax itself makes a real difference with complicated merging of version controlled branches, but that might come with the ability to read it quickly.
Recently we've begun adding support for a new VCS, requiring:
refactoring current code to separate VCS specific actions and information from common/generic information
refactoring the UI layer to accomodate the new functionality
Most of what we've achieved has been possible because of the availability of C/Python bindings (eg. PySVN, Nautilus-Python, etc). But when it hasn't been available... well, it's not that hard to roll your own (as a developer did for the new VCS). When the bindings lack functionality... it's not that hard to add it.
The real drawbacks so far have been:
Threading mishaps. Lesson learnt: forget about threads, use multiple processes where possible or your toolkit's threading method (eg. PyGTK, wxPython and Twisted all have their own ways of dealing with concurrency)
(C) Extensions. Cause threading mishaps (they almost invariably lock the GIL, preventing threading). See above.
Needing to hack on C bindings when certain functionality is unavailable.
Profiling can be tricky when you're not just doing something based on a single function call.
If you want to know about more specific aspects, ask away in the comments :)

A business Case for Enterprise Python [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
This will not be a "programming" question but more technology / platform related question. I'm trying to figure out whether Python can be a suitable Java alternative for enterprise / web applications.
Which are the ideal cases where you would prefer to use Python instead of Java? How would a typical Python web application (databases/sessions/concurrency) perform as compared to a typical Java application? How do specific Python frameworks square up against Java based frameworks (Spring, SEAM, Grails etc.)?
For businesses, switching from the Java infrastructure to a Python infrastructure .. is it too hard/expensive/resource intensive/not viable? Also shed some light on the business case for providing a Python + Google AppEngine based solution to the end customer. Will it be cost effective in an typical scenario?
Sorry if I am asking too wide a question, I would have liked to keep it specific, but I need your help to evaluate Python as a whole from the perspectives of the programmers, service providing company and end business customer.
For an SME, a Python/GoogleAppEngine based technology stack is a clear scalable and affordable platform. But what about a large MNC that already has a lot invested in Java.
Thank you so much. I am researching this myself and will gladly share my conclusions here!
Thank you,
Srirangan
An enterprise that already has a terabucks of Java investments should add jython to their mix of technologies -- it can be adopted gradually and progressively, at first for ancillary functions such as testing, "one-off" data migrations &c, prototyping of new functionality, cases in which using some existing open source Python library is obviously very handy, and so on, and so forth -- then, as the many Java developers in the company learn to use Jython, some of the prototypes will just be put in production as Jython code because there would be no advantage recoding them, some old subsystem needing recoding will be recoded in Jython, and so forth.
It's never really a wise decision to throw away a huge existing and working codebase and the ginormous investment it represents -- Python's strengths include its wealth of strong, production-level implementations, how well they "play with others", and how well Python can gradually and incrementally infiltrate most any development shop.
The larger your investment in an existing technology is, the more expensive it is to move away from it. COBOL is perhaps the best example here.
That investment isn't just in porting existing solutions, but also in retraining or hiring new staff so that you have the skill sets to build and support the new technologies even while still maintaining your legacy solutions.
Add to that the fact that for most large Multinational Corporations, software isn't their core business. As long as it functions effectively and fulfills the business need, they don't tend to care so much about the 'details'.
You need to be able to offer some pretty compelling benefits to overcome this kind of inertia.
Sad but true.
If you need to do the sort of things you can do with Django, then Django and Python is totally what you want. Google App Engine runs Django as well. So, you can do a Django app and host it on Google App Engine, and later change your mind and switch to conventional server hosting, or self-hosting if you have your own server.
I haven't tried Google App Engine but my understanding is that the price is quite reasonable for what you get. Google's IT department does a great job of keeping their data centers going; if you outsource the hosting to Google App Engine you know your data is backed up, you know the servers won't go down, and even if a backhoe takes a whole Google data center off the Internet, some other Google data center will keep serving up your application to your customers. You also know that if your application suddenly becomes hugely popular, Google App Engine wil l scale up automatically to handle the load. (I think you set a cap for the maximum you are willing to pay, and it scales until it hits the cap. But as I said I haven't used it and I'm not certain.)
I haven't used Java yet, but from what I have seen of it, Python is a much more expressive language and skilled Python coders can get more work done in a day just because the language is that much better. However, if you already have invested in Java and have in-house expertise in Java, you would be crazy to walk away from that overnight. The correct thing is to pick one new project to just try out that crazy Python thing.
And I really do recommend Django. You can get the Django book and try out the tutorial. If your first pilot project in Python is a Django project, you should have an easy time of things.
The answer to your question is yes. Python can be well suited for Enterprise because python is a language which has raw power, flexible and can be glued with other programming languages. What enterprise really requires is a language which does everything and i feel python is already enterprise ready. If you want examples then i believe there can be no bigger example than google. Google is running python internally and externally for its business critical applications. The only problem with python is that it is not very well recognized by top MNC company and we as a python programmer find hard time convincing the management team. I guess you will face the same issue. But i guarantee you once you get your feet wet in python, you will understand its true power
There is -- almost -- no usable "Business Case" for any technology choice.
"what about a large MNC that already has a lot invested in Java" Ask around. See if there's a business case for Java.
I doubt you'll find anything. Most companies drift into technology choices slowly.
There was no business case for COBOL -- it was the only game in town in the olden days.
There is rarely a business case for Java. What usually happens is that some visionary individual started building the first web site (probably in Perl). The "web thing" gained traction, and some vision individual started building web sites in Java. Eventually, the success of those small teams indicated to others that Java had advantages over COBOL.
Managers say the words "make a business case", but watch what they actually do. They listen to (1) their peers, (2) successful people.
To make the "business case" for Python, you have to be that visionary individual.
1) Use Python.
2) Be successful.
3) Share your successes.
4) Be prepared to explain that your success is due to your tools, not your personal level of genius and charisma.

How do you make a case for Django [or Ruby on Rails] to non-technical clients [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Businessmen typically want a web application developed. They are aware of .net or J2EE by names, without much knowledge about either.
Altho' Rails and Django offer for a much better and faster development stack, it is a big task to convince businessmen to use these platforms.
The task begins with introducing Django (or Rails), quoting some blog/research. Then making a case for the use of the framework for the specific project.
Lot of the task is repetitive. What are the sources/blogs/whitepapers and other materials you use to make a case for django (or Rails)
Don't you think there should be a common brochure developed that many development agencies could use to make the same case, over and again. Are there any such ones, now?
There seems to be enough discussion on Django vs Rails. Whereas the need is (Django and Rails) vs (.net and J2EE), at least so, while making a business case. Both represent a faster pragmatic web development in a dynamic language.
It's easier to ask forgiveness than permission.
First, build the initial release in Django. Quickly. Build the model well (really well!). But use as much default admin functionality as you can.
Spend time only only reporting and display pages where the HTML might actually matter to the presentation.
Show this and they'll only want more. Once they've gotten addicted to fast turnaround and correct out-of-the box operation, you can discuss technology with them. By then it won't matter any more.
You need to speak the language of business: money.
"If we do it Rails, it will cost you 50% less than the same functionality in Java."
Your percentage may vary, and you might need to also include hosting and upkeep costs, to show how it balances out.
When you're convincing other programmers, sure, talk about development speed and automation of repetitive tasks. But talk bottom-line cost to a business person.
Before you begin making the case for Django or Rails, you have to be convinced it's the right stack first in the context of the business person's needs. If the business person is an entrepreneur, he may have other factors that go beyond how quickly can the solution be developed. For example:
If its an enterprise play that's being developed (something like SalesForce.com, SugarCRM, etc.) it may make sense to have it written in Java because this makes acquisitions and mergers easier with potential Java-based suitors.
If its an internal IT play for a custom solution in a large company, they may already have a significant amount MS infrastructure in place. It may not make sense to have your client install SQLServer or complicate their stack further with a Rails/Django friendly stack.
If you've cross this chasm and are convinced you have the client's best interest in mind, then I would look for examples on the Internet where the same application has been authored in both Java and Rails/Django. Here's an example of the Pet Store implemented in Rails.
http://www.anassina.com/projects/railspetstore/
You can download the source code and demonstrate to your client how much less code is needed to achieve the same result.
Explain to the client why less code is valuable: the less code you write, the fewer bugs you will have.
The first 2 arguments from the top of my mind:
Easier and faster development = cheaper product, less time to market.
SO optimization out of the box.
While many of you made some good suggestions, WRT the talks/resources for using these frameworks, you may also note to have a look at talk on redesigning yellow pages in ROR:
Summary from the site:
This talk explains how
YELLOWPAGES.COM, one of the
highest-traffic websites in the U.S.,
was written using Ruby on Rails, how
it was scaled to handle the traffic
and how the software architecture
evolved. Also: the reasons for
choosing Ruby on Rails.
The best case to be made for either of these frameworks is their ability to automate repetitive and time-consuming tasks. This allows developers to be faster and more productive which in turn means projects are delivered faster.
The problem with a "brochure" approach is that it doesn't address the clients needs. Putting the language/platform of choice into a presentation that addresses the clients goals is much more likely to sell them - both on the tools you want to use, as well as you as a provider. As long as you can show that your approach will solve the problem (preferably with the least amount of expense), you'll have fewer objections and less of the "but I've heard that xxx is the best".

Dilemma: Should I learn Seaside or a Python framework?

I know it's kinda subjective but, if you were to put yourself in my shoes which would you invest the time in learning?
I want to write a web app which deals securely with relatively modest amounts of peoples private data, a few thousand records of a few Kb each but stuff that needs to be kept safe, addresses, phone numbers etc. I've done several web projects in PHP/MYSQL and have decided, handy though it is I really don't like PHP and don't want to do another large project in it...
As such I figure I'd best learn something new and so I am considering 2 options (although I'll happily entertain others if you have suggestions). I'm having terrible trouble deciding though. They both look quite involved so rather than just jump in and potentially waste days getting up to speed enough on both of them to make an informed choice I thought I'd come here and canvas some opinion.
So the two options I'm considering are...
One of the PYTHON Web frameworks - TurboGears seems well regarded?
Advantage: Of all the languages I ever tried Python is by far and away my favorite. There's loads of frameworks to choose from and I have done quite a lot of non web python coding over the last few years.
Disadvantage: There's loads to choose from so it's hard to pick! Need to run single server process? or mod_python? which I don't like the sound of. What I do like is the notion of process separation and compartmentalization, i.e. if one users account is compromised it gives an attacker no leverage against the rest of the system. I'm not clear to what extent a python solution would handle that.
Writing it as a SEASIDE app Which I guess runs on a squeak app server?
Adv: From what I've heard it would permit good compartmentalization of users as each would have their own little private VM independent of all the systems other users which sounds wonderful from a security, scaling and redundancy standpoint.
Dis: I've not done any Smalltalk since Uni 15 years back and I never dug too deep into it then. I don't see much entry level help for seaside or that many projects using it. I suspect setting a server up to run it is hard for the same reason i.e. not because it's inherently hard but just cause there will be less help online and a presumption you are already rather au fait with Sqeak/Smalltalk.
So, what do people think? Would I be able to efficiently get the kind of strong separation and compartmentalization I'm after with a Python framework? Is Seaside as good as I think in terms of insulating users from each other? Might I be better off, security wise, sticking to the languages I'm most familiar with so I don't make any n00b mistakes or will Seaside be worth worth scaling the learning curve and prove more secure, comprehensible and maintainable in the long run? At the end of the day it's not a life or death decision and I can always bail if I start with one and then hate it so pls nobody get all holy language war and start flaming anyone! ;-)
Cheers for any replies this gets,
Roger :)
Disclaimer: I really don't like PHP, Python is nice, but doesn't come close to Smalltalk in my book. But I am a biased Smalltalker. Some answers about Seaside/Squeak:
Q: Which I guess runs on a squeak app server?
Seaside runs in several different Smalltalks (VW, Gemstone, Squeak etc). The term "app server" is not really used in Smalltalk country. :)
Q: From what I've heard it would permit good compartmentalization of users as each would have their own little private VM independent of all the systems other users which sounds wonderful from a security, scaling and redundancy standpoint.
Yes, each user has its own WASession and all UI components the user sees are instances living on the server side in that session. So sharing of state between sessions is something you must do explicitly, typically through a db.
Q: I've not done any Smalltalk since Uni 15 years back and I never dug too deep into it then. I don't see much entry level help for seaside or that many projects using it.
Smalltalk is easy to get going with and there is a whole free online book on Seaside.
Q: I suspect setting a server up to run it is hard for the same reason i.e. not because it's inherently hard but just cause there will be less help online and a presumption you are already rather au fait with Sqeak/Smalltalk.
No, not hard. :) In fact, quite trivial. Tons of help - Seaside ml, IRC on freenode, etc.
Q: Is Seaside as good as I think in terms of insulating users from each other?
I would say so.
Q: Might I be better off, security wise, sticking to the languages I'm most familiar with so I don't make any n00b mistakes or will Seaside be worth worth scaling the learning curve and prove more secure, comprehensible and maintainable in the long run?
The killer argument in favor of Seaside IMHO is the true component model. It really, really makes it wonderful for complex UIs and maintenance. If you are afraid of learning "something different" (but then you wouldn't even consider it in the first place I guess) then I would warn you. But if you are not afraid then you will probably love it.
Also - Squeak (or VW) is a truly awesome development environment - debugging live Seaside sessions, changing code in the debugger and resuming etc etc. It rocks.
Forget about mod_python, there is WSGI.
I'd recommend Django. It runs on any WSGI server, there are a lot to choose from. There is mod_wsgi for Apache, wsgiref - reference implementation included in Python and many more. Also Google App Engine is WSGI, and includes Django.
Django is very popular and it's community is rapidly growing.
I'd say take a look at Django. It's a Python framework with a ready-made authentication system that's independent of the hosting OS, which means that compromises are limited to the app that was compromised (barring some exploit against the web server hosting the Python process).
I've been getting into seaside myself but in many ways it is very hard to get started, which has nothing to do with the smalltalk which can be picked up extremely quickly. The challenge is that you are really protected from writing html directly.
I find in most frameworks when you get stuck on how to do something there is always a work around of solving it by using the template. You may later discover that this solution causes problems with clarity down the road and there is in fact a better solutions built into the framework but you were able to move on from that problem until you learned the right way to do it.
Seaside doesn't have templates so you don't get that crutch. No problems have permanently stumped me but some have taken me longer to solve than I would have liked. The flip side of this is you end up learning the seaside methodology much quicker because you can't cheat.
If you decide to go the seaside route don't be afraid to post to the seaside mailing list at squeakfoundation.org. I found it intimidating at first because you don't see a lot of beginner questions there due to the low traffic but people are willing to help beginners there.
Also there are a handful of seaside developers who monitor stackoverflow regularly. Good luck.
Have you taken a look at www.nagare.org ?
A framework particularly for web apps rather than web sites.
It is based around the Seaside concepts but you program in Python (nagare deploys a distribution of python called Stackless Python to get the continuations working).
Like Seaside it will auto generate HTML, but additionally can use templates as required.
It has been recently open sourced by http://www.net-ng.com/ who themselves have many years experience in delivering web apps/sites in quality web frameworks like zope and plone.
I am researching it myself at the moment to see if it fits my needs, so can't tell you what I think of it in the wild. If you take a look, please give your feedback.
While considering a Smalltalk web framework, look at Aida/Web as well. Aida has built-in security with user/group/role management and strong access control, which can help you a lot in your case. That way you can achieve safe enough separation of users at the user level in one image. But if you really want, you can separate them with running many images as well. But this brings increased maintenance and I'd think twice if it is worth.
I'm toying with Seaside myself and found this tutorial to be invaluable in gaining insight into the capabilities of the framework.
I think you've pretty much summed up the pros and cons. Seaside isn't that hard to set up (I've installed it twice for various projects) but using it will definitely affect how you work--in addition to re-learning the language you'll probably have to adjust lots of assumptions about your work flow.
It also depends on two other factors
If other people will eventually be maintaining it, you'll have better luck finding python programmers
If you are doing a highly stateful site, Seaside is going to beat the pants off any other framework I've seen.
There is now an online book on Seaside to complete the tutorial pointed out earlier.

Categories

Resources