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. Terry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com