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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4