On 4 Dec, 07:12 pm, [EMAIL PROTECTED] 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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
