On Fri, Jan 22, 2021 at 8:31 AM Neil Girdhar <mistersh...@gmail.com> wrote:
> It's possible for reversed(enumerate(...)) to just work if enumerate
> of a sequence were to return a sequence view. Then you would also get
> all the other sequence operations for free like enumerate(...)[23:27],
> len(enumerate(...)), etc.
That would break backward compatibility. The behaviour of enumerate()
at the moment isn't compatible with it just suddenly being a sequence.
It would have to have some way to be told "please return a sequence".
We currently have a way to say "please return an eager sequence", so
the only thing we don't easily have is "please return a lazy
sequence", and that's possible with about four lines of custom class.
Note that slicing is NOT easy. The proposed semantics for a reversed
enumeration would make slicing extremely odd.
> > As Chris A mentioned, it's quite easy to wrap list() or tuple() around it
> > if you want that.
>
> Yes, you can alternatively wrap with list and pay the computational
> cost. However, as was suggested by Andrew in this thread, but has
> come up many times before, the native iteration tools could return
> views. This saves the user having to build her own custom classes
> (along with tests, etc.). I happen to think this is simpler and more
> beautiful.
It wouldn't work. With enumerate, you could get away with returning a
view, but let's look at map. Should that return a view? If so, does
map(...)[4] cache the result or not? If it does, you're paying the
memory cost of (potentially) the full eager list, in which case you
may as well just make the list. If it doesn't, you break expectations
badly by having it call the function more than once, potentially
giving different results. Either way, it's far better to write your
own, giving you the freedom to define the semantics the way you want
to.
It's even worse with filter(). It can't possibly know which is the 5th
element without counting from the start ("hmm, that's Fire... Earth...
Water... Air... Boron. Ah! Boron!").
What about itertools.tee()? I think the whole point of that is to
hybridize laziness and caching, but if you're going to give it a
sequence, you may as well just get multiple iterators.
I'm eyeballing itertools and really not seeing any that would benefit
from magically returning sequences. Several of them specifically exist
to provide sequence-like behaviour on non-sequence iterables (eg
islice), and others don't have a direct correlation between input
index and output index (eg dropwhile) or have other discrepancies (eg
takewhile).
Rather than try to propose that ALL native iteration tools return
views, find one that would actually benefit, and propose that.
Unfortunately, I think you'll run into the same problem that it's no
longer backward compatible, so it's still going to need a spelling to
request that it behave in sequence view mode, which is probably best
written as something like "import seqview; seqview.map(...)".
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/AJMCPNPSJHY2VUKYOPMAKFB76UCT4HQ3/
Code of Conduct: http://python.org/psf/codeofconduct/
