Fw: [Types-sig] Sample declarations

[Tim Hochberg]

I originally sent this with a gif showing a rough type hiearchy. This made
the message too long and it got held by the list software. In retrospect,
that image wasn't that important anyway, so I'm resending this without it.
The list administrator (Paul?) can feel free to delete the original message.

 > [GvR]
 [SNIP]
 > > - Similar questions can be asked about streams.
 > >
 > > In short, it looks (and I am as surprised as you are!!!) like we will
 > > need to agree on the Python type hierarchy before we can ever hope to
 > > agree on any kind of type assertions.  That is, unless you make the
 > > type assertions only deal with the concrete types.  But that wouldn't
 > > be very useful, as there are lots of cases where you want to express
 > > that you accept any kind of sequence, mapping, file, etc.
 [Samuele Pedroni]
 > The point is that until now python let one be lazy and free.
 > Clearly we can introduce a hierarchy of so to say abstract classes,
 > that at least mention all the methods that a class should implement
 > to be a Mapping, a Sequence, ...
 > But my feeling is that at the moment python is more like Self or
Smalltalk
 > an input is fine for an algorithm as long it defines just the required
 > "selectors" (methods) in a meaningful way.
 > Is that a bad practice wrt to err&doc? probably yes but allows for
 > flexibility and quick coding.
 > If for example the whole std lib will introduce typechecking that
 > could be a problem.

 Ideally, adding type checking to the standard library shouldn't make any
 difference; the type checking would only squawk when a callable was passed
 an object that was going to cause failure anyway. Whether a type hierarchy
 can be designed that's expressive enough to allow this without being
 overwhelming is another matter.

 I'm NOT attaching a picture I put together to try to make sense of how the
 sequence/mapping types fit together. Every time I look at it I end up
having
 to make it more complicated, so I'm sure the current version is flawed, but
 I include it to give people something concrete to think about. Note that
 I've assumed that something useful comes out of the iter-sig. However, in
 light of Samuele's comment, I think this not the right approach. The right
 approach is to look to the standard library. Somebody or group of bodies
 should look through a sampling of the standard library and see what useful
 type information (in terms of method signatures) would be for
 sequence/mapping types. Either order (a useful set of sequence/mapping
 types) or chaos will emerge.

 For example, a quicklook at getopt.getopt (chosen randomly):

def getopt(args, shortopts, longopts = []):
  #...

args: __nonzero__ or __len__, __getitem, and __getslice__(*), members are
strings
shortopts: __getitem__ and __len__, members are strings
longopts: string | something that can be turned into a list (__len__ and
 __getitem__?), members are strings.

 [(*)  Didn't __getslice__ get subsumed by getitem?]

>From this tiny little example one gets the idea that __len__ and __getitem__
(and __getslice__?) are perhaps the important elements of some type of
sequencehood. However, to really get a reliable idea many more chunks of the
standard library would have to be examined.

We can think about type theory all we want, but it doesn't help unless it
describes real code usefully. So, we might as well looking at the code.

-tim