alfps at start
Nov 4, 2009, 7:33 PM
Post #3 of 8
(306 views)
Permalink
|
* Steven D'Aprano:
> On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote:
>
>> Steven D'Aprano <steven [at] REMOVE> writes:
>>
>>> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
>>>
>>>> Steven D'Aprano <steven [at] REMOVE> 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
--
http://mail.python.org/mailman/listinfo/python-list
|
