PEP-317

[Michele Simionato]

Roy Smith <roy at panix.com> wrote in message news:<roy-B36181.09340211062003 at reader1.panix.com>...
> "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".

I don't know what is expected for Python 3000, but I would like to
have a compatibility switch on the command line. I think the Python 
3.0 distribution should contain a Python 2.4 or 2.5 or whatever inside it, 
accessible with a switch or changing some settings and file associations. 
Only in this way I would accept code breaking changes. Nothing is more
annoying that a perfectly good old program no more working due to an
upgrade.
In addition to that, there could be an automatic code converter, making
old programs compatible with Python 3000. Any comments about that ?

                                                           Michele