terry at jon.es
Wed Mar 7 00:16:54 CET 2007
I think there are various good arguments that the current behavior of
splitext isn't optimal. But..... these don't feel strong enough to me to
break existing code or to force people who happen to be in the know to go
hunt down and review old code etc. I don't see the point in doing that,
just to fix something that everyone seems to agree is quite marginal.
There are about 500 hits for splitext\(lang:python at code.google.com.
Many of these blindly use something like
newname = splitext(filename) + '.bak'
You could convincingly argue that these would be "fixed" if the current
behavior were changed. In fact, from looking at 30 examples or so, I
suspect much more code would be fixed than broken. But changing the
behavior of programs doesn't seem like a good idea - even if you can claim
to have fixed them. (This reminds me of SUN adopting a newer malloc in the
mid-90s - it had better internal fragmentation behavior for many requests,
and thereby broke a bunch of working (but in fact buggy) code that was
inadvertently relying on the slop in the older malloc).
I do think the behavior can be improved, and that it should be fixed, but
at a place where other incompatible changes will also be being made, and
where people are already going to have to do serious code review. To me
that argues for fixing it in Py3k. Arguing that it's just a minor change,
and so therefore it can go straight in, seems to also lend support to the
suggestion that it can wait.
More information about the Python-Dev