5 ms·
Some 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 additio
by tomp 12y ago
Some 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
dict(elements) == {'a': 3, 'b': 2}
7. I see
D.get(key, None)
way too often.
8. Unpacking works in many situations, basically whenever a new variable is introduced.
for i, el in enumerate(['a', 'b']):
print i, el
{key: value for (key, value) in [('a', 1), ('b', 2), ('a', 3)]}
map(lambda (x, y): x + y, [(1, 2), (5, -1)])
Note: the last example (`lambda`) requires parentheses in `(x, y)`, as `lambda x, y:` would declare a two-argument function, whereas `lambda (x, y):` is a one-argument function, that expects the argument to be a 2-tuple.
- kryptiskt 12y ago> 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.
- tomp 12y agoIn 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.
- shabble 12y agoprint-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 it in someone's code and looked it up) Also, suppressing line endings: print "cats", or print("cats", end='') My lazy-brain prefers the statement. My sensible/code-review brain prefers the function.
- tomp 12y agoThe 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.stderr
- shabble 12y agowell, as a statement it's also a reserved keyword, so you can't override or mock it (AFAIK), and I suspect changing the parser to identify context and operate accordingly might be rather painful. Honestly, I'm reasonably happy with the split; there don't seem to be many compelling reasons to shoehorn all the extra bits back into statement-print other than a) removing a single pair of parens b) being backwards compatible (but then the old code wouldn't be using those new features anyway, and would still have to support that nasty bitshift hack.
- phaer 12y agoWhhats wrong with 7.?
- tomp 12y agoThe default value (the second argument of the `get` method) defaults to `None` anyways. Therefore, D.get(key, None) is just syntax noise (in the best case - in the worst case, it signifies someone who doesn't know/understand Python). D.get(key) should be used instead, or D.get(key, "whatever") if required.
- bpeebles 12y agoOf course, sometimes I still type: D.get(key, None) since I forget that dict.get and getattr() have different behavior in the case of missing keys/attributes...
- philh 12y agoOn the subject of "call me lazy", I really like the % syntax for string interpolation. I'd like perl-style interpolation even more. "".format() is going in completely the wrong direction for me. (I don't think % is being removed, but I think it's discouraged.) > lambda (x, y): x + y This syntax is removed in python 3: http://legacy.python.org/dev/peps/pep-3113/ http://legacy.python.org/dev/peps/pep-3113/
- 0942v8653 12y agoI'm still not sure why that was deprecated. It's much cleaner. I still use it… :/
- GFK_of_xmaspast 12y agoIdeology.
- ris 12y ago"7" May be because getattr (at least) works the other way around, instead raising an exception if not found and no default specified. I'm sure many people can't always remember which works which way.
- tomp 12y agoThere would be no purpose in the `get()` function if it raised an exception if the key wasn't there - that's how `[]` works. On the other hand, `getattr` is IMO mostly used for situations where you don't know what properties exist on an object, so you can't just use the dot notation.
- RubyPinch 12y agowith the print as a keyword, you can't have modules defining a print function (for example, APIs where print makes sense as a function name ([he]xchat's py support comes to mind)) additionally, if you want to override print in python2, you need to replace the stdout stream with your own inbetween buffer object, which also has the downside of being global