Python idioms I wish I'd learned earlier
81–90 of 174 posts
Re: Python idioms I wish I'd learned earlier
#82Some comments: 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. 5. Dict comprehensions can be dangerous, as keys that appear twice will be silently overridden: elements = [('a', 1), ('b', 2), ('a', 3)] {key: value for key, value in elements} == {'a': 3, 'b': 2} # same happens with the dict() constructor dic…
> 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses.
If you think the parentheses are bad, why wouldn't you prefer a language like Ruby where you can omit them generally? Leaving them out for just one special construct seems so insufficient as a cure.
Re: Python idioms I wish I'd learned earlier
#83haha.. in #1, the easter egg "not a chance" :) :)
Re: Python idioms I wish I'd learned earlier
#84I'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
That's a Pythonization of C's conditional operator.
foo = qux == NULL ? bar : baz;
Re: Python idioms I wish I'd learned earlier
#85Some comments: 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. 5. Dict comprehensions can be dangerous, as keys that appear twice will be silently overridden: elements = [('a', 1), ('b', 2), ('a', 3)] {key: value for key, value in elements} == {'a': 3, 'b': 2} # same happens with the dict() constructor dic…
print-as-a-function has a few nice qualities, like the ability to pass it around as an argument to things so you can do (stupid example):
map(print, range(10))
Which is the more intuitive of the following?:
print(errmsg, file=sys.stderr)
print >>sys.stderr, errmsg
print "cats",
print("cats", end='')
Re: Python idioms I wish I'd learned earlier
#86Sincerely, Transforming Code into Beautiful, Idiomatic Python – by Raymond Hettinger... http://youtu.be/OSGv2VnC0go
Re: Python idioms I wish I'd learned earlier
#87Some comments: 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. 5. Dict comprehensions can be dangerous, as keys that appear twice will be silently overridden: elements = [('a', 1), ('b', 2), ('a', 3)] {key: value for key, value in elements} == {'a': 3, 'b': 2} # same happens with the dict() constructor dic…
Whhats wrong with 7.?
Re: Python idioms I wish I'd learned earlier
#88Some comments: 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. 5. Dict comprehensions can be dangerous, as keys that appear twice will be silently overridden: elements = [('a', 1), ('b', 2), ('a', 3)] {key: value for key, value in elements} == {'a': 3, 'b': 2} # same happens with the dict() constructor dic…
> 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. If you think the parentheses are bad, why wouldn't you prefer a language like Ruby where you can omit them generally? Leaving them out for just one special construct seems so insufficient as a cure.
In general, Ruby's syntax (or rather, semantics) is ambiguous (you don't know if a statement without parentheses is calling a function or just accessing a value). I prefer unambiguous syntax.
However, Python's `print` statement is (1) well-known, (2) very useful (for prototyping, debugging, in REPL), and (3) shouldn't in general be present in production code (logging should be used instead). Therefore, omitting parentheses would help ease debugging and exploring (REPL prototyping), while not making code more ambiguous in general. Yes, it's a special case, but `print` is also has very special, very specific use-case.
Re: Python idioms I wish I'd learned earlier
#89Some comments: 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. 5. Dict comprehensions can be dangerous, as keys that appear twice will be silently overridden: elements = [('a', 1), ('b', 2), ('a', 3)] {key: value for key, value in elements} == {'a': 3, 'b': 2} # same happens with the dict() constructor dic…
print-as-a-function has a few nice qualities, like the ability to pass it around as an argument to things so you can do (stupid example): map(print, range(10)) It can also take some kwargs that allow you to do things that are a bit clunky with the print statement. Which is the more intuitive of the following?: print(errmsg, file=sys.stderr) print >>sys.stderr, errmsg (I didn't even know about the latter until I found…
The first really has nothing to do with `print` being a statement - it could be parsed and passed as a function in "non-statement" positions regardless.
The rest could probably be special-cased in a backwards-compatible way as well. This is currently not valid Python 2.0 syntax:
print "cats", end='', file=sys.stderrRe: Python idioms I wish I'd learned earlier
#90Some comments: 1. Am I the only one that really loves that `print` is a statement and not a function? Call me lazy, but I don't mind not having to type additional parentheses. 5. Dict comprehensions can be dangerous, as keys that appear twice will be silently overridden: elements = [('a', 1), ('b', 2), ('a', 3)] {key: value for key, value in elements} == {'a': 3, 'b': 2} # same happens with the dict() constructor dic…
Whhats wrong with 7.?
The default value (the second argument of the `get` method) defaults to `None` anyways. Therefore,
D.get(key, None)
D.get(key)
D.get(key, "whatever")