Re: [Python-Dev] A wart which should have been repaired in 3.0?
pobox.com> writes: > You could I suppose though that would just be adding another hack on top of > existing questionable behavior. Agreed. We should fix the original function so that it has the obvious, intented effect. Leaving the buggy function in place and adding another function with the proper behaviour sounds ridiculous. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
>> You could I suppose though that would just be adding another hack on >> top of existing questionable behavior. Antoine> Agreed. We should fix the original function so that it has the Antoine> obvious, intented effect. Leaving the buggy function in place Antoine> and adding another function with the proper behaviour sounds Antoine> ridiculous. If we add commonpath or commonpathprefix or pathprefix, or whatever, then find someplace to move the existing commonprefix function (maybe to the string module or as a class method of string objects?) then could we make a 2to3 fixer for this? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
pobox.com> writes: > > If we add commonpath or commonpathprefix or pathprefix, or whatever, then > find someplace to move the existing commonprefix function (maybe to the > string module or as a class method of string objects?) then could we make a > 2to3 fixer for this? IMHO it's a bug, the py3k migration process needn't apply. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
Antoine Pitrou wrote: > pobox.com> writes: >> If we add commonpath or commonpathprefix or pathprefix, or whatever, then >> find someplace to move the existing commonprefix function (maybe to the >> string module or as a class method of string objects?) then could we make a >> 2to3 fixer for this? > > IMHO it's a bug, the py3k migration process needn't apply. 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". It's brokenness isn't obvious at all to me - it just doesn't do what you want it to do. Adding a separate function called "os.path.commonpath" with the behaviour Skip wants sounds like *exactly* the right answer to me. Cheers, Nick. * entries = os.listdir() candidates = [e for e in entries if e.startswith(typed)] if len(candidates) > 1: tab_result = os.path.commonprefix(entries) elif candidates: tab_result = candidates[0] else: tab_result = typed -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
Nick Coghlan 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
Antoine Pitrou wrote: > Nick Coghlan 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 | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
