His last slide could be written more idiomatically as ''.join('Thanks!')
And this would be more idiomatic:
'Thanks!'
Python Idioms [pdf]
21–30 of 128 posts
Re: Python Idioms [pdf]
#22As 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.
Also an easy way to fake a do ... while loop.
Re: Python Idioms [pdf]
#23Earlier quoted context omitted.
In this case, {k: v for k, v in zip(keys, values)} edit: As I mention below, this becomes useful when you want to do e.g. {f(k): g(v) for k, v in zip(keys, values)}
I'd disagree, as dict(zip(keys, value)) is more concise, doesn't introduce extra variables, and doesn't repeat itself, and explicitly names a dict rather than using a symbol.
Right, but the second you need to modify either the key or the value, you are better off with the dict comprehension. It's like map() vs [...].
Re: Python Idioms [pdf]
#24Interesting philosophical points. To me personally, testing for 'truthy' and 'falsy' values, or relying on exceptions rather than checking values in advance, feels like sloppy and imprecise programming. A string being empty or not, or an array having items or not, or a boolean being true or false, are all qualitatively totally different things to me -- and just because Python can treat them the same, doesn't mean a p…
> it's possible to over-simplify things in a way that obfuscates instead of clarifying
While this is true, I think it's important to keep in mind that a big benefit of being able to handle a situation programatically in different ways is that you, as a programmer, are more able to accurately describe intent.
For example, I think it's foolish to always catch exceptions instead of checking beforehand (look-before-you-leap). However, being able to do either allows me to more accurately represent the intent of a statement. Blindly following rules is almost always sure to lead to poor decisions.
If I'm retrieving an element from an array and I know that for the majority of possible application states there will be an element there, I can just access it, and handle an exception (because it's an "exceptional" case). However if I'm expecting that it could go either way in typical circumstances, then I might more explicitly check the index in the array to illustrate my intent that yes, there are two distinct paths here and that is how the program's control flows naturally.
Of course all of these things are only worthwhile if the reader can see and interpret them as purposeful decisions rather than coincidence. Conveying that is something else entirely.
Re: Python Idioms [pdf]
#25Earlier quoted context omitted.
In this case, {k: v for k, v in zip(keys, values)} edit: As I mention below, this becomes useful when you want to do e.g. {f(k): g(v) for k, v in zip(keys, values)}
I'd disagree, as dict(zip(keys, value)) is more concise, doesn't introduce extra variables, and doesn't repeat itself, and explicitly names a dict rather than using a symbol.
I like list comprehensions and to me dict comprehensions feel like a natural extension of this. It means that you can do things like
{k.upper(): v ** 2 for k, v in zip(keys, values)}
{f(k): g(v) for k, v in zip(keys, values)}
Re: Python Idioms [pdf]
#26Interesting philosophical points. To me personally, testing for 'truthy' and 'falsy' values, or relying on exceptions rather than checking values in advance, feels like sloppy and imprecise programming. A string being empty or not, or an array having items or not, or a boolean being true or false, are all qualitatively totally different things to me -- and just because Python can treat them the same, doesn't mean a p…
I think part of the reasoning behind the truthy / falsy mechanic is that it's more robust. If, for whatever reason, we did: name = None instead of name = '' Then the second conditional would fail, whereas the first would still be fine.
In this particular case, you want to write
name is None
edit: didn't notice at first that you wrote an assignment, not a comparison
Re: Python Idioms [pdf]
#27Interesting philosophical points. To me personally, testing for 'truthy' and 'falsy' values, or relying on exceptions rather than checking values in advance, feels like sloppy and imprecise programming. A string being empty or not, or an array having items or not, or a boolean being true or false, are all qualitatively totally different things to me -- and just because Python can treat them the same, doesn't mean a p…
I think part of the reasoning behind the truthy / falsy mechanic is that it's more robust. If, for whatever reason, we did: name = None instead of name = '' Then the second conditional would fail, whereas the first would still be fine.
See my response as well, but it depends on your intent.
None and '' are two completely different things, and could mean different thing sin the context of the application. It's quite likely that choosing either is a conscious choice of the programmer.
Re: Python Idioms [pdf]
#28As 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.
If there is a simple condition I prefer "while condition" because it makes the code easier to read: I can tell (roughly) when the loop is supposed to exit without reading the contents of the loop and scanning for a break.
Re: Python Idioms [pdf]
#29As 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
i=0
while True:
i+=1
if i == 5:
breakRe: Python Idioms [pdf]
#30I disagree with promoting try / catch. Exceptions like ValueError can really happen almost anywhere, so it is usually better to sanitize your inputs. E.g. something like: try: something = myfunc(d['x']) except ValueError: something = None The programmer's intent is probably to only catch errors in the key lookup d['x'], but if there is some bug in the implementation of myfunc() or any of the functions called by myfun…
That example would surely be better as: something = myfunc(d['x']) if 'x' in d else None
Doesn't this go against the Pythonic notion of handling exceptions rather than "looking before you leap"?