py3k s***s

[Sverker Nilsson]

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

Sverker


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.0, including the 2to3 tool.
> Have you used it?
>
> --
> Gabriel Genellina