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.
Related
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.
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.
Is 2.x still the norm or would you recommend just coding in v3 at this point?
Python 3 is still a long way off having universal support from tools, libraries and distros, so its use in production would depend very much on whether the bits you need (or are likely to need in the near future) have been ported.
For exploratory, educational and other uses, it depends very much on your own proclivity for living on the bleeding edge. If you are happy building from source and debugging and hacking third-party libraries to get things working, then you'll probably have no issues with Python 3. Otherwise, stick to the latest your distro offers, and if it is stuck on a really old Python — CentOS is still on 2.4! — you have my commiserations. Personally, I steer clear of CentOS for precisely this reason.
Google App Engine documentation states it uses Python 2.5
Today I happened to notice that Python Imaging Library is till not released for 3.x.
So, if you need those libraries or services, I guess you should wait.
Do the frameworks and libraries you use have Python 3 versions? Libraries you use for development, and does your deploy stack support Python 3?
Many Python projects have a lot of dependancies, especially web based projects, most of which aren't Py3K ready yet.
If your stack is good, sure - Python 3 is the future, might as well embrace it now.
My main use of Python is Django. Support for 3.x for this framework still lies in the future, unfortunately, and who knows about any related modules - so no, it's not quite time for many people.
I actually bought Python 3 books last year when I started learning Python, thinking "I'll just start with 3 from the beginning!". That didn't work out, though.
I've always used v3 primarily. "Hacking 3rd party libraries" to me is just like importing any other module. The only thing is since most stuff still uses v2 you have to know both versions and keep them straight when looking at others code.
G'day,
I'm wanting to go back to Python after not using it for a while and I saw this question "Python Version for a Newbie" while wondering about getting back into Python 2.6 or Python 3.
Almost all of the questions' answers were along the lines that most of the code out there, libraries, legacy systems, etc., is 2.5 or 2.6 rather than 3 so start with 2.x now and then head towards 3 later on.
Given that the question and all answers date from early December 2008 I was wondering is this still the case?
Should someone who wants to get back into Python maybe start off with 2.6 and then head towards 3 later on?
Yes. Virtually all live production systems will use 2.5/2.6 for a long time yet. There's no point learning 3.0, only to have to downgrade it because your host doesn't support it.
95% of what you will learn in 2.5/2.6 is applicable to 3 anyway.
Depends on the amount of libraries you're going to use.
Raw Python, or all libs are available for Py3k - go for it without any doubts.
Python code distributed as standalone app (using PyInstaller), relying on some GUI lib, XML-lib, win32api etc - double check if all libs are available at least as betas for Py3k. Chances are still quite high that some older lib is not available for Python 3.x, and either you port it by yourself to new Python version, or you switch to some other lib or - stick to Python 2.6 for a while.
If you want to use only standard library then try Python 3.1. If you want to use others libraries/frameworks then they dictate the version to use. For example web2py framework will work best on 2.5.
I would say that Python 2.4 is the safest to learn, but the changes from 2.4->2.5->2.6 make some small progress towards Python 3.x, even if they may never make it (if I recall there will be some more steps?).
Python 3.1 can be used if you own a dedicated server and intend to build your own applications from the ground up. WSGI does support this, but I wouldn't recommend it.
As has already been said, I would learn the Python 2.5 or Python 2.6 style, but I would make a few changes.
Look at the Python 3 style regarding brackets.
e.g. The print function in 2.x has always been just
print "Hello World"
Where as in 3.x you need to enclose it
print("Hello World")
This is probably a good practice to pick up on, but things like Exceptions will cause issues if you use 3.x in 2.x. I know it's probably a bit confusing, but if you make sure you wrap your functions (additional brackets shouldn't really hurt most things) so that nothing is bare (bare like the first code snippet above), then it'll help with the transition.
The problem is, if you started with 2.4 or more it is better if you start from there, so you'll get on track faster, after some time when you feel comfortable with you code you can try 3.0 and find out what did they change and learn the new style.
I for once still code in 2.6 style and follow those guidelines, still haven't seen the changes in 3.0
I've been looking really hard at all of the way**(s)** one can develop web applications using Python. For reference, we are using RHEL 64bit, apache, mod_wsgi.
History:
PHP + MySQL years ago
PHP + Python 2.x + MySQL recently and current
Python + PostgreSQL working on it
We use a great library for communicating between PHP and Python (interface in PHP, backend in Python)... However, with a larger upcoming project starting, using 100% python may be very advantagous.
We typically prefer not to have a monolithic framework dictating how things are done. A collection of useful helpers and utilities are much preferred (be it PHP or Python).
Question 1:
In reading a number of answers from experienced Python users, I've seen Werkzeug recommended a number of times. I would love it if several people with direct experience using Werkzeug to develop professional web applications could comment (in as much detail as their fingers feel like) why they use it, why they like it, and anything to watch out for.
Question 2:
Is there a version of Werkzeug that supports Python 3.1.1. I've succefully installed mod_wsgi on Apache 2.2 with Python 3.1.1.
If there is not a version, what would it take to upgrade it to work on Python 3.1?
Note: I've run 2to3 on the Werkzeug source code, and it does python-compile without
Edit:
The project that we are starting is not slated to be finished until nearly a year from now. At which point, I'm guessing Python 3.X will be a lot more mainstream. Furthermore, considering that we are running the App (not distributing it), can anyone comment on the viability of bashing through some of the Python 3 issues now, so that when a year from now arrives, we are more-or-less already there?
Thoughts appreciated!
mod_wsgi for Python 3.x is also not ready. There is no satisfactory definition of WSGI for Python 3.x yet; the WEB-SIG are still bashing out the issues. mod_wsgi targets a guess at what might be in it, but there are very likely to be changes to both the spec and to standard libraries. Any web application you write today in Python 3.1 is likely to break in the future.
It's a bit of a shambles. Today, for webapps you can only realistically use Python 2.x.
I haven't used Werkzeug, so I can only answer question 2:
No, Werkzeug does not work on Python 3. In fact, very little works on Python 3 as of today. Porting is not difficult, but you can't port until all your third-party libraries have been ported, so progress is slow.
One big stopper has been setuptools, which is a very popular package to use. Setuptools is unmaintained, but there is a maintained fork called Distribute. Distribute was released with Python 3 support just a week or two ago. I hope package support for Python 3 will pick up now. But it will still be a long time, at least months probably a year or so, before any major project like Werkzeug will be ported to Python 3.
I can only answer question one:
I started using it for some small webstuff but now moved on to rework larger apps with it. Why Werkzeug? The modular concept is really helpful. You can hook in modules as you like, make stuff easily context aware and you get good request file handling for free which is able to cope with 300mb+ files by not storing it in memory.
Disadvantages... Well sometimes modularity needs some upfront thought (django f.ex. gives you everything all at once, stripping stuff out is hard to do there though) but for me it works fine.