We Keep Coding

What versions of Python are in current use, and packages should support?

As a small-time Python package writer (cobs, simplerandom), I'm wondering what Python versions I should support.
I've heard anecdotally that Python 2.5 is still in use on enterprise type servers. So I thought 2.5 was the oldest that needed to be practically supported, here in 2011.
However, I saw this blog in which the author says he's still using 2.4. From memory, I saw an e-mail on the PyCrypto mailing list saying they aimed to keep support going back to 2.2 if possible.
Of course, then there's Python 3.x which is slowly gaining momentum. It would be good to know who is using that.
Then, there is also Jython and Ironpython, and I have very little idea about them.
Is there any concrete and up-to-date Python installation/usage data available to enlighten us? Is there any "best practices" or other advice for what versions/flavours of Python a package writer should aim to support?

I think that this is a problem that's simply inherent when developing any software. Anyone could be running any version and would need support for that version (I wonder how many people are still running Windoze ME out there? ;)). Personally, when developing libraries, I'll support only support the current version+. If for no other reason, because I'm only one person and I don't have a team.
Having said that, I'd stick my packages up on github and take patches from anyone who wants support for previous versions (and is willing to put in the work).
Edit:
I've found that a good rule in software development (especially packages) is develop only for what is needed, not what you think might be needed. In other words, get it working for whatever version of Python you're running (or is dearest to you) and then take support requests if you want to implement them yourself as people need them.

I have servers that run Python 2.3. :-)
But no, you don't need to support it. Most servers like that are just running, and do not get any new modules installed.
When creating a new module today, 2.6, 2.7, 3.1 and 3.2 is the versions to support. For existing modules you can ask your users. :-)

You should support the latest of the 2.x series (2.7 as of now) and 3.x (3.2 as of now). Unless you have a specific need for supporting older versions, I don't think you need to go there.
As for alternate implementations like IronPython and Jython, you should do that only if needed. It can be time consuming (although perhaps educational) to support you app for all these implementations.
As a side node, to test your app on multiple versions/implementations of Python, I recommend tox.

What's going on with python 3k? [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 13 years ago.
Since I'm not strictly python developer please don't flame me just for the question.
I'm wondering about Python 3k, that from my point of view, might be some kind of misconception.
Or quite in-relevant step forward (I'm taking into account the 2.6 and 3k releases, which was almost one after another).
Before the flame will start, I'll explain my position at this topic and I'd assume couple facts from my work environment.
I work in a cutting edge market data solutions company,
we use mainly functional languages to high throughput data analysis.
But we also use python as a second technology for smaller tasks, scripts, process management & monitoring.
Some of my colleagues write more serious production applications based on python technologies,
but:
ALL of our customers use python 2.6,
because of above we have quite strong 2.6 toolset and internal/external support,
We still plan to develop 2.6 apps.
Every small tool development is also based on 2.6 platform.
Additional what I observe:
at this point any new linux distribution (in our infrastructure) has python 2.6 on the board,
most third party modules are developed for 2.6 version,
great part of resources in the network is also dedicated for 2.6
(I know that You can port most of this to 3.1.x, but it's too big overhead here.)
I know that Py 3k is still growing but,
there is already python 3.1.1, but no one "cares" (in my environment).
I've a strong feeling that Python 3k overheads are stopping it for moving this great technology into new dimension.

The OP appears to be surprised that a minor-release upgrade (which added some nifty features, basically broke zero existing code, and allowed trivial rebuilds of all existing third party libraries) happened overnight at their organization, while a major-release upgrade (requiring much more effort especially from the point of view of third-party library authors) didn't and won't. I think I mostly feel surprised at their surprise;-).
Even minor-release upgrades don't happen instantly in most large projects and organizations; for example, App Engine is still using Python 2.5 (apparently, upgrading its specialized "sandboxed" Python runtime and all it relies on is not a zero-effort proposition, so they prefer to keep putting their energy towards adding engine features instead) -- so I believe are implementations such as Jython and PyPy (I think IronPython's in the process of migrating to 2.6, but the current production version is still 2.5).
Totally new projects starting today should seriously consider starting with Python 3; for example, Allison Randal's pynie (Python for Parrot) project made exactly that choice (and, I think, it was the correct choice in their situation). Migrating existing projects is a harder proposition, and mostly depends on what third-party components the existing project depends on (if a new project intrinsically depends on some functionality that's only available in 3rd party libraries for 2.6, not 3.1, then the new project will probably also have to stick with the 2.6 version for the time being, of course).
Third party libraries that are under active development will probably come out with Python 3 version gradually (for example, gmpy did so relatively recently). Once enough such third party libraries are available, the chance that a missing library inhibits migrating an existing project (or, even more, starting a new project) using Python 3 starts going down pretty rapidly. This makes Python 3 ports feasible. At some point, some attractive functionality will become available in Python 3 only (for example, if and when pynie releases, that might be the case for a Parrot implementation affording smooth interoperability with Perl &c), and that will provide a strong motivation for some projects to go 3-only (pragmatically stronger than pure issues of language quality).
Even then, some sufficiently large projects and organizations will stick with Python 2 for a long time, and you can confidently expect that at some time a 2.7 will exist (possibly one or two more after that, but that's harder to predict). Hey, I sharply remember that throughout the '90s in most large projects and organizations "Fortran" still meant Fortran 77 (in fact in some places -- not many, 30+ years after than Fortran version's first release -- that's still true today!)... for all the advantages of Fortran 90 and later versions, migration costs (esp. in terms of various compilers, libraries, tools) were just perceived as being too high a price to pay for the advantages of the new language version. That's just inevitable when a language acquires a large installed base and a rich ecosystem of third party tools and libraries, as Python 2 now has. No reason for surprise!-)

Py3k is a good and necessary step in the evolution of the Python language. I like it much better than 2.x, and code in it almost exclusively. I'm fortunately not dependent on third-party libraries, few of which are there for Py3k yet. But they will be.
There is nothing wrong with using 2.6 - 2.7 will come and be even more of a bridge to 3.x, and you can start generating Py3k-like code already that will be trivial to port to 3.x once your favorite third-party library is there. I think I read somewhere that Py2k will be around for several more years.

What exactly is the question here? You observe that there's a newer version of the platform you currently use. You have good reason for staying with the version you have. This pattern is common across very many development organisations, you simply cannot chase every new version of the stuff yiou use. Nor can you stay where you are for ever, eventually you will need to migrate.
There are forces that may drive you to migrate, for example
The new version has some very major new feature you would really benefit from (eg. annotations in Java 5)
Support for a current platform (or dependent library) is being withdrawn
Meanwhile, you could attempt to future-proof your code so that migrating is easier. Are you familiar with the level of change required to move up?

Since Python 3K is not backwards compatible, you can expect that it will take more time to be accepted in corporate environments. Python has a huge code base and many important third libraries. One must wait for all dependencies to be converted to Python 3K before adopting it. This could be a real slow process.
From what I understand, the creators of Python expected this to happen, but they thought it will be worse not to make the changes and just let the language "die".

Python 3.x is not yet aimed at production use, but it will get there in time.
As a language and a runtime, Python 3.x is fine. The limitation is that a lot of important third party libraries and tools are still in the process of being ported and tested.
It is expected that the transition to Python 3.x will take up to five years.
So, if you are not library developer, you really don't need to care about Python 3.x for the time being.
Also, it is not expected of current Python users to do the switch to Python 3.x anytime soon.

There are a lot of libraries which depend on other libraries in the Python ecosystem. Nose is used to test numpy, and scipy requires numpy, and lots of scientific libraries require scipy. Also, none of the library developers can start porting until their dependencies are ported. It's going to take a long time for whole chain to port across.
A lot of the pragmatists are hoping that python 2.7 and 2.8 will gradually depreciate the bits that won't work in python 3 (introduce a print function called print_function, then depreciate the print statement, then rename print_function to print ...), so eventually python 2 will merge with python 3.

Here is a video there Guido van Rossum, at the Py4Science meeting, talks about Python 3.
http://fperez.org/py4science/2009_guido_ucb/index.html

What's the state-of-the-art in Python programming in Windows? [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 10 years ago.
I'm looking to set up my development environment at home for writing Windows applications in Python.
For my first piece, I'm writing a simple, forms-based application that stores data input as XML (and can read that information back.) I do want to set up the tools I'd use professionally, though, having already done a round of didactic programming.
What tools are professional python developers using these days? In order to have a working python environment, what version of the compiler should I be using? What editor is common for professionals? What libraries are considered a must-have for every serious python developer?
Specifically, which Windowing and XML libraries are de rigeur for working in Windows?

I like Eclipse + PyDev (with extensions).
It is available on Windows, and it works very well well. However, there are many other IDEs, with strengths and weakness.
As for the interpreter (Python is interpreted, not compiled!), you have three main choices: CPython, IronPython and Jython.
When people say "Python" they usually refer to "CPython" that is the reference implementation, but the other two (based, respectively, on .Net and Java) are full pythons as well :-)
In your case, I would maybe go on IronPython, because it will allow you to leverage your knowledge of .Net to build the GUI and treating the XML, while leaving the implementation of business logic to Python.
Finally, should you decide to use CPython, finally, there are several choices for working with xml:
minidom; included in the standard library
lxml, faster and with a better API; it means an additional installation on top of Python.

Lots of questions, most hard to answer correctly. First of all, most of python development happens on unix-like platforms. You will hit many walls during development on Windows box.
Python is not a compiled lanugage, current preferred version for production is 2.5. For environement setup you should take a look at virtualenv. Editor is a personal choice, many Python developers use Vim, you can customize it pretty well to suite your needs.
About libraries, Python is very strong around this area and it's really hard to say what is a must to know. If you want to handle XML, I would preffer lxml.

If you go for CPython, make sure you get the win32 extensions by Mark Hammond, either as a separate download which you install on top of the vanilla Python installation, or as part of ActiveState's ActivePython. It includes an integrated editor and debugger.
Jython has recently reached 2.5 compliancy, but we quickly ran into recursion limit issues.
The standard distribution includes IDLE, a graphical editor and debugger.
I like shells, so I'm using IPython for interactive work, and pydb as debugger (unfortunately, I had problems getting pydb to work under Windows).

"What tools are professional python developers using these days?"
Lots
"In order to have a working python environment, what version of the compiler should I be using?"
["compiler" is meaningless. I'll assume you mean "Python"]
We use 2.5.4. We'll be upgrading to 2.6 as soon as we've done the testing.
"What editor is common for professionals?"
We use Komodo Edit.
"What libraries are considered a must-have for every serious python developer?"
We use Django, XLRD, PIL, and a few others. We don't plan this kind of thing in advance. As our requirements arrive, we start looking for libraries. We don't "pre-load" a bunch of "must-have" libraries. The very idea is silly. We load what we need to solve the problems we have.

There are no set standards in these matters, and for good reasons:
there is a fair amount of good choice
different people are productive with different tools
different tools and libraries are suited for solving different problems
That said, I think it's a valid question exactly because there is a fair amount of good choice. When there is too much choice people often do not chose at all and move on. You still need to do your own research to decide what is best for you but you may find here some good starting points.
Here is what I use professionally on windows:
python 2.5.4
latest wxPython
XRC Resource Editor from the wxPython docs & demos for the grunt of the tedious GUI design
lxml or gnosis utils for xml
WingIDE Professional

Taking the headline question literally, the answer has to be IronPython. The 2.0 releases are equivalent to CPython 2.5, and the 2.6 release (currently at beta2) is intended to match CPython 2.6 (full 2.6 release some time in the next couple of months). With either you can use the state of the art in Windows GUI frameworks, i.e. WPF; and you get the whole .net XML support libraries (excepting Linq to XML, which relies on clever bits of C# that IronPython cannot yet emulate).
I've used NetBeans Python plug-in happily as an IDE for IronPython using WPF.

The answer would depend on what you want to do with Python. If you want to do web programming, Python is blessed with many web frameworks. The most popular ones are: Django, Pylons, and Turbogears. There's also Google App Engine, where you can deploy your Python webapp (based on GAE framework) to Google's infrastructure. If you want to do Desktop programming then there is PyQT and TkInter, or you can even try using Java Swing with Jython. And if you want to do Mobile app programming then there is Python for S60 which is backed by Nokia.
Python is interpreted language, so there is no compiler (although the interpreter also compiles your python module into bytecode). I would recommend using Python 2.6 as it has some syntax and libraries that is different compared to 2.5. You can also start learning Python 3.0 too.
There is several IDE that is good for Python. You don't have to get yourself attached into one editor/IDE because most of them are good ones. For the commercial ones there is WingIDE which is really focus on making IDE for Python and I would really recommend IntelliJ IDEA with Python plugin which is really nice if you often look at the libraries in your Python environment. For the free ones (as others have said) there is Komodo Edit or you can also try Netbeans with Python plugin.
As for the must-have libraries, this is depending on what you want to do. What kind of application you want to develop with Python. But I think every Python developer should consider PIL for imaging library. I also use simplejson quite often, because I prefer using JSON rather than XML. If you are using XML though, you can use lxml as it is really fast in parsing XML.

When should I drop support for python2.4 on my public python library?

I maintain an open source python project. Right now it supports python 2.4, 2.5, 2.6. I am looking for to add support for python 3. I guess it will be easier if I drop 2.4 support.
I know it is possible to support all but it is very annoying if I have to install 4 or 5 python versions on my machine and run the tests on all of them. Although it is easy to avoid new features introduced in the language I would like to make use of them! And what is the point of supporting something that possible nobody uses? I do want to drop it, but also dont want to loose users (existing and new).
When should I drop support for python 2.4? Is there any recommendation on this?

I'd say it depends on your target audience. For enterprise stuff I think RedHat (certainly CentOS 5) are still on 2.4 - so if you want typical RedHat/CentOS using people to able to install without resorting to third party python installations then I think you need to keep 2.4 for a while. If most of your users are more 'desktop' based running Fedora/Ubuntu then they probably have 2.5/2.6 already so it wouldn't be an issue for them.

You don't have to drop support for 2.4 in order to add support for 3.x, as I'm sure you know. I've made coverage.py run on 2.3 through 3.1 with the same code. It's not always pretty, but it's possible: Running the same code on Python 2.x and 3.x.

It's a matter of weighing pros and cons.
I suppose the real answer to this question is how many features there are in 2.5/2.6 that would really improve your library. It seems as though 2.4 becomes less and less worth supporting as time goes by.
On the other hand, there are still some people on Python 2.4. You have to decide if it's worth it to drop support for them to take advantage of newer features of Python 2.5.

You don't have to drop anything, what works on 2.4, works on 2.5 and 2.6. You can easily avoid incompatibilities skipping "with", the ternary operation, et "import future".
Now, once you have a very stable and full featured version of your code and need to make a big achitectural change, start writting for Python 3.0. No rush, it won't be massively used before one year or two.
A good indicator is to focus on project that have the same audience as yours. When do they switch on the roadmap ?
GNOME ?
Django ?
Inkscape ?

Track downloads of each version of your project. Graph the daily traffic (or weekly if there is too much variation day to day) for each version separately. Keep an eye on the trends and at some point you will see a distinctly downward trend for 2.4 compared to the rest. When that downward trend is well established, discontinue upgrades to the 2.4 version, but keep it available for download. You should include some kind of note in the README for the last 2.4 version, and maybe display a message when it is installed.
At this point, your work is done, unless you find some really glaring error that you want to fix. You don't ever have to actually discontinue the 2.4 version, just cease upgrading it.
And the graphs that you now produce every week will tell you when it is time to do the same for 2.5, and eventually 2.6.

Any answer here is going to be subjective. I suggest you make a feature and user list. There are 2 things to consider here.
1: How will your program benefit - what features are better nicer/faster/less buggy in newer versions of Python ? What extra dependent libraries can your program utilize by sticking to an older version ? Not everything is ported to 3.x or even 2.5 yet.
2: How will your user benefit - What benefits do users gain from older versions. How much bigger / smaller does your user base get by dropping 2.4 and adding 3.x ? What does your user base look like currently.
The third is not really a point since direct benefit from Open Source to developers is kinda iffy - but what do you gain ? i.e. less time needed to maintain, faster development etc.
Hope making a summary will help you put things in perspective.

Which Version of Python to Use for Maximum Compatibility

If I was going to start an open source project using Python what version should I use to ensure that the vast majority of users can use it on their system?
I'm the kind of person who quickly jumps to the next version (which I'll do when Python 3 comes out) but many people may be more conservative if their current version seems to be working fine. What version would hit the sweet spot but still allow me to enjoy the newest and coolest language enhancements?

As python is in kind of an transition phase towards python 3 with breaking backward compatibility I don't think it is a good idea to go python 3 only. Based on the time line there will be at least one or two following releases of the 2.x series after 2.6/3.0 in october.
Beside not having python 3 available on your target platforms, it will take some time until important external python libraries will be ported and usable on python 3.
So as Matthew suggests staying at 2.4/2.5 and keeping the transition plan to python 3 in mind is a solid choice.

I've not seen a system with less than 2.3 installed for some time. Mostly 2.4+ is installed by default for most OS I use now. 2.3 is just on an older Solaris machine. Linux distros tend to have 2.4+, as does OS X.
IIRC, 2.4 has a lot of the features 2.5 does, but usable only with
from __future__ import *

You can use different versions of python on each machine.
Coding something new, I would not use anything less than python2.5. You can do apt-get install python2.5 on stock debian stable.
For windows, don't really worry about it. It's very easy to install the python2.5 msi.
If the users can't be bothered to do that, you can deploy an executable with py2exe (so simple) and build an installer with inno setup (again simple) then it will behave like a standard windows application and will use its own python dlls, so no need to have python installed.
Like Peter said: keep in mind the transition to 3.0 but don't build on it yet.

Python 2.3, or 2.2 if you can live without the many modules that were added (e.g. datetime, csv, logging, optparse, zipimport), aren't using SSL, and are willing to add boilerplate for True/False.
2.4 added decorators. generator expressions, reversed(), sorted(), and the subprocess and decimal modules. Although these are all nice, it's easy to write Pythonic code without them (assuming that your project wouldn't make heavy use of them).
2.5 added with, relative imports, better 64 bit support, and quite a bit of speed. You could live without all of those easily enough.
2.6 isn't released (although it's very close), so while it might appeal to developers, it doesn't have the compatibility you're after.
Take a look at the release notes for 2.3, 2.4, 2.5, and the upcoming 2.6 (use http://www.python.org/download/releases/2.Y/highlights/ where 'Y' is the minor version).
FWIW, for SpamBayes we support 2.2 and above (2.2 requires installing the email package separately). This isn't overly taxing, but the 2.3 additions are useful enough and 2.3 old enough that we'll probably drop 2.2 before long.

If the project is going to be mainstream and will be run on Linux the only sensible choise is 2.4 - just because it is a pain to get anything else installed as default on Enterprise Linuxes.
In any case, any modern OS will/can have 2.4 or newer.

You should use Python 2.7, the final major version of Python 2.
Python 3.x currently has limited 3rd-party library support, and is often not installed by default. So you are looking at the 2.x series.
Python 2.7 is essentially fully backwards-compatible with earlier 2.xs. In addition, it can give deprecation warnings about things that won't work in Python 3. (Particularly, it will pay to maintain unit tests, and to be pedantic about Unicode- vs. byte-strings.) The warnings will force you to write good code that the automated 2to3 tool will be able to translate to Python 3.
Guido van Rossum officially recommends maintaining a single Python 2 code-base, and using 2to3 together with unit testing to produce compatible releases for Python 2 and 3. (Since PEP 3000 was written, Python 2.6 has been superseded by 2.7.)