PEP-317

[Roy Smith]

"Donn Cave" <donn at drizzle.com> wrote:
> "Never" would be a reasonable schedule, hope that's constructive.
> The reasons advanced for breaking currently valid "raise" statements
> would be excellent for a newly introduced feature, but those same
> excellent sentiments add up to "gratuitous" here.  Break things
> only when necessary, not just for the sake of tidiness.

I have to agree with that.  I'm all for making stuff better, but if it 
means breaking something that currently works, it's a bad idea.  I'd 
much rather live with a few "historical warts" in the language than have 
to put up with working code breaking.

I've got python apps that I wrote 4-5 years ago at a previous job that 
are still in production use.  I don't work there any more.  Let's say 
somebody were to upgrade the python interpreter running on that system.  
All of a sudden, stuff that had been working for eons would stop 
working.  Stuff that nobody is really familiar with anymore.

Let's face it, getting Python mindshare is often an uphill battle.  In 
the scenario above, it's not hard to imagine some PHB saying, "Screw 
that Python crap, somebody rewrite that in a language I can trust".