[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Feb 21 23:45:54 CET 2012
- Previous message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Next message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Feb 22, 2012 at 8:16 AM, Andrew McNabb <amcnabb at mcnabbs.org> wrote:
So, I would be one of those people who would flood in the complaints. :)
As another "you don't know what you're going to break" war story:
In Python 2.5, using "-m" with a package appeared to work, but actually slightly corrupted the import state (mostly in a benign way, but if it ever bit you it would lead to some very confusing behaviour).
Since I'd never intended to allow that to happen (as I knew about the state corruption problem), for 2.6 I added back the "this doesn't work properly" guard that had been present in the earlier versions of 2.5, but had been lost when some duplicate code in pkgutil and runpy was merged into a single version.
Doing that broke things: http://bugs.python.org/issue4195
The basic rule is, if it's documented to work a certain way and the current implementation does work that way, then, someone, somewhere is relying on it working as documented. If it doesn't actually work that way (or the behaviour isn't explicitly documented at all), then we have some leeway to decide whether to bring the docs in line with the actual behaviour or vice-versa. For the Element case though, there's no such discrepancy - the docs and implementation have been consistent for years, so we need to maintain the current behaviour if the C acceleration is going to be used implicitly.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Next message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]