Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Idioms [pdf]

safehammad.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Python Idioms [pdf]

#71

Post by baddox »

Perseids wrote: post #68
baddox wrote: post #56

Earlier quoted context omitted.

I think the point of the article, and of idioms in general, is that they make code "better" (e.g. some combination of clearer, shorter, cleaner, etc.) for the community of coders who are familiar with the idioms. The obvious downside of idioms is that a programmer needs to learn the idioms to reap these advantages. So I suppose whether you should encourage idioms in your code base would depend on who will be working…

Nonetheless, you should reconsider from time whether those idioms are actually helpful for those in the community. I personally dislike 'if name and pets and owners:' because it removes the information of what is happening at this line of code and I have to look up what type name, pets and owners actually are.

That's a good point. In the example they give it's not really an issue, since the variables are clearly defined right before the if statement. I still think it's reasonable and intuitive in most cases, once you're familiar with the "truthiness" of basic data types (e.g. empty arrays, empty strings, empty dicts, and numbers equal to zero are "falsy").

Re: Python Idioms [pdf]

#72

Post by calroc »

beambot wrote: post #70
calroc wrote: post #64

Earlier quoted context omitted.

I couldn't resist. Moar funky-cool Python: >>> from string import ascii_letters >>> ors = ['|'] * (len(ascii_letters) * 2 - 1) >>> ors[::2] = ascii_letters >>> ''.join(ors) 'a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z|A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z' (Obviously, in this example '|'.join(ascii_letters) would suffice, but if the objects weren't strings...)

Not gonna lie... your snippet made me say "WTF?" Why not just do: from string import ascii_letters '|'.join( ascii_letters ) (I also like list slicing... but only when necessary.)

Yeah, I realized after posting it. (See edit.) The original code was using non-string objects. I basically come up with this to get the same behavior as str.join(). ;-)

Re: Python Idioms [pdf]

#74

Post by jerf »

calroc wrote: post #72
beambot wrote: post #70

Earlier quoted context omitted.

Not gonna lie... your snippet made me say "WTF?" Why not just do: from string import ascii_letters '|'.join( ascii_letters ) (I also like list slicing... but only when necessary.)

Yeah, I realized after posting it. (See edit.) The original code was using non-string objects. I basically come up with this to get the same behavior as str.join(). ;-)

    '|'.join(str(x) for x in y) # or
    '|'.join(map(str, y))

Re: Python Idioms [pdf]

#76

Post by beagle3 »

jfischer wrote: post #31
andrewfong wrote: post #19

Earlier 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.

I've personally run into problems when I don't do exact comparisons with True and False. For example, I've forgotten to return a value in one path of a function/method, and then tried to use the result in an if statement in the style recommended by the OP (e.g. if fcall(): do something). After being bitten several times by this, I always do explicit comparisons.

So you never use "else"? Else is the mother of inexact comparisons.

Re: Python Idioms [pdf]

#77

Post by pdonis »

Perseids wrote: post #68
baddox wrote: post #56

Earlier quoted context omitted.

I think the point of the article, and of idioms in general, is that they make code "better" (e.g. some combination of clearer, shorter, cleaner, etc.) for the community of coders who are familiar with the idioms. The obvious downside of idioms is that a programmer needs to learn the idioms to reap these advantages. So I suppose whether you should encourage idioms in your code base would depend on who will be working…

Nonetheless, you should reconsider from time whether those idioms are actually helpful for those in the community. I personally dislike 'if name and pets and owners:' because it removes the information of what is happening at this line of code and I have to look up what type name, pets and owners actually are.

it removes the information of what is happening at this line of code and I have to look up what type name, pets and owners actually are

My response to this is, why do you care what their types are? What the statement is saying, conceptually, is "if there's a name and there's pets and there's owners, do this". Why should I have to explicitly tell the language how to tell whether there's a name and there's pets and there's owners, when it already knows that? To me that's just extra verbosity for no good reason. Do you really care that name is a string but pets and owners are containers? (And even if you do, isn't that evident from the variable names anyway? Good naming conventions can do a lot of the work of clarifying what's going on while keeping the code compact.)

Re: Python Idioms [pdf]

#78

Post by pekk »

rsfinn wrote: post #61
drewblay wrote: post #52

>pets = ['Dog', 'Cat', 'Hamster'] >for pet in pets: > print('A', pet, 'can be very cute!') This may be nit picking but I prefer output like this: print 'A %s can be very cute!' %(pet)

Possibly because you haven't moved to Python 3?

Python 3 doesn't dictate that style, just the parentheses

Re: Python Idioms [pdf]

#79

Post by bcoates »

crazygringo wrote: post #13

Interesting 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 a dynamic-typing thing. In some hypothetical static-strong-non-duck version of Python,

  if name != '' and len(pets) > 0 and owners != {}
would tell you that name is a non-empty string, pets has values, and owners is a non-empty dict (except it doesn't work, as pdonis noticed).

But Python allows immoral implicit conversions, so that's not what that line means! If name is a function, pets is the value '7' and owners is a list, the test passes.

  if name and pets and owners
Would pass as well, but it has the advantage of not implying it does more than it does: all you can infer from the test passing is that none of name,pets,owners are special falsy values.

If you actually wanted to test what the longer line is implying, you'd write something like

  if isinstance(name, str) and isinstance(pets, list) and isinstance(owners, set) and name and pets and owners
(don't do this, it violates duck-typing and LBYL)

Re: Python Idioms [pdf]

#80

Post by thruflo »

falcolas wrote: post #41
Walkman wrote: post #18

For 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 have personally never seen this before. I'd be wary to use it, since it breaks the "_ is a throwaway" idiom, as well as the REPL "_ is the results of the last expression" function. Aliasing it to "t" or "txl" seems like a saner way, if I'm honest.

This has been established practise in Zope, Plone et al for many years.

http://developer.plone.org/i18n/internationalisation.html#ma...

Post reply on HN