[M.-A. Lemburg]
> ...
> Seriously, this goes down the path of lazy evaluation of expressions.
Lazy sequences specifically, but that's been a tension in Python all along
(it started with the for/__getitem__ protocol, and nothing we do from here
on in will ever be as much of a hack as xrange() was for that <0.9 wink>).
> Not sure whether this is the right path to follow though (can cause
> brain damage due to overloaded builtin debuggers, IMHO).
We can introduce "L[...]" for explicitly lazy list comprehenions <wink>.
> BTW, looks like I can finally get rid off the dict() builtin I
> have in mxTools which is Good News !
It's not quite the same in the details: CVS dictionary(s) works just like
CVS
d = {}
for k, v in s:
d[k] = v
In particular, it demands that the elements of s each produce exactly 2
objects, where IIRC the mxTools dict() requires at least 2 (ignoring any
after the second). Was ignoring excess objects "a feature", or just
exposing an implementation that didn't want to bother to check?
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