RetroSearch Browse

Wed Jan 25 22:30:02 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-January/060062.html

[Ian Bicking]
>Losing .open() would make it much harder for anyone wanting to write, 
>say, a URI library that implements the Path API.

[John]
> Why?  Could you expand a bit?
> 
> What's wrong with urlopen(filesystem_path_instance) ?

[Ian]
>    def read_config(path):
>        text = path.open().read()
>        ... do something ...

I should have expected that answer, but couldn't believe that you think
it's a good idea to implement that obese filesystem path API for URLs ;-)

Shouldn't we instead have:

 a) .open()-able objects blessed in the stdlib & stdlib docs, as a
separate interface from the path interface (I guess that would be an
argument in favour of path implementing that one-method interface, as long
as it's not tied too tightly to the fat path interface)

 b) a path object with a thinner interface (I know you've already
expressed that preference yourself...)?

John

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-January/060062.html below:

[Python-Dev] The path module PEP