ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> types-sig
types-sig
Re: [Types-sig] Re: PRE-PROPOSAL: Python Interfaces
by Gordon McMillan other posts by this author
Nov 24 1998 12:42PM messages near this date
[Types-sig] Re: PRE-PROPOSAL: Python Interfaces | [Types-sig] Re: PRE-PROPOSAL: Python Interfaces
[me]

>  > How about FileInput? That's a sequenceish protocol. A read-only,
>  > forward-only, sequential-only sequence. How do we (sensibly and
>  > comprehensibly) capture the fact that most sequenceish protocols will
>  > suffice where a FileInput protocol is required, with the exception of
>  > those stack-ish style sequences?

[Jim Fulton] 
>  I don't know what FileInput is.

Well why didn't "read-only, forward-only, sequential-only sequence" 
define it completely <wink> ? I doubt it's much more helpful to know 
that the only sequence method it implements is __getitem__. Saying 
that's __getitem__(Int) would help a little, but I'm afraid that 
looking at the source (it's in the standard distribution) or asking 
on the newsgroup are the only ways of finding out what a FileInput 
really _is_. 

>  > That is, the set of all interfaces has a cardinality
>  > that I don't particularly want to contemplate.
>  
>  But one would not bother to enumerate all possible interfaces.

True. One would not even try to enumerate all possible signatures. 
The point is, though, that there's a conflict between precision and 
usability. If interfaces are too precise, they will multiply with 
abandon and become unmanageable. To prevent that, people will choose 
the "closest" interface. So the "requirer" will ask for more than is 
actually needed, and the "requiree" will have the choice of adding 
unneeded methods, wrapping unnecessarily, or lying.

>  > At the moment "sequence protocol" means 2 different things. It means
>  > Py_SequenceCheck(o) == TRUE (which I hope the type / class
>  > unification fixes),
>  
>  No.  This is a purely implementation check.  It doesn't, for
>  example, capture instances that implement the sequence protocol.

That's why I said it needs to be fixed.
 
>  > and it means that if you squint a little and wave
>  > your hands alot, this thing could be considered a sequence. My worry
>  > is that if you attempt to make the latter definition more precise,
>  > you in fact increase complexity.
>  
>  Interfaces give you the ability to express more.  In a sense this
>  adds complexity, but it also lends order to existing complexity
>  (e.g., as you point out, Tuples are sequences, sort of)

They actually express less. But, hopefully, they express it much more 
concisely, and at a "reaonable" level of abstraction. They do not 
obviate the need for reading the source (see FileInput, above), but 
once you've done that they serve as mnemonics. Once you've been 
through it, you now either remember, or know where to look it up.

every-silver-lining-has-a-cloud-ly y'rs

- Gordon
Thread:
Jim Fulton
Gordon McMillan

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved