[Python-Dev] re: Sets BOF / for in dict

[Ka-Ping Yee]

On Mon, 5 Feb 2001, M.-A. Lemburg wrote:
> Slices and dictionary enclose the two parts in brackets -- this
> places the colon into a visible context. for ... in ... : does
> not provide much of a context.

For crying out loud!  '\':' requires that you tokenize the string
before you know that the colon is part of the string.  Triple-quotes
force you to tokenize carefully too.  There is *nothing* that this
stay-away-from-colons argument buys you.

For a human skimming over source code -- i repeat, the visual hint
is "colon at the END of a line".

> > Because there's no good answer for "what does iterator() return?"
> > in this design.  (Trust me; i did think this through carefully.)
> > Try it.  How would you implement the iterator() method?
> 
> The .iterator() method would have to return an object which
> provides an iterator API (at C level to get the best performance).

Okay, provide an example.  Write this iterator() method in Python.
Now answer: how does 'for' know whether the thing to the right of
'in' is an iterator or a sequence?

> For dictionaries, this object could carry the needed state
> (current position in the dictionary table) and use the PyDict_Next()
> for the internals. Matrices would have to carry along more state
> (one integer per dimension) and could access the internal
> matrix representation directly using C functions.

This is already exactly what the PEP proposes for the implementation
of sq_iter.

> This would give us: speed, flexibility and extensibility
> which the syntax hacks cannot provide;

The PEP is not just about syntax hacks.  It's an iterator protocol.
It's clear that you haven't read it.

*PLEASE* read the PEP before continuing to discuss it.  I quote:

| Rationale
| 
|     If all the parts of the proposal are included, this addresses many
|     concerns in a consistent and flexible fashion.  Among its chief
|     virtues are the following three -- no, four -- no, five -- points:
| 
|     1. It provides an extensible iterator interface.
| 
|     2. It resolves the endless "i indexing sequence" debate.
| 
|     3. It allows performance enhancements to dictionary iteration.
| 
|     4. It allows one to provide an interface for just iteration
|        without pretending to provide random access to elements.
| 
|     5. It is backward-compatible with all existing user-defined
|        classes and extension objects that emulate sequences and
|        mappings, even mappings that only implement a subset of
|        {__getitem__, keys, values, items}.

I can take out the Monty Python jokes if you want.  I can add more
jokes if that will make you read it.  Just read it, i beg you.

> e.g. how would you
> specify to iterate backwards over a sequence using that notation
> or diagonal for a matrix ?

No differently from what you are suggesting, at the surface:

    for item in sequence.backwards():
    for item in matrix.diagonal():

The difference is that the thing on the right of 'in' is always
considered a sequence-like object.  There is no ambiguity and
no magic rule for deciding when it's a sequence and when it's
an iterator.


-- ?!ng

"There's no point in being grown up if you can't be childish sometimes."
    -- Dr. Who