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. 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. What would be gained? Primarily, it would allow you to derive classes from file more easily. 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... For instance, you have no way of creating a file_with_caching() object from the file descriptors returned from os.fork(). 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. This breaks the nice Linux OS-level definition of a file descriptor. 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.
On 1/12/07, A.M. Kuchling
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/)
On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
On 1/12/07, A.M. Kuchling
wrote: Many types in Python are idempotent, so that int(1) works as expected, float(2.34)==2.34, ''.join('hello')=='hello' et cetera.
I'm not sure I understand the use case; I don't believe I've ever felt the need for this.
I have oodles of routines of the form def foo(thefile): if type(thefile) == str: thefile = open(thefile) or if not hasattr(thefile, 'read'): thefile = open(thefile) or something similar.
We should also consider the semantics in more detail. Should the seek position be shared between the two objects? What about buffering?
That's definitely the hard part. But it's somewhat similar to
"normal" mutable objects which are (I think always, right?) shallow
copied when used in a constructor.
--
Jack Jansen,
"Jack Jansen"
Terry Reedy schrieb:
| > We should also consider the semantics in more detail. Should the seek | > position be shared between the two objects? What about buffering? | | That's definitely the hard part. But it's somewhat similar to | "normal" mutable objects which are (I think always, right?) shallow | copied when used in a constructor.
But why, in the normal case, do you want a copy? It seems to me that is thefile is a file rather than a string, then that is what you want, and you are asking for 'thefile = file(thefile)' to work just as the iter statement does.
Consider the use case presented before: def foo(thefile): if type(thefile) == str: thefile = open(thefile) Now, if thefile is already a file object, you won't have to close it because it came from somewhere else. If thefile is a string, you'll have to close it at the end. Now, if file(fileobject) would return another file object created by something like os.dup(), you can do def foo(thefile): try: thefile = file(thefile) (...) finally: thefile.close() Georg
On 1/12/07, A.M. Kuchling
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.
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.
For security reasons I might be asking for file's constructor to be removed from the type for Python source code at some point (it can be relocated to an extension module if desired). By forcing people to go through open() to create a file object you can more easily control read/write access to the file system (assuming the proper importation of extension modules has been blocked). Not removing the constructor allows any code that has been explicitly given a file object but not open() to just get the class and call the constructor to open a new file. Don't know when I am gonig to get around to asking for it, though (still have to finish my security work to have something to present to python-dev). -Brett
On 13/01/2007 1.37, Brett Cannon wrote:
For security reasons I might be asking for file's constructor to be removed from the type for Python source code at some point (it can be relocated to an extension module if desired).
Isn't there the wrong list then? I can't see how this can ever happen in the 2.x serie... -- Giovanni Bajo
participants (7)
-
A.M. Kuchling
-
Brett Cannon
-
Georg Brandl
-
Giovanni Bajo
-
Guido van Rossum
-
Jack Jansen
-
Terry Reedy