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

141–150 of 174 posts

Re: Python idioms I wish I'd learned earlier

#141

Post by lmm »

ajuc wrote: post #101
kazinator wrote: post #14

Earlier quoted context omitted.

Common Lisp (and other dialects): ( Also: (lcm a b c d ...) ;; lowest common multiple (+) -> 0 (+ a) -> a (+ a b) -> a + b (+ a b c) -> (a + b) + c (*) -> 1 (* a) -> a (* a b) -> a * b (* a b c) -> (a * b) * c Is it just syntactic sugar? ( (and ( isn't the same as ( By the way, this could be turned into a short-circuiting operator: more semantic variation. Suppose < is allowed to control evaluation. Then an expressio…

I love clojure for providing ( and for making = actually useful (works on nested structures properly). "Is this sorted", and "are these equal" are intuitive and useful concepts in programming and you shouldn't need to reimplement them each time you need them.

"Is this sorted" is useful but "<=" is not a good name for it.

Re: Python idioms I wish I'd learned earlier

#142

Post by _paulc »

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

    from __future__ import print_function
    import textwrap

    t = """
            Hello there
            This is aligned
    """

    # Need strip to get rid of extra NLs 

    print(textwrap.dedent(t).strip())

Re: Python idioms I wish I'd learned earlier

#143

Post by frindo »

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:…

Python noob here. What does the _ mean in "...for _ in range(100))"?

Re: Python idioms I wish I'd learned earlier

#144

Post by icebraining »

frindo wrote: post #143
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:…

Python noob here. What does the _ mean in "...for _ in range(100))"?

It's just a name of a variable. There's nothing special about it (in this context), but it's conventionally used when you don't care about the value assigned to it.

Re: Python idioms I wish I'd learned earlier

#145

Post by philsnow »

noinsight wrote: post #77
Spiritus wrote: post #43

Earlier quoted context omitted.

Use `textwrap.dedent()`?

I normally just do this for multiline strings: s = "\n".join(["one","two","three"])

This happens at run time whereas IIRC the string literal is crammed pre-joined into the ,pyc / .pyo file.

The performance hit of doing this kind of thing really adds up in a larger app.

Re: Python idioms I wish I'd learned earlier

#146

Post by ixwt »

frindo wrote: post #143
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:…

Python noob here. What does the _ mean in "...for _ in range(100))"?

Normally you would place a variable there, such as x or y. But in this case, the variable doesn't matter. You aren't using it in the function call. You're telling the programming the variable for the for loop that it doesn't matter.

Re: Python idioms I wish I'd learned earlier

#148

Post by misiti3780 »

rectangletangle wrote: post #62

I'm a fan of Python's conditional expressions. foo = bar if qux is None else baz They're particularly interesting when combined with comprehensions. ['a' if i % 2 == 0 else 'b' for i in range(10)] Though this particular example can be expressed much more concisely. ['a', 'b'] * 5

i didnt realize you could add the if statement in the comprehension where you did

    ['a' if i % 2 == 0 else 'b' for i in range(10)]
very cool!

I was on aware of code like

    ['a' for i in range(10) if i % 2 == 0]

Re: Python idioms I wish I'd learned earlier

#149

Post by misiti3780 »

rectangletangle wrote: post #62

I'm a fan of Python's conditional expressions. foo = bar if qux is None else baz They're particularly interesting when combined with comprehensions. ['a' if i % 2 == 0 else 'b' for i in range(10)] Though this particular example can be expressed much more concisely. ['a', 'b'] * 5

i didnt realize you could add the if statement in the comprehension where you did

    ['a' if i % 2 == 0 else 'b' for i in range(10)]
very cool!

I was only aware of code like

    ['a' for i in range(10) if i % 2 == 0]

Re: Python idioms I wish I'd learned earlier

#150

Post by dllthomas »

myg204 wrote: post #103
dllthomas wrote: post #65

Earlier quoted context omitted.

You can implement it entirely in the parser if you can avoid name capture - it may or may not be implemented entirely as a tweak to the parser in practice, but it's fundamentally a syntactic thing. Your discussion of types here is all wrong - it's true that C treats booleans as if they were integers, but Python does, too : >>> (3 > 4) >> 3 > 4 >> 3 > (4 It has nothing to do with types.

I think the comparison is more readable as (here with the >>> of the python shell): >>> 0 as opposed to >>> 1 > x > 0 Following the number line and placing x there is nicer IMHO. Other than that, very nice trick.

In terms of coding style, I agree with you that following the number line is usually going to be clearest. I think there might be some situations where descending is better than ascending, but certainly both are radically better than what I did above (low > high As an example for what I was specifically trying to show here, though, that doesn't let me distinguish things quite as clearly.

I believe that (a 

    x
So there's no way to get both of the parenthesized versions to disagree with the unparenthesized version in a single example.
Post reply on HN