ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Not sure about Django, but for Python web frameworks in general the biggest problems come from string changes in Python 3. As you may know, Python 3 strings now contain Unicode characters (similar to Python 2 unicode objects), and for characters in any encoding (e.g. UTF-8) there are bytes objects. Unfortunately, they can't be used in the same way as Python 2 strings (at least in some cases), and that makes it hard for web frameworks to switch. To quote Armin Ronacher, the author of Flask framework, "the web is based on bytes with encodings", but Python 3 made it difficult to work with this kind of data. Python developers realize this now, and hopefully they'll come up with solutions for Python 3.3, but I wouldn't hope for the current situation to change any time soon.
Look at the topic of this thread. It's about Django and Python 3 and has nothing to do with PHP. That's why it's unrelated to the question you asked. You should have started a new thread for it.
Now back to your question. Better for what? How do you define "better" in this case? How we should measure it? Not to mention that I don't know PHP and can't compare it with Python...
Yeah, seriously. Just compare how much cleaner the syntax for using "dictionaries" (Python hash tables) is than the syntax for using "arrays" (PHP hash tables).
I think you get my point. All of these things are "tools in our toolboxes." (During the course of a work-week, many of us might switch between PHP, Perl, Python, Ruby, and so-on. Hence, any discussion of "which one is better?" would merely elicit, at the very best, strange looks.)
Every language moves forward from major-release to major-release, and when the major-number changes, the encompassed set of changes is usually quite large and fundamental. For instance, Python-3 brings in a completely new treatment of Unicode. A very necessary thing for Python to have done, of course, but fundamentally incompatible in some ways with its past. (And it is perfectly understood that both versions will co-exist for perhaps many years to come, if not "forever.")
Enter Django. (Or, if you prefer, your_package_name_here.) Could be any one, really, and any language. It's a large legacy product with a large number of installations and built ... built very well ... for a particular language implementation. In this case, and at this moment, that is Python-2.
Deal with it.
Quote:
P.S.: It is actually quite common for more than one version of a language to be installed on the same server at the same time to support backward-compatibility in business-necessary cases like this one. It's not something that you want to do forever, but it can go on for a surprisingly long time. You can, IIRC, still license FORTRAN-G from IBM, to run under DOS/VSE in your virtual machine, and, by gawd, if you've got a fleet of satellites up there in the sky doing ######## which still depend upon those computations still being done today as they were done in the 1970's (don't ask... I can't tell...), that's exactly what you would do and still do.
The one and only time that I saw an actual computer in-service which had magnetic core memory was at the University of Tennessee, which kept a machine around for years because it could still run IBM 1401AutoCoder emulation. I have no idea how many thousands of dollars a month they paid to IBM to keep the machine going, but IBM quite-obligingly did so.
The Django development team will never have been caught flat-footed on anything at all, but a new language release is going to have some fundamental changes that are going to affect both Django and any other "plug-ins" that you may have. Fortunately, your appropriate response as a Django (or your_package_name_here your_language_name_here) user is a simple one: stick with the major-version of your_language_name_here that your_package_name_here has been certified for, and wait patiently.
Last edited by sundialsvcs; 02-10-2012 at 08:46 AM.
It is expected that a document detailing Django's Python 2.x deprecation process, and timeline for moving to Python 3.x, will be made available concurrently with, or shortly after, the Django 1.3 release.
Some additional on-topic info: according to http://getpython3.com/#notable-ports Django port to Python 3 is on the way, while Pyramid has already been ported (although it's still in alpha stage). Looks like transition to Python 3 is happening quicker than I thought it would. Now I need to wait for Flask port to happen and then I'll be a happy man.
If you must have a Python 3 web development framework now, CherryPy is Python 3 compatible. It is also much "lighter" and more "minimalistic" than Django. You can use it with the Jinja2 templating engine, which is also Python 3 compatible. Add SQLAlchemy (also Python 3 compatible) to the mix, and you have a full stack. Albeit not a stack as full-featured as Django or Web2py.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
