[Python-Dev] A wart which should have been repaired in 3.0?

[Nick Coghlan]

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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------