py3k s***s

[Sverker Nilsson]

Thanks for your well-formulated article

Providing the Python infrastructure with my program doesn't apply
since I am providing a program/library that is intended to be
general.
So it doesn't help.

All that py3k does to me, it seems, is some extra  work.

To be frank, no innovation. Just changes, no progress. And yes, I am
p****d.

Somebody compared it with MS stuff. Yes.

Nothing personal, I appreciate Your comment. And all others.

Sverker


On Apr 15, 7:09 pm, Donn Cave <d... at u.washington.edu> wrote:
> In article
> <11567a1a-b184-42e6-bbf3-a655736c1... at p25g2000hsf.googlegroups.com>,
>  Sverker Nilsson <s... at sncs.se> 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
>
> Welcome to the world of Python.
>
> There was a period of relative stability in the '90s, culminating
> with version 1.5.2, which just happens to be about the time that
> people started taking Python seriously.  It turns out that this
> stability was only due to lack of resources, though.
>
> I think most of us are working under two imperatives here that
> really boil down to the same thing:   we want a programming
> language that lets us focus on the goal of the program.  On
> one hand, that means things like automatic memory management
> that are brought to us by newer languages (i.e., less than
> 30 years old.)  On the other hand it means stability that allows
> our deployed code to go on working without constant intervention,
> which usually we find in languages that have become utterly boring
> and out of fashion (i.e., more than 30 years old.)
>
> It's hard to find a good compromise between these two, in an
> interpreted language.  I don't know what the current party line
> may be on this matter, but some years back it was that you should
> consider the interpreter part of your application.  That is, each
> application should deploy with its own dedicated Python interpreter,
> complete with libraries and everything.  This naturally relieves
> some of the maintenance issues, since at least you can upgrade on
> your own schedule, but of course it has its costs too.  Anyone who
> might be thinking about using Python for an application should
> seriously think about this.
>
>    Donn Cave, d... at u.washington.edu