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

Python idioms I wish I'd learned earlier

prooffreaderplus.blogspot.com

Post reply on HN
Print view View original

51–60 of 174 posts

Re: Python idioms I wish I'd learned earlier

#51

Post by Jach »

davidrusu wrote: post #34
hasenj wrote: post #18

Earlier quoted context omitted.

But can any lisp dialect do: a = c ?

( = b c)) same number of operators but a few extra parens

This isn't the same thing -- the Python syntax is asking for a = c, while only evaluating b once. There are many infix math libraries for lisps (e.g. this one from 1995: https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...) that allow things like #I(a = c), but the trick is only evaluating b once. (The linked lib will expand into two evaluations if b is an expression.)

Re: Python idioms I wish I'd learned earlier

#52

Post by abecedarius »

philsnow wrote: post #40
smoe wrote: post #24

Earlier quoted context omitted.

I personally don't like this style of using multiple strings. Makes radical changes of the text cumbersome. I think in most cases it's better to use triple quotes. And if the content of these variables isn't exclusively shown in the shell, you should use translation files anyway.

$ cat triple.py def foo(): print """this is a triple quoted string this is a continuation of a triple quoted string""" if __name__ == '__main__': foo() $ python triple.py this is a triple quoted string this is a continuation of a triple quoted string This is really warty. In bash you can mostly get around this with e.g. $ function usage() { cat

I'd normally write

    def foo():
        print """\
    this is a triple quoted string
    this is a continuation of a triple quoted string"""

Re: Python idioms I wish I'd learned earlier

#53

Post by dllthomas »

"Because I was so used to statically typed languages (where this idiom would be ambiguous), it never occurred to me to put two operators in the same expression. In many languages, 4 > 3 > 2 would return as False, because (4 > 3) would be evaluated as a boolean, and then True > 2 would be evaluated as False."

The second half of this is correct, but it has nothing to do with whether the language is statically or dynamically typed. It's a tweak to the parser, mostly.

Re: Python idioms I wish I'd learned earlier

#54

Post by unwind »

dalke wrote: post #42
philsnow wrote: post #36

Earlier quoted context omitted.

Even worse IMHO is the semantics of strings being implicitly iterable. Often it ends up that you're intending to iterate over something for item in orders: do_something_with(item) So if `foo` is usually `[Order(...), Order(...), ...]` but due to a bug elsewhere, sometimes `foo` is "some string". Then you get a mysterious exception somewhere down in `do_something_with` or one of its callees at run time, and all becaus…

I use "for c in s", to read characters in a string, pretty often. Here's an example from Python3.2's quopri.py: def unhex(s): """Get the integer value of a hexadecimal number.""" bits = 0 for c in s: c = bytes((c,)) if b'0' Here's another example of iterating over characters in a string, from pydoc.py: if any((0xD800 It seems like a pretty heavy-weight prohibition for little gain. After all, you could pass foo = open…

Shouldn't unhex() just be int(s, 16)?

Not sure what it adds, but I don't quite understand it yet and perhaps there's something magic in the context of MIME quoted printable that I'm missing.

Re: Python idioms I wish I'd learned earlier

#55

Post by sullyj3 »

Animats wrote: post #13
euphemize wrote: post #9

One of my favorites: >>> print "* "* 50 to quickly print a separator on my terminal :) Previous discussion on python idioms from 300 days ago: https://news.ycombinator.com/item?id=7151433

That's cute, but the result of a bad design decision. Python overloads "+" as concatenate for strings. This also applies to lists. So [1,2,3] + [4,5,6] yields [1,2,3,4,5,6] This is cute, but not what you want for numerical work. Then, viewing multiplication as repeated addition, Python gives us [1,2,3]*4 yields [1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3] This is rarely what was wanted. Then there's numpy, which has its own…

I really like haskell's "++" for list concatenation. Makes a lot of sense.

Re: Python idioms I wish I'd learned earlier

#56

Post by smoe »

philsnow wrote: post #40
smoe wrote: post #24

Earlier quoted context omitted.

I personally don't like this style of using multiple strings. Makes radical changes of the text cumbersome. I think in most cases it's better to use triple quotes. And if the content of these variables isn't exclusively shown in the shell, you should use translation files anyway.

$ cat triple.py def foo(): print """this is a triple quoted string this is a continuation of a triple quoted string""" if __name__ == '__main__': foo() $ python triple.py this is a triple quoted string this is a continuation of a triple quoted string This is really warty. In bash you can mostly get around this with e.g. $ function usage() { cat

I would put all messages in variables at the top of the file or even in a separate one and print them in the appropriate places.

Having multi line prints in functions add a lot of noise in my opinion. When i read code, i dont normally care about the content of messages being printed.

Re: Python idioms I wish I'd learned earlier

#57

Post by dalke »

unwind wrote: post #54
dalke wrote: post #42

Earlier quoted context omitted.

I use "for c in s", to read characters in a string, pretty often. Here's an example from Python3.2's quopri.py: def unhex(s): """Get the integer value of a hexadecimal number.""" bits = 0 for c in s: c = bytes((c,)) if b'0' Here's another example of iterating over characters in a string, from pydoc.py: if any((0xD800 It seems like a pretty heavy-weight prohibition for little gain. After all, you could pass foo = open…

Shouldn't unhex() just be int(s, 16)? Not sure what it adds, but I don't quite understand it yet and perhaps there's something magic in the context of MIME quoted printable that I'm missing.

That is an excellent point!

Based on my reading, there's nothing magic. The context is:

    elif i+2
I tweaked it to

        new = new + bytes((int(line[i+1:i+3], 16),)); i = i+3
and the self-tests still pass. (I also changed the 16 to 15 to double-check that the tests were actually exercising that code.)

It's not part of the public API, so it looks like it can simply be removed.

Do you want to file the bug report? Or perhaps it's best to update http://bugs.python.org/issue21869 ("Clean up quopri, correct method names encodestring and decodestring")?

Re: Python idioms I wish I'd learned earlier

#58

Post by meowface »

baddox wrote: post #25
rnhmjoj wrote: post #22

This is something I do instead of writing a long if-else: opt = {0: do_a, 1: do_b, 3: do_b, 4: do_c} opt[option]()

Do you consider that to be idiomatic? I've been out of touch with the a Python community for a few years, but back then I wouldn't have considered that remotely idiomatic, and if I was on a team writing software, I would have argued that we shouldn't be writing code like that.

It can be idiomatic in certain circumstances.

If your dict keys are just numbers, then no, probably not. But strings mapping to functions, and in some cases objects and other things, are often used to substitute for numerous if and elif statements.

Re: Python idioms I wish I'd learned earlier

#59

Post by zo1 »

davidrusu wrote: post #30
baddox wrote: post #25

Earlier quoted context omitted.

Do you consider that to be idiomatic? I've been out of touch with the a Python community for a few years, but back then I wouldn't have considered that remotely idiomatic, and if I was on a team writing software, I would have argued that we shouldn't be writing code like that.

I've done this before, I think of it as a more powerful form of a switch statement. I'd love to hear why you think it's not ideal.

"I'd love to hear why you think it's not ideal."

I'm not the poster you posed that question to. But for me, the one big drawback of using that idiom is that the function signatures have to be identical. So you either have to resort to args/kwargs, or you have an additional intermediary method between the actual "guts" of what you're calling, and the "switch" statement.

Or you live with the fact that you're passing unused/unnecessary parameters to your functions.

Re: Python idioms I wish I'd learned earlier

#60

Post by Shizka »

ims wrote: post #4

I think the example in #4 misses the point of using a Counter. He could have done the very same for-loop business if mycounter was a defaultdict(int). The nice thing about a Counter is that it will take a collection of things and... count them: >>> from random import randrange >>> from collections import Counter >>> mycounter = Counter(randrange(10) for _ in range(100)) >>> mycounter Counter({1: 15, 5: 14, 3: 11, 4:…

I recently had a use case for this where I needed a naively created bag of words along with the frequency of words. Having Counter made this extremely easy as I could simply split the string on whitespaces and pass the result to a Counter object. Another useful feature is that you can take the intersection of two Counter objects. It's a really nice data structure to have!
Post reply on HN