[Python-3000] Builtin iterator type

Mon Nov 20 18:06:58 CET 2006

On 11/20/06, Michael Urman <murman at gmail.com> wrote:
> > However, of you know ahead of time that not all birds can fly you can
> > design for this.
>
> To use a more relevant example, how about file-like-objects and
> nameless files. Any class derived from file can be expected to have
> the name member. However several files have nonsense names:
>
> >>> f = tempfile.TemporaryFile()
> >>> isinstance(f, file)
> True
> >>> f.name, sys.stdin.name, sys.stdout.name
> ('<fdopen>', '<stdin>', '<stdout>')
>
> Furthermore arbitrary file-like objects may or may not see it as
> necessary to provide a name attribute:
>
> >>> f = urllib.urlopen('http://www.google.com')
> >>> isinstance(f, file)
> False
> >>> f.read(62)
> '<html><head><meta http-equiv="content-type" content="text/html'
> >>> f.name
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: addinfourl instance has no attribute 'name'
>
> I'm skeptical that class hierarchy design time is a good time to
> target. Class hierarchies should be relatively rare in python,
> maintenance is more common, and developers new to your class hierarchy
> not knowing the special cases are likely to make incorrect
> assumptions. Both of the following are wrong, but are easy assumptions
> to have made:
>
>   1) All file-like objects have a usable name
>   2) All file-like objects have a name attribute

One issue here is the (informal) name of the protocol "file-like",
which although it adds the suffix "like" and gives a clue it's not
necessarily about real files, it makes such erroneous assumptions more
likely. OTOH if we were talking about, say, "character streams", the
expectation of having a name would be less justified.

By the way, file-like is a good example of a protocol that would
benefit from being less fuzzy and informal. For one, it would give a
clear definition of the protocol attributes; you can't know this just
by looking at the concrete file type and assume that all file-like
objects should support the same attributes ('name' is one example that
makes sense to real files mainly). For two, it would give default
implementations for methods that can be defined through others, e.g.
readline() and readlines() can be implemented using read() (of course
a subclass may override these to provide more efficient
implementations, just as with dictmixin). Anyone else that would find
a 'stream' (or 'charstream' or 'StreamMixin' or whatever) class a good
idea?

George