[Python-bugs-list] [ python-Feature Requests-644940 ] Support file path concat with "/"

[noreply@sourceforge.net]

Feature Requests item #644940, was opened at 2002-11-27 21:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark VanTassel (markvantassel)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Support file path concat with "/" 

Initial Comment:
A very useful feature is to overload the "/" operator for 
strings to support path concatenation - that is, to concat 
the left and right arguments in such a way that there is 
exactly one slash between them, regardless of which 
argument(s) did or didn't include slashes:

dir = "/this/that"
file = "whatever.py"
print dir / file 
#prints "/this/that/whatever.py"

It seems silly, but when you're not 100% in control of 
things (such as when reading paths from config files, 
user input, etc), it's great to be sure that the right thing 
will happen without writing/testing a lot of icky code. 
And even when you are 100% in control, it's nice to not 
have to worry about it so much.

This doesn't seem to conflict with any existing usage or 
syntax, so I don't think it can possibly break any 
existing behaviour (except, of course, those who were 
counting on having an exception thrown!)

I've already coded this as a minor tweak to the Python 
2.2.2 release, and I'd be happy to share the fix with the 
powers that be, if there's general concensus that this is 
a good thing. Feedback is solicited and appreciated 
(this is my first foray into open-source development, so 
be gentle!)

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-12-03 19:24

Message:
Logged In: YES 
user_id=21627

Please notice that there is an established function in
Python that has the same effect: os.path.join:

>>> dir = "/this/that"
>>> file = "whatever.py"
>>> import os
>>> print os.path.join(dir,file)
/this/that/whatever.py

There is, in general, reluctance to add new syntax to Python
if you can achieve the same effect with a function - in
particular if the function has been there for a long time.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-29 21:00

Message:
Logged In: YES 
user_id=33168

How often do you really need this?  Is it that bad/hard to
use os.path.join?

There are always problems with adding new features which
overload existing operations, like using "/".  It's true
that it would raise an exception today, so could be
acceptable to implement str / str.  However, unless this is
for a very common task, is it worth it?  Using / to join
path components is not obvious to me.  I doubt it would be
generally obvious.  Would it be confusing?

There is the cost of not being able to use / for something
possibly more meaningful and more common if this were
implemented.

----------------------------------------------------------------------

Comment By: Mark VanTassel (markvantassel)
Date: 2002-11-29 14:02

Message:
Logged In: YES 
user_id=658048

Having used a C++ string class with overloaded "/", I can 
assure you it's quite useful. Aside from the executable being 
about 100 bytes larger, I can't see how it hurts anything.

The righthandside absolute path (assuming you mean with a 
non-empty leftside path) is a semantic problem. You could 
reasonably say that if the right side starts with a slash, ignore 
the left side.

Similarly, if the rightside starts with "X:" (under windows), 
ignore the left side. The Mac version could certainly insert ":" 
chars instead of slashes.

Note, though, that the "/" operator isn't intended to solve all 
the worlds problems - if you have quirky path-usage rules, 
you'll probably have to implement them yourself regardless.
This is just to make the relatively simple stuff (hopefully the 
80% case) drop-dead simple and avoid strange errors when 
the user improperly specifies a directory (or a file) in a config 
file or whatever.

URLs are a more intriguing issue - they were far less 
important the first time I implemented this. I suppose a 
subclass would be best.

And while OS-specific flavors might be nice add-ons (for 
those rare cases when a Mac is concatenating paths meant 
for evaluation on a windows machine, etc), I strongly believe 
that the "default" behaviour should be appropriate for the 
current OS, thereby promoting code portability.

Question: Would it be too ugly (or too difficult) to have a prefix 
character (analogous to the "r" for raw strings) to specify that 
a literal string is of one of the above-suggested subtypes?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-11-29 10:46

Message:
Logged In: YES 
user_id=45365

Apart from the question of whether pathname concatenation is important enough to add a special operator on the string type for (I think not), there are lots of boundary issues with your proposal.

For instance, how about a righthandside absolute path? How about two paths with C: style disks in them on Windows? How about Macintosh pathnames (colon-separated, with relative paths starting with a colon)? Or, why does it concatenate pathnames in the first place, and not URLs (makes a difference on Mac)?

If you want to continue down this trail I would suggest the first step is to subclass strings. You can then have separate subclasses for Windows paths, Unix paths, URLs, Mac paths, etc.

----------------------------------------------------------------------

Comment By: Mark VanTassel (markvantassel)
Date: 2002-11-27 21:49

Message:
Logged In: YES 
user_id=658048

P.S. There are a few loose ends for discussion:

1) What to do with empty strings? My current implementation 
doesn't do anything special, so dir/"" ends with a slash, ""/file 
starts with a slash, and ""/"" is a slash. If someone thinks 
different behaviour would be better, I'm open to alternatives.

2) What about back slashes on Windows (my native platform, 
actually)? My version removes trailing slashes and 
backslashes from the 1st arg, and removes leading slashes 
and backslashes from the 2nd ard, and then puts a 
backslash between them... but again I'm open to alternatives.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470