Antoine Pitrou wrote: > Nick Coghlan <ncoghlan <at> gmail.com> writes: >> The current behaviour is exactly what one would need to implement >> bash-style tab completion [1], so I don't get why anyone is calling it >> "useless" or "obviously broken". > > Point taken. > Although the fact that it lives in os.path suggests that the function should > know about path components instead of ignoring their existence... A generic > longest common prefix function would belong elsewhere. > > The issue people are having with the proposal to create a separate function is > that it's a bloat of the API. I don't think the os.path module claims to give > utilities for implementing bash-style tab completion, however it is supposed > to > make manipulation of paths easier -- which returning invalid answers (or, > worse, > valid but intuitively wrong answers) does not.
True, but it's a matter of weighing up the migration cost of the two options: a) Add a new function (e.g. os.path.commonpath) which works on a path component basis. Zero migration cost, minor ongoing cost in explaining the difference between commonpath (with path component based semantics) and commprefix (with character based semantics). That ongoing cost can largely be handled just by referencing the two functions from each other's documentation (note that they will actually be next to each other in the alphabetical list of os.path functions, and the path component based one will appear before the character based one). b) Deprecate the current semantics of os.path.commonprefix (which will likely involve changing the name anyway, since it is easier to deprecate the old semantics when the new semantics have a different name), add the new path component based semantics, add the character-based semantics back somewhere else. This imposes a major migration cost (since the old commonprefix will at least change its name) with significant potential for confusion due to the semantic changes across versions (if the commonprefix name is reused for the new semantics). If we're going to end up with two functions anyway, why mess with the one which is already there and in use for real programs? Just add a new function with the new semantics and be done with it. Anything else will just cause migration pain without any significant counterbalancing benefit. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
