RetroSearch Browse

Wed Jan 25 00:03:37 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-January/060040.html

Ian Bicking wrote:
> 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'))

It occurs to me that it might be hopeless to expect substitution to work 
generally (at least without a specific thought on the matter) because I 
expect this form will be typical:

   def read_config(path):
       # convert string input to a path (has no effect on Path objects):
       path = Path(path)
       content = path.text()

Since people will be passing strings in to file-related functions for 
the forseeable future, so people will coerce that input to paths 
explicitly whenever they accept a path from a public function.

Now, if there were a way to make sure that "Path(x) is x" is true when x 
is already a Path, and maybe a way to coerce strings to a Path without 
coercing Path-like objects into Path objects, that would help resolve 
the problem.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

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

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

[Python-Dev] The path module PEP