[Python-Dev] RELEASED Python 3.0 final

[glyph at divmod.com]

On 4 Dec, 07:12 pm, python at rcn.com wrote:
>The latter statement worries me.  It seems to unnecessarily undermine
>adoption of 3.0.  It essentially says, "don't use this".  Is that what 
>we want?

I think so.  The default case, the case of the user without the 
wherewithal to understand the nuances of the distinction between 2.x and 
3.x, is a user who should use 2.x.  If the user understands what's going 
on, they're not going to pay attention to such a notice anyway.  I think 
Barry did a great job phrasing this; the language in this comment has to 
be strong enough to counter the prevailing wisdom that "higher version 
number = better".  I think it did that without being overly negative.

For most users, especially new users who have yet to be impressed with 
Python's power, 2.x is much better.  It's not like "library support" is 
one small check-box on the language's feature sheet: most of the 
attractive things about Python are libraries.  Of course I am not free 
from bias, being the author of many libraries myself, but it was other 
libraries that drew me to Python in the first place.

If you're writing an application with 2.x, you get GTK, Qt, PyGame, PIL, 
NumPy, and of course the wonderful Twisted.  With 3.0, you get... 
Tkinter, and ... pywin32, I guess, although I can't find the download on 
sourceforge?  A fork of django that "just barely works"?  A "half 
broken" email module in the stdlib?  All things which you can *also* get 
on 2.x, modulo the "barely works" and "half broken".

If you're writing a library, even if you intend to support py3 as a 
platform on day one, you could reach a much wider audience by simply 
writing in 2to3-friendly style and releasing 2.x source.  Writing a 
3.x-only library will artificially limit your audience and make it much 
harder to combine your library with *other* useful Python libraries 
which have not yet been ported.  There's no 3to2 yet, and maybe there 
never will be.  ("py3to2" looks like an interesting project, but seems 
to be misleadingly named, since I don't think it will help you run your 
3.x-source programs on a stock 2.x VM).

The third (albeit much less likely) option is that you're learning 
Python to learn to interact with a system that's scriptable in embedded 
Python, like Blender or Gimp.  I don't think there's a single system of 
that variety which uses 3.0 yet, and these will likely be even slower to 
move than libraries.  So if the user downloads Python 3 and the 
accompanying tutorial they're likely to be confused when they try to use 
their newly-acquired knowledge to script the tool in question.

Of course, in the long term, maintenance for 2.x is going away and we 
are all being gently herded to 3.x.  Aren't the things I just talked 
about the reason for the continued maintenance of 2.x, though?

It makes sense to talk about 3.1 and beyond, because that points to some 
continuity with 3.0.  It doesn't make sense to say "don't use it", but 
it does make sense to say "use it to get ready for the eventual 
direction of the language".  For example, my experience so far suggests 
that the only motion on Twisted towards 3.x during the 3.0.x/2.6.x cycle 
will be us reporting bugs in 2to3 and in the new version of the stdlib. 
3.1 is likely to be the first version we could realistically target.  I 
am sure that many other libraries are in a similar situation, since 2to3 
has not yet been exposed to a wide variety of ugly, real-world code, and 
nobody's maintaining an #ifdef'd up C extension module yet.  By the time 
3.1 rolls around, we will all know how this migration strategy is really 
working out, and will be able to predict the likely migration timetable 
for various libraries with some degree of accuracy.