On page 20, there is slight mistake - count is used in the second ("NOT SO GOOD") example but "i" is printed.
Python Idioms [pdf]
111–120 of 128 posts
Re: Python Idioms [pdf]
#112[deleted]
Re: Python Idioms [pdf]
#113As an implementor of Hy (a homoiconic lisp frontend to Python) I've found certain Python idioms to be rather infuriating of late. In particular: >>> 0 == False True Which makes the idiom of testing truthiness quite annoying in parsing code such as: def is_digit_char(s): """ Return a parsed integer from 's'.""" try: return int(s) except (ValueError, TypeError): return None Which is harmless enough except that as a pre…
Why not use the Python built-in method "anystring".isdigit() ?
anystring in string.digits
Re: Python Idioms [pdf]
#114As a huge Python fan, I'm ashamed to admit but I don't get the while True: break What's the problem? I supose the use case is while True: # do stuff if some_condition: break What is the alternative? 'while some_condition'? That means we must have the 'some_condition' variable outside of the loop. And if we have multiple exit points it may become a mess.
That means we must have the 'some_condition' variable outside of the loop. I'm not sure what you mean by that, this works just fine. Though you would probably use range in the real world. i=0 while i !=5: i+=1 Instead of i=0 while True: i+=1 if i == 5: break
He means the variable used in the condition to break (or start/not start), i.e. "i" in your example - which you have outside of your loop.
Re: Python Idioms [pdf]
#115Earlier quoted context omitted.
Personally, because I find infinite loops to be a real PITA, I prefer to do: for _ in xrange(100000): break else: logging.error("ran into an infinite loop") unless I really do need an infinite loop for things like event handler loop, which is admittedly quite rare.
That seems incredibly silly, and looks like it could lead to very infrequent bugs (the worst kind). `while True` is shorter, simpler, and conveys the actual purpose better. Maybe having a statement like that when testing is okay, but in production code that looks insane.
I'd argue that `while True` would be fine in testing, but problematic for production, particularly in the types of programs I write most frequently (long running, minimal supervision). In these daemons, stalling on infinite loops is significantly more painful than dropping out of a loop early occasionally (and with proper logging that it did fall out of the loop, to boot).
It's certainly not as idiomatic, but it's more correct in the long run. My eyes were opened to this when reading through the NASA C guidelines. Closing the door on infinite loops lets programs recover gracefully and do the correct thing for the duration of the programming, as opposed to thing that may be correct for that moment of operation: i.e. looping 1-2 more times beyond the limits of the xrange counter.
Re: Python Idioms [pdf]
#116String concatenation is pretty fast nowadays with the + operator.
Do you have a source? Also, I would argue that concatenation with + is less readable than string formatting.
Re: Python Idioms [pdf]
#117On page 20, there is slight mistake - count is used in the second ("NOT SO GOOD") example but "i" is printed.
Or was it really a mistake?
Re: Python Idioms [pdf]
#118String concatenation is pretty fast nowadays with the + operator.
Do you have a source? Also, I would argue that concatenation with + is less readable than string formatting.
I think that concatenation with + is okay when you're concatenating two strings. And CPython can optimize x = x + y or x += y calls.
Re: Python Idioms [pdf]
#119Re: Python Idioms [pdf]
#120Earlier quoted context omitted.
That means we must have the 'some_condition' variable outside of the loop. I'm not sure what you mean by that, this works just fine. Though you would probably use range in the real world. i=0 while i !=5: i+=1 Instead of i=0 while True: i+=1 if i == 5: break
He means the variable used in the condition to break (or start/not start), i.e. "i" in your example - which you have outside of your loop.
OK, that makes sense then. I was thinking "the condition" was the variable changing within the loop.