Hi,
We read about the same to find that many users were indeed surprised by the
function 'os.path.commonprefix' returning invalid paths, present as it was
in the Path library. And so in the later versions of Python, there is this
function 'os.path.commonpath', that returns only valid paths (the way it is
implemented right now).
As suggested, allowing the user to opt for either of the implementations
seems reasonable.
It would be great if everyone could share their views on the same till next
Tuesday so that we can keep in mind the suggestions made and the merge can
happen accordlingly.
Thanks,
Unnati and Prithvi
On 28 February 2018 at 00:05, Brad Chamberlain <[email protected]> wrote:
>
> Hi Unnati and Prithvi --
>
> I'm not a Python user, but based on the name of the function, the
> inclusion of 'foo' in the result feels surprising to me (i.e., I like your
> interpretation better, intuitively).
>
> As Michael says, searching to see if there's any rationale for Python's
> choice (or any frustration among users that it behaves this way) would be
> interesting. And I like his intuition that including 'foo' feels more like
> simple "find the prefix of these strings" rather than a path-based function.
>
> One potential way to have our cake and eat it too would be to have the
> function take an optional bool arg which would allow a user to opt into
> either interpretation. Of course, that would still require making a choice
> as to what the default should be.
>
> Thanks for your effort on this routine,
> -Brad
>
>
>
> On Tue, 27 Feb 2018, Michael Ferguson wrote:
>
> Hi -
>>
>> It looks like Python 'os.path.commonprefix' returns the version including
>> foo, in your example.
>> I personally wonder if that should just be *string* commonprefix and if
>> *path* commonprefix should
>> return only whole path components.
>>
>> Anybody have a sense for where this might be used - and if so, which
>> interpretation is
>> more likely to be useful? Or why the Python library is this way?
>>
>> Thanks,
>>
>> -michael
>>
>> Hi!
>>
>> My teammate and I are applying in this project for RGSoC this year.
>>
>> We have worked on the commonPrefix function for the Path library and
>> have implemented it differently from what was originally proposed and would
>> like to discuss the same.
>>
>>
>> The function was originally proposed to take a list of strings (paths)
>> as input and return the longest common path prefix. Thus, if given a list
>> of paths like '/Users/foo.chpl', '/Users/foo.good' the function would
>> return '/Users/foo' which is not a valid path.
>>
>>
>> Instead, our implementation of the function returns only valid path
>> prefixes ('/Users' in this case).
>>
>>
>> So, we would like know how reasonable would this approach be and would
>> it be preferable to have both implementations?
>>
>>
>> Thanks,
>>
>> Unnati and Prithvi
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Chapel-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
