On 11/9/06, Talin <[EMAIL PROTECTED]> wrote: > Mike Orr wrote: > > On 11/9/06, Talin <[EMAIL PROTECTED]> wrote: > >> (This is a good reason to have paths represented as strings instead of > >> as a tuple, since you can't defer interpretation this way with > >> pre-parsed paths.) > > > > Er, is there an API recommendation in there somewhere, or is this just > > philosophy or usage style? > > I am indeed trying to describe a usage style, one that is not only used > by me but by a large number of pre-existing apps. My goal in describing > this is to insure that any new path system allows similar kinds of usage > patterns. > > What I am arguing against is an overly strict and pedantic > interpretation of the differences in path representation across > platforms. True, in theory, you can't compare a windows path with a > posix path, but in practice it generally "just works". > > I sometimes notice a tendency on this list that anything which is not > 100% provably correct should be forbidden, no matter how useful it is. > > Let me give a concrete example: In my TurboGears project, there is a > file called "thes.egg-info/sqlobject.txt" that contains this string: > > history_dir=$base/thes/sqlobject-history > > I didn't write this, it was generated by the 'quickstart' script. I > fully expect to be able to package up my TG app from my OSX machine, > transport it to my Windows box, and have it work. And I would fully > expect to be able to do the same in any future version of TurboGears > running on a future version of Python. > > Now, one can argue that this string is meaningless when taken from one > platform to another, but the only thing that is accomplished by that > argument is to remove functionality that current users find useful and > valuable.
I'm looking for "we need a method named foo with signature bar that does this..." Or "make sure method blah doesn't do this...." Otherwise I don't know what to do with the information. Can you make a use case showing how you'd ideally like to interact with the module (what you'd call) and what it should do, starting wtih a config file fragment and ending with a file operation (mkdir, open, etc). In the case above, the question is how TurboGears would interact with the new path module. First we'd need to know what TG is doing internally now; then we can verify we're not losing any functionality. I would guess TG is doing a text substitution of $base and not even using a join function. That's outside of our control. We know that our join/combine method is tied to a particular platform, and if given two path fragments from that same platform will join them properly. Beyond that all bets are off -- no using the wrong platform class, and no mixing path fragments from different platforms. You can't combine "C:\" and "thes/sqlobject-history" into anything useful. But os.path.join() has the same restrictions. On Windows you're depending on "something below Python" to interpret the forward slashes properly when you do a file operation. This is outside the path module's scope. But it looks like we'll be adding the ability to convert at least some paths from Posix to Windows -- something os.path doesn't do. -- Mike Orr <[EMAIL PROTECTED]> _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
