On page 20, didn't he/she mean "print(count, name)" in the BAD example?
On page 18, the Java comment: it depends. E.g. see [1]
[1] http://stackoverflow.com/questions/299068/how-slow-are-java-...
Python Idioms [pdf]
121–128 of 128 posts
Re: Python Idioms [pdf]
#122Earlier quoted context omitted.
> Checking for empty strings can be done with len(mystring)==0 for this reason. `len` blows up on None, so this blows up completely instead of just failing. > Relying on implicit conversions is just sloppy. There is no implicit conversion. Truthiness is a protocol, it does not convert anything anywhere.
> `len` blows up on None, so this blows up completely instead of just failing That's the whole point! As I said, Better with an exception than continuing with corrupt data. Or maybe I should say unsupported data type rather than corrupt data.
At the point where you are doing your validation (or where you are doing the actual work with the variable) you can make that decision.
It's entirely possible that upstream code is content with any type as long as it's coercible. A lot of Python code just wants an iterable, for example, or something that can be coerced to a string.
It's definitely possible to have a situation where you need a string specifically (or an integer specifically), but it's generally better to have your code coerce the data whenever possible so as to allow for more logical code.
e.g. 's.send(str(object))' (if object has a relevant __str__()) makes perfect sense in code. You don't necessarily need a string, you just need something that can behave as a string in a sensible manner.
You also end up with scenarios where None is a 'valid value' in e.g. the SQL sense of 'value not specified'; for example, company_name might be '' (empty string provided) or None (no value provided); either way company_name is Falsey, and your logic should work the same.
Re: Python Idioms [pdf]
#123Earlier quoted context omitted.
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 since None is a unique distinct value edit: didn't notice at first that you wrote an assignment, not a comparison
Note that 'is' in Python is kind of tricky. None is None, and any value==None is also None. 1 is 1, and 100 is 100; 256 is 256 but 257 is not 257, and "test" is not "test".
The reason for this is that 'is' tests to see if both operands are the same object; it's not a test of equivalence on any level.
There is only ever one instance of None, and you simply get or create references to it. Likewise, there is only one instance of integers up to 256 (presumably a performance optimization for small loops, indexes, etc.). Integers after 256 get separate instances each time, so 'is' fails after that point.
A lot of newcomers to Python come across the 'is None' construct and make assumptions about what 'is' does; the worst part is that they're often correct, and the behaviour becomes difficult to track down when it changes.
Re: Python Idioms [pdf]
#124Earlier quoted context omitted.
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.
The computer sees None and '' as different. But the users of my database at work just see a blank entry. As far as they are concerned, they are the same. For that reason it can be useful to have the code treat them the same.
Re: Python Idioms [pdf]
#125Interesting 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…
>When I read: > if name and pets and owners >I have no intuitive idea of what that means, of what's going on in the program. I agree with you, when I read that I think if name and pets and owners, what? All equal each other? Seems like an unfinished statement.
Out of interest what language do you use? Coming from Perl, this seems pretty normal to me.
Re: Python Idioms [pdf]
#126For point 10: '_' is often aliased as gettext to ease translation of string: from django.utils.translation import ugettext as _ translated_str = _('Something to translate') so using it will overwrite the alias. Instead, you can use '__' (double underscore) as ncoghlan suggests below his answer [1]. or you can use the 'unused_' prefix as Google Python Style Guide suggests [2] or you can change your code, so you don't…
I got caught out by this recently. I wasn't expecting it to be used as a method alias and assumed it was an unusual part of Pythons syntax that I hadn't discovered. I had to get the answer from Stack Overflow.
Not very intuitive.
Re: Python Idioms [pdf]
#127As 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.
I think this is more for: while True: result = do_something() if not result: break rather than: result = True while result: result = do_something() [[edit apparently tab ret submits, not whatever I was trying to do with the actual editing]]
I prefer the second one and its a line less code.
Re: Python Idioms [pdf]
#128Interesting 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…
No. What if 'owners' is a collections.defaultdict, or some other dict-like type?
Your argument is invalid:
In [1]: from collections import defaultdict
In [2]: {} == defaultdict()
Out[2]: True