Hi -
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).
Given that experience in Python, I suggest that we simply implement commonPath
and leave commonPrefix for another day.
(Your current draft implementation of commonPrefix would just be renamed to
commonPath).
Thanks for looking in to it,
-michael
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 <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
