[Python-Dev] file(file)

Guido van Rossum guido at python.org
Fri Jan 12 19:01:51 CET 2007


On 1/12/07, A.M. Kuchling <amk at amk.ca> wrote:
> Forwarded for discussion from http://www.python.org/sf/1633665.
>
> --amk
>
> [forwarded from http://bugs.debian.org/327060]
>
> Many types in Python are idempotent, so that int(1) works
> as expected, float(2.34)==2.34, ''.join('hello')=='hello'
> et cetera.

The join(0 example seems out of place, since it is not a constructor call.

> Why not file()? Currently, file(open(something, 'r')) fails
> with "TypeError: coercing to Unicode: need string or buffer, file found."
>
> Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
> or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
> You should get another independent
> file object that accesses the same file.

That's rather Unix-centric semantics. I don't think the same thing
exists on Windows.

We should also consider the semantics in more detail. Should the seek
position be shared between the two objects? What about buffering?

I'm not sure I understand the use case; I don't believe I've ever felt
the need for this.

> What would be gained?
>
> Primarily, it would allow you to derive classes from file more easily.

Inheritance is overrated.

> At present, if you want to derive like so, you're class can only work
> when passed a file name or buffer.
>
> class file_with_caching(file):
>     def __init__(self, something):
>         file.__init__(self, something)
>
> def etcetera...

But the devil is in the details. What are the "caching" semantics you
want to implement here? Is it appropriate to subclass file for that
purpose, or is it better to use a wrapper (or proxy or delegate)?

> For instance, you have no way of creating a file_with_caching()
> object from the file descriptors returned from os.fork().

I didn't know fork() returned a file descriptor.

> Also, you have no way of taking a file that is already open,
> and creating a file_with_caching() object from it. So,
> you can't use classes derived from file() on the standard input
> or standard output.

More hints that you shouldn't be using inheritance.

> This breaks the nice Linux OS-level definition of a file descriptor.

But a Python file is not a Unix file descriptor. It's more like a C stdio file.

> At the Linux level, you have a nice uniform interface where all
> file descriptors are equally good. At the python level, some
> are better than others. It's a case where Python unnecessarily
> restricts what you can do.

That's what you say. I see a lot of murky thinking.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list