Develop Reference

MySQL module for Python 3

MySQLdb as I understand doesn't support Python 3. I've heard about PyMySQL as a replacement for this module. But how does it work in production environment?
Is there a big difference in speed between these two? I asking because I will be managing a very active webapp that needs to create entries in the database very often.

PyMySQL is a pure-python database connector for MySQL, and can be used as a drop-in replacement using the install_as_MySQLdb() function. As a pure-python implementation, it will have some more overhead than a connector that uses C code, but it is compatible with other versions of Python, such as Jython and PyPy.
At the time of writing, Django recommends to use the mysqlclient package on Python 3. This fork of MySQLdb is partially written in C for performance, and is compatible with Python 3.3+. You can install it using pip install mysqlclient. As a fork, it uses the same module name, so you only have to install it and Django will use it in its MySQL database engine.

What is PyMySQL and how does it differ from MySQLdb? Can it affect Django deployment?

I just solved some problems in my Django 1.3 app by using PyMySQL instead of MySQLdb. I followed this tutorial on how to make the switch: http://web-eng-help.blogspot.com/2010/09/install-mysql-5-for-python-26-and.html
Now I want to know what PyMySQL actually is and how it is different from MySQLdb.
I am using it on localhost and will then upload it to some hosting.
Is it fine to use PyMySQL on localhost and on hosting whatever they provide? Since I have changed "MySQLdb" in base.py and introspection.py to "PyMySQL", will I need to upload it to the server after changing these files? Or as it is Django's files, since Django will be uploaded there already, does it not matter much?

PyMySQL and MySQLdb provide the same functionality - they are both database connectors. The difference is in the implementation where MySQLdb is a C extension and PyMySQL is pure Python.
There are a few reasons to try PyMySQL:
it might be easier to get running on some systems
it works with PyPy
it can be "greened" and works with gevent
The proper way to use it with Django is to import it and tell it to impersonate MySQLdb in your top-level file, usually manage.py. Put the following code at the very top of your manage.py (or whatever file you call when starting your server):
try:
import pymysql
pymysql.install_as_MySQLdb()
except ImportError:
pass

PyMySQL and MySQLdb are both database connectors for Python, libraries to enable Python programs to talk to a MySQL server.
You would normally never upload core Django files when deploying an app. If Django is working fine on your deployment server, you definitely don't need to change anything there. The DB driver is a step or two below the ORM even, and certainly none of the code you have written depends on which of these is in use.

Your first point:
According to pymysql wiki page:
MySQLdb, is a C extension module that has a reputation of being
difficult to compile, especially if you're on a Mac. Additionally,
end-users need to wait for new binaries to be compiled for each new
release of Python, and MySQLdb will never run on Jython, IronPython,
or PyPy (without something like cpyext or IronClad). We also maintain
100% compatibility between Python 2 and Python 3, so all advancements
made on the 2.x trunk will be immediately available on Python 3.
Your second point:
If django is working fine on your localhost, then it should be fine on
your development.

As per my experience I had difficulty in installing "MySQL-python" - (MySQLdb).
It made me search for more alternatives so I found pymysql, and it also got installed easily and worked in first go like a charm.
So I would suggest using pymysql only instead of MySQLdb.

I am starting with these topic, I only want to say an observation: PyMSQL has CPYTHON as a requirement(is optionall perhaps for performance https://pypi.org/project/PyMySQL/#requirements) to install, and Cpyhton depend on 'C', I tested Cpython and I had trouble when installed for the version of C too... then both implementation depend on 'C' [if you want performance], is the same thing for me...if the performance is not problem, perhaps PyMySQL is good without Cpython, free of 'C'. Perhaps we can start with PyMySQL alone with Python and switch Python to Cpython to gain in performance that could be a good thing we have all the things running and after that we can try to switch to Cpython,,,
We need to know the funcionality difference. Why in Django PyMySQL run better for you or give to you solutions for some problems, what problems? That is the important thing for change perhaps. MySQLdb perhaps depend directly from 'C' but PyMSQL indirectly thru Cpython(in case of similar performance), I prefer a direct dependence without limitations of jumps...Greetings.

Has anyone here tried using the iSeries Python port?

I found http://www.iseriespython.com/, which is a version of Python for the iSeries apparently including some system specific data access classes. I am keen to try this out, but will have to get approval at work to do so. My questions are:
Does the port work well, or are there limits to what the interpreter can handle compared with standard Python implementations?
Does the iSeries database access layer work well, creating usable objects from table definitions?

From what I have seen so far, it works pretty well. Note that I'm using iSeries Python 2.3.3. The fact that strings are natively EBCDIC can be a problem; it's definitely one of the reasons many third-party packages won't work as-is, even if they are pure Python. (In some cases they can be tweaked and massaged into working with judicious use of encoding and decoding.) Supposedly 2.5 uses ASCII natively, which would in principle improve compatibility, but I have no way to test this because I'm on a too-old version of OS/400.
Partly because of EBCDIC and partly because OS/400 and the QSYS file system are neither Unix-like nor Windows-like, there are some pieces of the standard library that are not implemented or are imperfectly implemented. How badly this would affect you depends on what you're trying to do.
On the plus side, the iSeries-specific features work quite well. It's very easy to work with physical files as well as stream files. Calling CL or RPG programs from Python is fairly painless. On balance, I find iSeries Python to be highly usable and very worthwhile.
Update (2012): A lot of work has gone into iSeries Python since this question was asked. Version 2.7 is now available, meaning it's up-to-date as far as 2.x versions go. A few participants of the forum are reasonably active and provide amazing support. One of them has gotten Django working on the i. As expected, the move to native ASCII strings solves a lot of the EBCDIC problems and greatly increases compatibility with third-party packages. I enthusiastically recommend iSeries Python 2.7 for anyone on V5R3 or later. (I still strongly recommend iSeries Python 2.3.3 for those who are on earlier versions of the operating system.)
Update (2021): Unfortunately, iSeriesPython is no longer maintained, and the old website and forum are gone. You can still get the software from its SourceForge repository, and it is still an amazingly useful and worthwhile asset for those who are stuck on old (pre-7.2) versions of the operating system. For those who are on 7.2 or newer, there is a Python for PASE from IBM, which should be considered the preferred way to run Python on the midrange platform. This version of Python is part of a growing ecosystem of open source software on IBM i.

It sounds like it is would work as expected. Support for other libraries might be pretty limited, though.
Timothy Prickett talks about some Python ports for the iSeries in this article:
http://www.itjungle.com/tfh/tfh041706-story02.html
Also, some discussion popped up in the Python mailing archives:
http://mail.python.org/pipermail/python-list/2004-January/245276.html

iSeriesPython is working very well.
We are usning it since 2005 (or earlier) in our Development and Production Environments as an utility language, for generating of COBOL source code, generating of PCML interfaces, sending SMS, validating/correcting some data ... etc.
With iSeriesPython you can access the iSeries database at 2 ways: using File400 and/or db2 module. You can execute OS/400 commands and you can work with both QSYS.LIB members and IFS stream files.
IMHO, iSeries Python is very powerful tool, more better than REXX included with iSeries.
Try it!

I got permission to install iSeries Python on a box about 3 years ago. I found that it worked pretty much as advertised. I contacted the developer and he was very good about answering questions. However, before I could think about using it in production, I had to approach the developer regarding a support contract. That really isn't his gig, so he said no and we scrapped the idea. The main limitation I found is that it is several releases behind Python on other platforms.
I have also had very good experience with Jython on the iSeries. Java is completely supported on the iSeries. Theoretically, everything you can do in RPG on the iSeries, you can do in Java, which means you can do it in Jython. I was sending email from an AS/400 (old name for iSeries) via JPython (old name for Jython) and smtplib.py in 1999 or 2000.

Another place to look is on the mailing list MIDRANGE-L or search the archives for the list at midrange.com. I know they have talked about this a while back.

Werkzeug in General, and in Python 3.1

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.

MySQL-db lib for Python 3.x?

So, looking for a mysql-db-lib that is compatible with py3k/py3.0/py3000, any ideas? Google turned up nothing.

It appears the MySQLdb is pretty much a dead project. However, PyMySQL is a dbapi compliant, pure-python implementation of a mysql client, and it has python 3 support.
EDIT: There's also MySQL Connector/Python. Same idea.

I was looking for it too, but also found nothing, so I ported MySQL-python-1.2.3 to py3k
you can read it here
http://sourceforge.net/p/mysql-python/discussion/70460/thread/61e3a3c9/

There are currently a few options for using Python 3 with mysql:
https://pypi.python.org/pypi/mysql-connector-python
Officially supported by Oracle
Pure python
A little slow
Not compatible with MySQLdb
https://pypi.python.org/pypi/pymysql
Pure python
Faster than mysql-connector
Almost completely compatible with MySQLdb, after calling pymysql.install_as_MySQLdb()
https://pypi.python.org/pypi/cymysql
fork of pymysql with optional C speedups
https://pypi.python.org/pypi/mysqlclient
Django's recommended library.
Friendly fork of the original MySQLdb, hopes to merge back some day
The fastest implementation, as it is C based.
The most compatible with MySQLdb, as it is a fork
Debian and Ubuntu use it to provide both python-mysqldb andpython3-mysqldb packages.
benchmarks here: https://github.com/methane/mysql-driver-benchmarks

As for future plans of MySQLdb, you might want to ask the author (Andy Dustman).
His blog is here: http://mysql-python.blogspot.com/

Here is a working repository for Python 3: https://github.com/davispuh/MySQL-for-Python-3

not sure if you're still looking, but you could try this:
http://sourceforge.net/projects/mypysql/

You can download the mysql-connector-python module compatible with Python3:
http://rpm.pbone.net/index.php3/stat/4/idpl/15667200/dir/rawhide/com/mysql-connector-python3-0.3.2-2.fc16.noarch.rpm.html
Get the "source RPM", unzip it and use it (e.g. put it in your PYTHONPATH, and look at the examples).

You're probably better off using Python 2.x at the moment. It's going to be a while before all Python packages are ported to 3.x, and I expect writing a library or application with 3.x at the moment would be quite frustrating.

There is an official Python 2/3 library, downloadable from MySQL website.
Oracle released version 1.0.7 to public on 29 September 2012.
It's pure Python and works with MySQL 4.1+
See more details here: http://dev.mysql.com/doc/connector-python/en/connector-python.html
I'm currently using it with MySQL 5.5 and Python 3.2 with no problems thus far :)