Should file(fileinput.input()) work? Currently it raises an exception because fileinput.input() returns neither a string nor a buffer object. If it should work, would it make sense for file() to look for __file__ on instances? Or should fileinput.input() return a subclass of the file object? Or some other solution I haven't thought of? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice.
Should file(fileinput.input()) work? Currently it raises an exception because fileinput.input() returns neither a string nor a buffer object.
What on earth would you want it to do? It doesn't seem to make any sense to me.
If it should work, would it make sense for file() to look for __file__ on instances? Or should fileinput.input() return a subclass of the file object? Or some other solution I haven't thought of?
I have no idea what you want, so I can't answer this. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, May 06, 2002, Guido van Rossum wrote:
Aahz:
Should file(fileinput.input()) work? Currently it raises an exception because fileinput.input() returns neither a string nor a buffer object.
What on earth would you want it to do? It doesn't seem to make any sense to me.
Well, if it should work, it should return the FileInput instance (i.e. return self). On thinking further, I'm going to use a slightly different question divorced from my current problem: What should list(UserList()) return? What about class myList(list): pass l = list(myList()) I suppose this question is related to PEPs 245/246. The broader question is, what should a constructor return when called on a related object or subclass? Getting back to my specific example, I've got this function: def grep(f, regex): f = file(f) regex = re.compile(regex) for line in f: if regex.search(line): yield line I was originally passing in file handles or filenames, demonstrating to the students that calling a constructor on an existing object returns that object if it doesn't need to do any real work. Alex suggested that I use fileinput.input(), whereupon my function blew up. The meta question is, what kind of programming style do we want to push? More smarts on top or bottom? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ See me at OSCON! I'm teaching Python for [Perl] Programmers, a fast intro for all experienced programmers (not just Perl). Early bird ends June 10. http://conferences.oreillynet.com/os2002/
Aahz:
Should file(fileinput.input()) work? Currently it raises an exception because fileinput.input() returns neither a string nor a buffer object.
Guido:
What on earth would you want it to do? It doesn't seem to make any sense to me.
Aahz:
Well, if it should work, it should return the FileInput instance (i.e. return self).
Hm, what analogy would lead you to that thinking? 'file' is the concrete file type.
On thinking further, I'm going to use a slightly different question divorced from my current problem:
What should list(UserList()) return?
That's perfectly well-defined already: a list consisting of the items of the UserList.
What about
class myList(list): pass l = list(myList())
I suppose this question is related to PEPs 245/246. The broader question is, what should a constructor return when called on a related object or subclass?
I don't know where you want to go with this. If Foo is a class, Foo(...) should return a foo instance constructed from the arguments.
Getting back to my specific example, I've got this function:
def grep(f, regex): f = file(f) regex = re.compile(regex) for line in f: if regex.search(line): yield line
I was originally passing in file handles or filenames, demonstrating to the students that calling a constructor on an existing object returns that object if it doesn't need to do any real work.
But that's not even a rule! str() and tuple() can return the original, but only if has exactly the required type. list() always returns a new list -- that's its *purpose*.
Alex suggested that I use fileinput.input(), whereupon my function blew up.
The meta question is, what kind of programming style do we want to push? More smarts on top or bottom?
Teach them Python, please. --Guido van Rossum (home page: http://www.python.org/~guido/)
07/05/2002 2:07:56 AM, Aahz <aahz@pythoncraft.com> wrote: [snip]
Getting back to my specific example, I've got this function:
def grep(f, regex): f = file(f) regex = re.compile(regex) for line in f: if regex.search(line): yield line
I was originally passing in file handles or filenames, demonstrating to the students that calling a constructor on an existing object returns that object if it doesn't need to do any real work.
Since when? Where is this documented? The following simple example concords with the documentation -- "The first two arguments are the same as for stdio's fopen(): filename is the file name to be opened," -- and seems to flatly contradict you. Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import sys foo = file(sys.stdout) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: coercing to Unicode: need string or buffer, file found bar = file(sys.stdin) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: coercing to Unicode: need string or buffer, file found
The fact that str('foo') -> 'foo' is due to the historical fact that str() started out as a builtin str(42) -> '42' and very much later also became a constructor, NOT due to some general rule that ctor(ctor(some_args)) == ctor(some_args).
Alex suggested that I use fileinput.input(), whereupon my function blew up.
Was Alex expecting this to work or to fail?
The meta question is, what kind of programming style do we want to push? More smarts on top or bottom?
A general 'rule' that a constructor should accept an instance of the class and silently do nothing with it would be IMO a totally unnecessary burden on the author of the constructor for no perceived gain.
On Tue, May 07, 2002, John Machin wrote:
Since when? Where is this documented? The following simple example concords with the documentation -- "The first two arguments are the same as for stdio's fopen(): filename is the file name to be opened," -- and seems to flatly contradict you.
Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import sys foo = file(sys.stdout) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: coercing to Unicode: need string or buffer, file found bar = file(sys.stdin) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: coercing to Unicode: need string or buffer, file found
Oops. <Aahz slinks away quietly with egg on face, swearing to test more carefully before posting again> "I know I tested it. Really, I did." -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ See me at OSCON! I'm teaching Python for [Perl] Programmers, a fast intro for all experienced programmers (not just Perl). Early bird ends June 10. http://conferences.oreillynet.com/os2002/
participants (3)
-
Aahz -
Guido van Rossum -
John Machin