Hi Unnati and Prithvi --
Thanks for the additional information. Personally, I'd be OK with either:
a) only having the Chapel routine return common paths, as you've
implemented it
b) supporting an optional bool argument (say, 'validPath=true') that would
allow someone to opt into the behavior that includes 'foo' if they
didn't like your choice.
Left to my own devices, I'd probably go with (a) on the argument that it
seems like the more correct / likely thing one would want from the Path
module. And if someone really wanted the other behavior down the road, we
could either add a commonPrefix routine to the string module (if we don't
already) or we could add the bool argument to your routine at that time
(which should not break any pre-existing codes).
This discussion also makes me wonder whether the routine you've developed
should be renamed 'commonPath' rather than 'commonPrefix'. While it's
true that it's defined in the 'Path' module, since many Chapel programs
don't use fully qualified names, 'commonPath' seems like it might be more
intuitive / self-descriptive (and, it sounds as though someone coming from
Python may look for that name anyway?). OTOH, calling it that would
probably preclude adding the boolean now or later (because it seems less
sensical to say "give me the common path, but it need not be a path").
But I'd still be OK with that and suggest we add String.commonPrefix()
if/when we want that behavior.
I'm definitely curious what others think as well,
-Brad
PS -- In retrospect, I regret that we aren't having this discussion over
on the GitHub issue to capture it for posterity and code formatting... We
may want to capture some of this discussion there as it resolves.
On Thu, 1 Mar 2018, Unnati Parekh wrote:
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
