
Ain't 'zip' cool.
The problem that zip addresses occurred over and over in my code.
(To Guido's chagrin) I do become fascinated and interested in language design issues. 'zip', for my purposes, was perfect. The intention, in my cases, is to iterate over lists of equal lengths. But there are corner cases in which the len of the lists become unequal, and I needed to test and adjust for that. My adjustment was exactly what zip provides - what the heck, go over the shorter of the two lists. Good enough for my purposes. Actually helped bulletproof my code. But only because there are parts of my code (when I'm just drawing, after all) where good enough is good enough. That is often not the case when programming. So as much as I appreciate 'zip' I recognize danger in it, because an unequal length list condition might also indicate an unexpected 'out of balance' condition as well as an expected one. That condition was more likely to be exposed with the 'old fashioned' way of handling the situation which zip addresses. So, in using zip, without some caution, an unexpected condition - a bug - might pass silently. The edu-sig relevance, I guess, is that there are always trade-offs, and therefore subtleties every way one turns. And, in the end, often no way to make things truly 'simple'. And students of the language, IMO, need to understand that upfront. And to take responsibility in all cases. It's all in the docs. But the reality is that probably the only way one is going to get one's arms fully around something as simple as the full implications of 'zip' is to get bitten by it once. Or at least that's how I end up learning most of the nooks and crannies. Having been bitten enough times and taken it like a .. (be careful) programmer, I sort of expect others to do the same. And get cranky when they don't. Which has been the base source of some of my crankiness when the issue of "newbies" and Python's responsibilities to them comes up again and again. Art

In addition to 'zip', I like 'enumerate'. It helps with that polynomial class I was mentioning.
def value(plist,x): """Evaluate a polynomial with coeffs plist at x""" return sum([c*(x**e) for e,c in enumerate(plist)])
def repr(plist): """Takes polynomial coefficients plist and returns a formatted textual representation of the poly""" terms = ['%s*(x**%s)' % (c,e) for e,c in enumerate(plist) if not c==0] return " + ".join(terms).replace("*(x**0)","")
Using:
repr([1,0,2,3,-1,5]) '1 + 2*(x**2) + 3*(x**3) + -1*(x**4) + 5*(x**5)'
value([1,0,2,3,-1,5],4) 5089
Another way to check results:
x = 4 eval(repr([1,0,2,3,-1,5])) 5089
Change value to __call__ and repr to __repr__, add some self stuff, and you've got your little Poly class (still need __add__ and __mul__ tho). Kirby
participants (2)
-
Arthur
-
Kirby Urner