A modest PEP0238 suggestion

[Chris Barker]

Stephen Horne wrote:

> If you ever had to deal with a customer blaming you for something that
> was due to them getting a DLL change resulting from a different
> applications installation, you'll know what this is like. But in that
> case, it's usually down to their other application having bad install
> logic or due to common system DLLs not maintaining back compatability
> - people understand that in the end.
> 
> This case is due to "the language and run-time environment *I*
> encouraged you to depend on changed its most basic semantics - sorry
> about that." - a little different, really.

How is it different? it seems to me that it is exactly the same as a DLL
not maintaining backward compatability. Which is something that
shouldn't happen, by the way. It is also why DLLs should have version
numbers built in, so that new ones and old ones can be used at the saem
time.

Frankly the easiest soolution to this problem is probably to only make
incompatable changes at a major version number, AND start calling Python
Python3 (then Python4), etc. Come to think of it, this would work for
*nix, because the #! lkine could call Python3, but not for Windows,
where the extension is your only clue. I guess we are back to having a
version indicator built into the code.

-Chris




-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------