Guido van Rossum
Mon, 06 May 2002 12:21:13 -0400
> >> 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).
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):
> 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/)