[Python-Dev] backwards compatibility (was: PEP 328 -- relative and multi-line import) (original) (raw)
Jewett, Jim J jim.jewett at eds.com
Mon Apr 12 12:11:00 EDT 2004
- Previous message: [Python-Dev] pyc/embedded c++ efficiency wrt binary data
- Next message: [Python-Dev] Candidate Function Decorator
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] pyc/embedded c++ efficiency wrt binary data
- Next message: [Python-Dev] Candidate Function Decorator
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]