Python 3

[Alf P. Steinbach]

* Steven D'Aprano:
> On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote:
> 
>> Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au> writes:
>>
>>> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
>>>
>>>> Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au> writes:
>>>>> Why would I want to use an already existing library that is fast,
>>>>> well- written and well-supported, when I can toss together a nasty
>>>>> kludge myself?
>>>> Because using that library will ensure you can't migrate to Python 3
>>>> any time soon?
>>> Why would I want to migrate to Python 3 any time soon?
>> Sounds like you've answered the questions posed, then. Good for you!
> 
> I was actually only being *half* tongue in cheek, which is why I left out 
> the smiley.
> 
> On the python-dev list at the moment is a lot of discussion on why uptake 
> of Python 3.1 has been slower than hoped. But one of the things that 
> people haven't really discussed -- or at least that I haven't seen -- is 
> why one would prefer 3.1 over 2.5 or 2.6.
> 
> I've played around with 3.0, and I've read the What's New for 3.1 (and am 
> installing 3.1 now), and while the changes look nice, I'm not sure that 
> they're nice enough to deal with the pain of 2to3 migration.
> 
> So how about that, 3.1 fans? What are the most compelling reasons for you 
> that convinced you to change?

Since I'm just learning Python and am an utter Python novice this might not 
amount to much, but it's in the nature of language evolution that the new more 
or less incompatible version *does* become the dominant one, and for new things 
it's then a good idea to adopt the coming in future generally used version of 
the language, instead of being left in a quagmire trying to catch up with new 
versions of tools and libs suddenly not so compatible with the old code.

This happened with e.g. C++ standardization in 1998. The whole standard library 
was revamped and put in a namespace, and old headers like [iostream.h] were 
removed. And as with the Python "/" operator core language functionality was 
changed: in C++98 'new' suddenly threw (Pythoneese raised) an exception instead 
of returning 0 on failure, and templates were suddenly "two phase" with quite 
different semantics, so that much old code didn't even compile, and when it did, 
didn't work correctly.

But those who chose to stay behind paid and still for some pay the price, having 
to use ages old tools and libs. One amusing or sad (depending one's point of 
view) variant was where firms chose to get along with the language evolution, 
tools etc., but still restrict themselves to not only pre-standard C++ but some 
early 1980's version, not much more than "C with classes" or "better C". For 
example, at Google they generally don't use C++ exceptions, presumably because 
they have a large code base of non-exception-safe code. Still, assuming that's 
the rationale, it would surprise me if they don't use exceptions in their new code.

This is perhaps an heretical view, that the new language version's advantages 
don't matter so much as the fact that the new language version is incompatible, 
viewing that incompatibility as a /reason/ to change.

But I think it's realistic; getting the advantages (such as with Python 3.x 
improved efficiency for range etc., and thus also more clear notation) is just 
an added bonus.


Cheers & hth.,

- Alf