[Python-Dev] The path module PEP
Ian Bicking
ianb at colorstudy.com
Tue Jan 24 22:37:46 CET 2006
Jason Orendorff wrote:
>> [...]omitted:
>> * Function for opening a path - better handled by the builtin
>> open().
>
>
> Aside: I added this to support a few people who liked the idea of
> "openable objects", meaning anything that has .open(), analogous to
> "writeable objects" being anything with .write(). I don't use it
> personally.
Losing .open() would make it much harder for anyone wanting to write,
say, a URI library that implements the Path API.
> I suspect you'll be asked to change the PEP to remove __div__ for
> starters, in which case I propose using the Path constructor as the
> replacement for os.path.join(). In that case, Path.joinpath can be
> dropped.
I'm -1 on this too. This means people will be hardcoding the specific
class they expect, so you can't pass in other classes. E.g., this will
fail:
def read_config(home_dir):
f = open(Path(home_dir, '.config_file'))
c = f.read()
f.close()
return c
read_config(URI('http://localhost/foo'))
I'm personally +1 on /. I think people who think it is confusing are
giving a knee-jerk reaction. It's very easy to tell the difference
between file-related code and math-related code, and / is currently only
used for math. In contrast, + is used for concatenation and addition,
and these are far more ambiguous from context -- but still it doesn't
cause that many problems. But barring /, .joinpath() should remain.
Too bad there isn't a shorter name, except .join() which is taken.
I would also, though, note that there are some security issues. When
you use open() or other path-related functions, you *know* you are doing
filesystem operations. You can't be getting some weird object that does
who-knows-what. For the most part if you can get an arbitrary object
into the system then the system is just broken, but I can imagine cases
where this encourages people to do bad things. I only bring this up
because it reminds me of PHP allowed over-the-net includes, which always
seemed like a bad idea.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Python-Dev
mailing list