[Python-Dev] backwards compatibility (was: PEP 328 -- relative and multi-line import)

Jewett, Jim J jim.jewett at eds.com
Mon Apr 12 12:11:00 EDT 2004


Bill Janssen:
> Wow.  This seems amazingly user-hostile.  Users (not Python
> developers) download some two or three year old code to do something
> from an online library, like the Vaults of Parnassus, and it just
> breaks because the meaning of "import" has changed.

Andrew Koenig:

> ... If you commit yourself to backward compatibility, you
> wind up with a growing list of decisions for which the 
> default is wrong ... everyone has to remember to override 
> the defaults in lots of everyday circumstances, a mental
> burden that hurts everyone from novices to experts.
 
> ... If you don't commit yourself to backward compatibility,
> you wind up with people downloading old code that breaks 

> The third possibility is to support all alternatives forever, 
> perhaps with a mechanism such as "from __past__ import foo". 

Most changes are for something that was possible but awkward
(inconvenient/ugly/inefficient) in the past.  Would it be 
reasonable to add a magic attribute like 

	__target_python__ = 2.3

Then the interpreter (or an externally maintained translator)
could translate the code automatically, in at least several 
cases.  Older code wouldn't have this, but that already 
suggests it is pre-(something), and the FAQ could say to that
if downloaded code doesn't work, try the automated translator.

In theory, the translator could also work backwards, so that 
maintainers could start to write True instead of 1.

I would be willing to work on such a translator, though I doubt
I could get it to full strength on my own.

-jJ



More information about the Python-Dev mailing list