Tim Peters wrote:
>
> [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>.
... and add a lazy list comprehension object (e.g. xlistcompobj) ?
Cool :-)
> > 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?
It was a feature; it's just that I forgot what I needed it for ;-)
There are quite a few things in mxTools which I've never *really*
needed. The single most used API in the package was and still is
irange() which returns a sequence (i, obj[i]). dict() and invdict()
are also rather popular ones. Most of the others tend to solve
performance problems in some inner loops of some applications
I wrote.
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
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