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
