"sins" (aka, acknowledged language problems)

[Alex Martelli]

Bijan Parsia writes:

> So, you could just use 'for' with the added notion that providing two
> variables gives you the index in the first one.
> 
> As I recall, this didn't lead to any confusion in NS.
> 
> I don't know if this conflicts with already legal Python. But it seems
> much preferable than a different keyword.
> 
It would indeed conflict -- "for x, y in e" already has a useful
meaning when e is a sequence of tuples, as it unpacks each
tuple into x and y variables.

I agree that piling keywords on top of each other is not the
best of ideas; I would much prefer a syntax such as

	for x,y in somebuiltinfunction(e):
		...

where "somebuiltinfunction" would turn the existing sequence
e into a virtual sequence of key-value pairs.  This has the
added advantage that, until "somebuiltinfunction" does get
added to Python, you can easily write it as a wrapper (see
my previous posts in this thread), already today.

For mappings, the "items" method already works this way:

	for key,value in mydictionary.items():
		...

except that it's uncertain whether its implementation needs
space to store all of the list of key-value pairs (I guess it
must), rather than just one at a time.  So, the hypothetical
new built-in function might work on mappings too, giving
the same service as today's ".items", but in a possibly
memory-optimized way working only in a "for" iteration
rather than when a list-of-items is needed in general.


As the name for "somebuiltinfunction", I personally like
"enum" (because I think of this as "enumeration idioms"),
but I realize this badly conflicts with the use of "enum" in
C or C++.  Thus, something like "iterator", "sequencer",
"itemizator", or abbreviations thereof, might be deemed
to be preferable to "enumerator" or abbreviations of it.
I'm _not_ at all stuck on this level of syntactic sugar...:-).


Alex