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
prop
>> 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
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 py3
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?
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 sh
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
