Article of interest: Python pros/cons for the enterprise

Rhamphoryncus rhamph at gmail.com
Sat Feb 23 16:38:31 EST 2008


On Feb 23, 11:39 am, Nicola Musatti <Nicola.Musa... at gmail.com> wrote:
> Paul Rubin wrote:
> > Nicola Musatti <nicola.musa... at gmail.com> writes:
> >>>    a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> [...]
> > There you replace one line of code with 40+ lines to get around the
> > absence of GC.  Sounds bug-prone among other things.
>
> Come on, you didn't define f, g, izip, h or frob either. It's more like
> 5 to one. Furthermore your code is more compact due to the existence of
> list comprehensions, not because of GC. Had you written a loop the
> difference would be smaller.

So here's three versions, for comparison:


a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]


a = []
for x, y in izip(m1, m2):
    if h(x, y).frob() == 7:
        a.append(f(x) + g(y))


std::vector<int> a;
for (std::someiterable<int,int>::iterator i = izip(m1, m2); !
i.finished(); ++i) {
    if (h(i->first, i->second).frob() == 7)
        a.push_back(f(i->first) + g(i->second));
}

Although the the benefits of static typing can be argued, surely you
can see the clarity tradeoffs that you make for it?

Some notes:
* izip() takes two iterables as input and returns an iterator, using
only O(1) memory at any given time.  Your original version got this
wrong.
* I fudged the "!i.finished()" as I couldn't find an appropriate
official version in time for this post
* The iterator can't sanely be copied, so it probably needs to use
refcounting internally.  Oops, that's GC...
* Whoever decided to keep C's i++ syntax for iterators should be shot
* x and y aren't named.  They could be extracted, but it's just enough
effort that it's probably not worth it in C++.



More information about the Python-list mailing list