Bugs in CPython 3.1.1 [wave.py]

[Lie Ryan]

Alf P. Steinbach wrote:
> * Stefan Behnel:
>> Alf P. Steinbach, 13.01.2010 06:39:
>>> * Steven D'Aprano:
>>>> On Tue, 12 Jan 2010 23:42:28 +0100, Alf P. Steinbach wrote:
>>>>> It is hopeless, especially for a newbie, to create correct Python
>>>>> 2.x+3.x compatible code, except totally trivial stuff of course.
>>>>
>>>> So you allege, but André points out that there are existing,
>>>> non-trivial applications that work unmodified under both Python 2.x
>>>> and 3.x. For example, CherryPy:
>>>>
>>>> http://www.cherrypy.org/wiki/WhatsNewIn32
>>>>
>>>> You're welcome to your own opinion, of course, but not your own
>>>> reality, and the reality is that it is NOT "hopeless" to write
>>>> correct Python code that operates under both 2.6 and 3.x. It's not
>>>> hopeless because it's been done. You might even be able to target
>>>> versions older than 2.6 if you really work at it, as CherryPy does.
>>>>
>>>> Continuing to assert something which is demonstrably untrue simply
>>>> means you lose credibility among those who are familiar with Python.
>>>
>>> You're confusing the existence of special cases where something has
>>> been done, at great cost, with a belief that it's practical to do so
>>> in general.
>>
>> Unless you can prove that it's *not* practical in general, you will
>> have to live with the fact that it was, and continues to be, practical
>> for existing code bases (and certainly for new code), so it clearly is
>> not hopeless to do so, not even "in general".
> 
> Simple proof: Python 3.x still lacks widespread usage. :-)

That's not a really sound proof, there was a after the release of 2.6
that people start migrating their code from 2.5; migration to 3.x is not
going to be different. Even nowadays, there are still a lot of codes
targeted for python 2.5 or 2.4 that will never have a chance to be
ported to 2.6.

It is valid to argue that the time gap is a bit longer in python 3.x;
but don't forget that 3.0 is intended to be a "preview" version, 3.1 a
beta and 3.2 a more stable production release. The recommended migration
path is to port to 2.x code to 2.6 then to 2.7 and then to 3.x. So to
establish a fairer comparison of the migration gap, you would have to
measure the adoption time between 2.7 to 3.2 (or 2.6 to 3.1, but not to
3.0).

We have yet releases 2.7 and 3.2, so it is still not possible to tell
how hard it is people think porting to 3.x is.

> Over in C++-land it's opposite.
> 
> Even the most enhusiastic C++ programmers almost revel in finding 
> faults with the language and its standard library, tools etc. And
> I think that's because there's no inferiority complex, or very
> little of it. So, repeating: Python is a great language, it really
> is, but There Are Issues, of course there are issues, and the best
> way or at least a good way to go about it is adopt that (great,
> but of course has issues) as one's basic view, and be critical.

if what you said is true, that will be a proof that python programmer's
PHI (programmer's happiness index) is higher than C++'s :)