py3k s***s

[Chris McAloney]

On 15-Apr-08, at 12:30 AM, Sverker Nilsson wrote:
> No one forces me, but sooner or later they will want a Python 3.0 and
> then a 3.1 whatever.
>
> I don't want that fuzz. As about the C versions, I am not that
> worried. What's your point?
>
> I just like want to write a program that will stay working. And maybe
> I can go on with something else hopefully than just compatibility
> fixes. They take some work afterall.
>
> It seems hard with Python. Esp. 2 -> 3

I couldn't help but notice that not only did you not address  
Gabriel's most important question, you excluded it from the quote  
below and changed the comma to a period.  Gabriel said:

"There is a strategy to migrate from 2.x to 3.0, including the 2to3  
tool.
Have you used it?"

*Have* you tried the 2to3 tool?  It might help to lessen your  
concerns a bit.  Yes, Python 3 is different from 2.x, but we've known  
that it was going to be for years and, as has already been pointed  
out, the devs are being very careful to minimize the pain that the  
changes will inflict on Python programmers, with tools such as 2to3.

Chris

> On Apr 15, 5:41 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> wrote:
>> En Mon, 14 Apr 2008 23:38:56 -0300, Sverker Nilsson <s... at sncs.se>  
>> escribió:
>>
>>
>>
>>> On Apr 15, 3:50 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
>>> wrote:
>>>> En Mon, 14 Apr 2008 22:02:38 -0300, Sverker Nilsson <s... at sncs.se>
>>>> escribió:
>>
>>>>> I tried out py3k on my project,http://guppy-pe.sf.net
>>
>>>> And what happened?
>>>> I've seen that your project already supports Python 2.6 so the  
>>>> migration
>>>> path to 3.0 should be easy.
>>
>>> 2.6 was no big deal, It was an annoyance that they had to make  
>>> 'as' a
>>> reserved word. Annoyances were also with 2.4, and 2.5. No big
>>> problems, I could make guppy backwards compatible to 2.3. But that
>>> seems not to be possible with Python 3.x ... it is a MUCH bigger
>>> change. And it would require a fork of the code bases, in C,  
>>> Guido has
>>> written tha or to sprinkle with #ifdefs. Would not happen soon  
>>> for me.
>>> It takes some work anyways. Do you volunteer, Guido van Rossum? :-)
>>
>>> It's not exactly easy. Perhaps not very hard anyways. But think of
>>> 1000's of such projects. How many do you think there are? I think
>>> many. How many do yo think care? I think few.
>>
>>> When it has been the fuzz with versions before, then I could have  
>>> the
>>> same code still work with older versions. But now it seems I have to
>>> fork TWO codes. It's becoming too much. Think of the time you could
>>> write a program in C or even C++ and then it'll work. How do you  
>>> think
>>> eg writers of bash or other unix utilities come along. Do they  
>>> have to
>>> rewrite their code each year? No, it stays. And they can be happy
>>> about that, and go on to other things. Why should I have to think
>>> about staying compatible with the newest fancy Python all the  
>>> time? NO
>>> -- but the answer may be, they don't care, though the others (C/C++,
>>> as they rely on) do. :-(
>>
>> You can stay with Python 2.6 and not support 3.0; nobody will  
>> force you to
>> use it. And nobody will come and wipe out your Python  
>> installation, be it
>> 2.6, 2.1 or whatever. And if you still enjoy using Python 1.5,  
>> please keep
>> using it - it won't disappear the day after 3.0 becomes available.
>>
>> Regarding the C language: yes, souce code *had* to be modified for  
>> newer
>> versions of the language and/or compiler. See by example, the new
>> "restrict" keyword in C99, or the boolean names. The C guys are  
>> much more
>> concerned about backwards compatibility than Python, but they can't
>> guarantee that (at risk of freezing the language). The 3.0
>> incompatibilities are all justified, anyway, and Python is  
>> changing (as a
>> language) much more than C - and that's a good thing.
>>
>> There is a strategy to migrate from 2.x to 3.