[Python-Dev] Single- vs. Multi-pass iterability

[Clark C . Evans]

On Fri, Jul 12, 2002 at 06:16:54PM +0200, Alex Martelli wrote:
| On Friday 12 July 2002 06:12 pm, Barry A. Warsaw wrote:
| > >>>>> "AM" == Alex Martelli <aleax@aleax.it> writes:
| >     >> I think Alex is in a great position to become co-author of PEP
| >     >> 246.
| >
| >     AM> Aye aye, cap'n.  What's the procedure for "becoming co-author"
| >     AM> -- edit python/nondist/peps/pep-0246.txt and send the cvs diff
| >     AM> to Barry, or ... ?
| >
| > That would work fine, although I would like to get /some/
| > acknowledgement from Clark Evans that passing the torch (or sharing
| > the flame as it were) was okay with him.
| 
| Makes sense (& thanks to the others who suggested the same thing).
| I mailed Clark and I'll wait to hear from him.

Wow!  I'm thrilled to hear that this PEP hasn't died of 
neglect.  When I wrote it I was relatively new to Python.
Python makes you think differently about a great many things.
What it means to be a particular "type" is one of those 
mind-bending experiences I had.  If it looks like a file, 
acts like a file, it's a file.   I love this straight-forward
mentality and this clarity of thought which carries through
all of Python makes it a true pleasure to code with.

This PEP was written just by listening to people (and getting
their feedback) on the interfaces list.  It just seemed to me
that people wanted a way to ask Python:  

    Hey is this object a Thymagig?

Although this is a nice question to ask; as a programmer with 10+
years of building components, and using other's components to 
build larger applications I often ask a similar but related question:

   Well, if it ain't a Thymagig, where is the
   wrapper so I can treat it like one?

It is this second question that the Object Adaptation PEP is based.
To me, this is the stuff FAQ's are made for ... and I wonder, why
can't the language do this for me?  Why not have a language where
the library writers (who usually know each other) can't build in
the glue to connect their components in such a way that the application
builder doesn't have to do the "interface hunt".

Speaking of which, I personally don't feel that interfaces
is the way to go...  there are many reasons why I'm using Python
and not using Java.  Interfaces are too inflexible and often times
can cause more headaches than they save with additional typing.
Frankly, I think that the whole "interface paradaigm" brings with
it alot of extra baggage to the "Is this object a Thymagig?" 
question; and I think this extra baggage is just not needed --
especially for Python.   For example, interface inheritance is
one of those bits of baggage (that others may disagree with me on).
Interface inheritance is one of those "givens" that one must do to
do interfaces right.  Interface inheritance isn't needed.  Why?
Mix-ins are far more powerful mechanism as they make you think about
operations which are othogonal to each other.  You think that
interface inheritance helps, but in my experience it just screws
with your thought process... ;)

Anyway, I'm so glad that Alex has taken up the cause; I'm not all 
that actively involved in Python internals... but as a user I can't
advocate more for something like this.  Alex, I'm delighted if 
you would take ownership of the PEP.  

ON A RELATED NOTE, if you have not otherwise found out, YAML
(YAML Ain't Markup Language) is doing wonderfully.  It is a pythonish
serialization format for native data structures of Python/Perl/Ruby/Etc.
You should check it out... http://yaml.org ; we will have a last
call for our working draft on Sept 1st.   YAML is progressing nicely
and feedback from the core Python team would be wonderful.  There is
a pure Python implementation written by Steve Howell and a "C" 
library written by Neil Watkiss with python glue written by yours-truly.
The "C" library is still private for another few weeks, but the pure
Python one is available now as a work-in-progress.   The specification
itself is very near the finish line.


Kind Regards,

Clark
Yo! Try YAML on fer size.  YAML is
serialization for the masses.

-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software