py3k s***s

[Rhamphoryncus]

On Apr 16, 12:10 pm, Aaron Watters <aaron.watt... at gmail.com> wrote:
> On Apr 16, 1:42 pm, Rhamphoryncus <rha... at gmail.com> wrote:
>
> >   The only reason to not make the
> > changes is that old, crufty, unmaintained libraries & applications
> > might depend on them somehow.  If that's more important to you, what
> > you really want is a language who's specs are frozen - much like C
> > effectively is.  I hope python doesn't become that for a long time
> > yet, as there's too much it could do better.
>
> I'm feeling a bit old, crufty, and unmaintained myself,
> but I'll try not to take offense.

No offence meant, even if you do seem a bit set in your ways. ;)


> There is a difference between something that works fine
> until the rug gets pulled out and something that needs fixing.
> It's a shame to junk stuff that works.

The point is, you can't have it both ways.  Either you evolve the
language and break things, or you keep it static and nothing breaks.

In the case of users wanting new versions, they may depend on the very
changes that break your libraries.  There's no solution to that.


> Also in the case of C/java etc changing the infrastructure
> is less scary because you usually find out about problems
> when the compile or link fails.  For Python you may not find
> out about it until the program has been run many times.
> Perhaps this will inspire improved linters and better coding
> practices....

Better coding practises such as extensive unit tests?


> I suppose if the py3k migration inspires tons of
> insomniac young programmers to seek fame and admiration
> by cleaning up ancient libraries, it would be a good
> thing.  It seems to have happened in the Perl4->5
> migration some years ago.  Could happen again.

If they're unmaintained, absolutely, it'd be great for them to get new
maintainers.