Recently I was working on my Django web app, when I discovered that for some reason Django only worked when I used a python 2.x. Interpreter, but all the while I had thought it had been configured for Python 3 and thus was coding like so.
So I tested it with print(sys.version()) and was surprised when Python 2.7 came out. After a little digging I discovered that Django uses the six module. My first question is why does Django use this? Is there any reason other than just making it easier on the programmer? My second question is, since I've been treating it like Python 3 should I go back and change my code so that it is pure Python 2? Or does it not matter?
P.s. I kinda understand how six works, but it would be great to know a little more about it.
Thanks.
Django 1.5 is the first version of Django to support Python 3. The same code runs both on Python 2 (≥ 2.6.5) and Python 3 (≥ 3.2), thanks to the six compatibility layer.
Writing compatible code is much easier if you target Python ≥ 2.6. Django 1.5 introduces compatibility tools such as django.utils.six, which is a customized version of the six module. For convenience, forwards-compatible aliases were introduced in Django 1.4.2. If your application takes advantage of these tools, it will require Django ≥ 1.4.2.
For More read through Porting to Python 3
Which Python version your system uses has nothing whatsoever to do with the six module. That's something that Django uses internally to be able to work with both 2.7 and 3.x.
If you want to use Python 3 locally, you need to configure your system to do so. That might just mean creating your virtualenv with Python 3, for example.
Related
How would I use 2 different python mods in the same file when both mods require different python versions? I am trying to write a program that uses pygame, which only works with 3.2 and pymssql, which only works with 3.3. I get errors if I try to run them both in the same file(on either python version), but not if I run them separately.
There is no simple solution for you. In my opinion, it is the pygame communitie's responsibility to make it work on Python 3.3. Python 3.3 has a higher potential to be widely distributed than Python 3.2. Also, "supporting Python 3" nowadays should mean supporting Python 3.3/3.4, and not only Python 3.2. I guess this is on the todo list of the pygame maintainers. If in doubt, you might want to ask on the corresponding forums/mailing list if supporting Python 3.3 is already planned.
If you are curious and not frightened, you might event want to dig into why pygame fails on Python 3.3 and start fixing issue by issue. I guess this effort will be highly appreciated.
Edit:
I was assuming that you did your research homework a bit :-) Looks like pygame is available for Python 3.3:
https://bitbucket.org/pygame/pygame/downloads
Thanks #batbrat.
I'm currently testing frameworks to create a big multiplayers game. I choose Django.
But I have a question about the version of Python. I should to create that project from scratch with Python 3.x or Python 2.x?
Python 3.x and Django compatibly is ok, or not production usable for now?
I wouldn't highly suggest going production with Python 3 with Django or for that matter any other framework that requires you to depend on many third party applications, although many have been ported to Python 3, you still may find bugs, which you will likely have to fix or wait awhile before maintainers get to it.
Also, there aren't many compelling reasons to move to Python 3 at the moment, but that I suspect that will change soon with all the asynchronous work being put into Python 3.
Django is compatible with Python 3.
There's at least one issue with Python3 + Django (1.6) + MySQL.
MySQLdb hasn't been ported to Python3 yet.
The other python-only mysql connector mentioned in the Django documentation (MySQL Connector/Python) has a bug in it which might stop it working with fixtures.
http://bugs.mysql.com/bug.php?id=72001
It looks like Oracle has closed this bug report by documenting that the problem may occur; so a real fix doesn't look likely any time soon.
So if you rely on fixtures and use MySQL, you'll likely have a problem.
Try using the latest GA version of mysql-connector-python.
I'm going to start on a long (~1-year) programming project in Python. I want to use wxPython for my GUI (supports 2.6), but I also want to use 3.1 for the rest of the project (to start using the 3.x syntax).
Is there any way for me to design a project that mixes 2.x and 3.x modules? Or should I just bite the bullet and use either 2.x (preferred, since I really want to learn wxPython) or 3.x throughout?
Thanks,
Mike
You should use python 2.7 (a release candidate is expected in the next days) that is very close to python 3.1 and to code taking care of no using deprecated features. There is a recent version of wxpython for python 2.7.
After wxpython gets 3.1-3.2 builds, conversion of the code should not be too hurting.
Still, wxpython has no deadline for the transition :-(
Another option is to use pyQt that already has builds for python 3.1
Python 2 and 3 are not that different. If you have learned Python 2 well, it will be a matter of minutes to get acquainted with Python 3. The official recommendation says that you should use Python 2.6 (the current version) and try to be forward-compatible. Python 3 is currently not an option for large projects as virtually none of the popular packages have been translated yet. But development of Python 2 and 3 will continue in parallel for a long time, so you won't lose much by not using Python 3. You can import many syntactical features of 3 (Unicode string literals, division, print function, absolute imports) using the __future__ module, and the standard library remains mostly the same. So I'd recommend using Python 2.
mixing the ability to use wxPython (2.x) + with learning new syntax (3.x)
Don't "mix".
Write Python 2. Get it to work.
Play with Python 3 separately. Don't "mix".
When the various packages and modules are available in Python 3, use the 2to3 conversion to create Python 3. You'll find some small problems. Fix your Python 2 so that your package works in Python 2 and also works after the conversion.
Then, you can drop support for Python 2 and focus on Python 3.
Don't "mix".
One of the feature I like in RoR is the db management, it can hide all the sql statement, also, it is very easy to change different db in RoR, is there any similar framework in Python 3000?
This answer was awfully outdated. The current state of afairs is:
Django is close to supporting Python 3
CherryPy supports Python 3 since version 3.2
Pyramid has Python 3 support since 1.3
Bottle, which is a lightweight WSGI micro web-framework, supports Python 3
I'm sure this list will keep growing every coming month, specially considering that there will never be a Python 2.8.
2.7 will be the end of the line for Python 2 development, and now the official upgrade path from 2.7 is Python 3.x. I'm sure that with this state of affairs, Python 3 support from web frameworks is only going to get better and better.
[OUTDATED]
Python 3 is not yet in high deployment. It's still lacking a lot of third party libraries.
The recommended Python version is 2.6.x, as it's the most current, it's backwards compatible, and has many backported features from 3.1.
For Python 2.6 you will find quite a few frameworks:
Django
Turbogears
CherryPy
Zope
and many more
I believe CherryPy is on the verge of being released for Python 3.X.
Python 3 isn't ready for web applications right now. The WSGI 1.0 specification isn't suitable for Py3k and the related standard libraries are 2to3 hacks that don't work consistently faced with bytes vs. unicode. It's a real mess.
WEB-SIG are bashing out proposals for a WSGI revision; hopefully it can move forward soon, because although Python 3 isn't mainstream yet it's certainly heading that way, and the brokenness of webdev is rather embarrassing.
Python 3 is not ready for practical use, because there is not yet enough libraries that have been updated to support Python 3. So the answer is: No.
But there are LOADS of them on Python 2. Tens, at least.
Django, Turbogears, BFG and of course the old man of the game: Zope. To tell which is best for you, you need to expand your requirements a lot.
There's Django but it works with Python 2.3+ only for now.
I've written a web-app in python using SQLite and it runs fine on my server at home (with apache and python 2.5.2). I'm now trying to upload it to my web host and there servers use python 2.2.3 without SQLite.
Anyone know of a way to use SQLite in python 2.2.3 e.g. a module that I can upload and import? I've tried butchering the module from newer versions of python, but they don't seem to be compatible.
Thanks,
Mike
There is no out-of-the-box solution; you either have to backport the SQLlite module from Python 2.5 to Python 2.2 or ask your web hoster to upgrade to the latest Python version.
Python 2.2 is really ancient! At least for security reasons, they should upgrade (no more security fixes for 2.2 since May 30, 2003!).
Note that you can install several versions of Python in parallel. Just make sure you use "/usr/bin/python25" instead of "/usr/bin/python" in your scripts. To make sure all the old stuff is still working, after installing Python 2.5, you just have to fix the two symbolic links "/usr/bin/python" and "/usr/lib/python" which should now point to 2.5. Bend them back to 2.2 and you're good.
Look here: http://oss.itsystementwicklung.de/download/pysqlite/
From the release notes (http://oss.itsystementwicklung.de/trac/pysqlite/browser/doc/install-source.txt)
Python:
Python 2.3 or later
You may not be able to do what you're trying to do.
If you have shell access to your web server, you can probably build you're own version of Python and SQLite. This will let you use the latest version. Download the source code, then when you configure it, do something like "./configure --prefix=$HOME/packages".
Next, fiddle around with your .profile, or .bashrc or whatever it is to make sure $HOME/packages/bin comes first in your path. This will cause your private Python to override the one installed by your web server.
This page might give you a little more information for how to do this on a server like Dreamhost: http://wiki.dreamhost.com/Python
In case anyone comes across this question, the reason why neither pysqlite nor APSW are available for Python 2.2 is because Python 2.3 added the simplified GIL API. Prior to Python 2.3 it required a lot of code to keep track of the GIL. (The GIL is the lock used by Python to ensure correct behaviour while multi-threading.)
Doing a backport to 2.2 would require ripping out all the threading code. Trying to make it also be thread safe under 2.2 would be a nightmare. There was a reason they introduced the simplified GIL API!
I am still astonished at just how popular older Python versions are. APSW for Python 2.3 is still regularly downloaded.