At 09:53 AM 10/17/03 +0200, Alex Martelli wrote:
>What about this latest small change, of having the indexing syntax
>invoke __getitem__ -- just like any other indexing, just with an
>iterator as the index rather than (e.g.) a tuple of slices etc?
>
>What, if anything, is "very confusing" in, e.g.,
>
> sum[x*x for x in blaap]
>
>compared with e.g. the currently accepted:
>
> a['tanto':'va':'la', 'gatta':'al':'lardo']
>
>?
Because it's arguably bad coding style to use slices or indexes on an
object in order to perform a function on the indexes supplied. Wouldn't
you find a program where this held true:
TimesTwo[2] == 4
to be in bad style? Function calls are for transforming arguments,
indexing is for accessing the contents of a *container*. Top(10) is not a
container, it has nothing in it, and neither does TimesTwo. I suppose you
could argue that TimesTwo is a conceptual infinite sequence of even
integers, but for most of the proposed accumulators, similar arguments
would be a *big* stretch.
Yes, what you propose is certainly *possible*. But again, if you really
needed an iterator as an index, you can right now do:
sum[ [x*x for x in blaap] ]
And if there are gencomps, you could do the same. So, why single out
subscripting for special consideration with regard to generator
comprehensions, thus forcing clever tricks of questionable style in order
to do what ought to be function calls?
I shudder to think of trying to have to explain Top(10)[...] to a Python
newbie, even if they're an experienced programmer. Because Top(10) isn't a
*container*. I suppose a C++ veteran might consider it an ugly operator
overloading hack... and they'd be right. Top(10,[...]) on the other hand,
is crystal clear to anybody that gets the idea of function calls.
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