Feature Requests item #644940, was opened at 2002-11-27 21:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected 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: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 19:08 Message: Logged In: YES user_id=1188172 I think this can be closed. If someone wants that functionality in the Python distribution, he should ask for a module like http://www.jorendorff.com/articles/python/path/ in the stdlib (which I would support too). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-12-09 19:30 Message: Logged In: YES user_id=89016 IMHO implementing str / str as a duplicate of os.path.join blurs what a string is. The meaning of a type should be tied to the type and not to various sets of operators (for + a str instance is treated as a string, for / as a filename). And if we add /, where should we stop? str.open(), str.exists(), str.stat() etc.? If we duplicate every function in os.path we might get name clashes. IMHO string and filename APIs should be kept separate. So the clearer solution would to be implement a separate filename class. Whether this is a subclass of str or not is IMHO unclear. What about Unicode filenames? ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
