Python Shortcuts for the Python Beginner(maxburstein.com)
maxburstein.com
Python Shortcuts for the Python Beginner
http://maxburstein.com/blog/python-shortcuts-for-the-python-beginner/
22 comments
I find I use it most in multi-level data structures, not unlike Perl's auto-vivification system:
logins = {}
for user, date in getLogins():
logins.setdefault(user, []).append(date)
Probably better done with a defaultdict:
from collections import defaultdict
logins = defaultdict(list)
for user, date in getLogins():
logins[user].append(date) if you have a lot of them, plain dict may prove faster.
Not likely. Proof?
I'd agree if you'd said "not a lot of key/values," as the setup could supersede the subsequent speedups. However, in that case, the difference is negligible, and we should do what is "pythonic."
I'd agree if you'd said "not a lot of key/values," as the setup could supersede the subsequent speedups. However, in that case, the difference is negligible, and we should do what is "pythonic."
Yes, I meant a myriad of very small dicts. In this case a plain built-in is faster.
I think you might have glossed over another very useful "shortcut" not covered in this article, the use of multiple assignments in a single statement.:
val = d['key'] = 'some default value'Nice list. I only wish the author warned the readers that using the "get" method to get an item from the dictionary is not 100% equivalent to using try/except.
When using the method, the default value argument will always be evaluated, regardless of whether the dictionary key exists. If the expression that produces the default value is an expensive one or has side effects, the programmer might want to use the try/except variant instead.
When using the method, the default value argument will always be evaluated, regardless of whether the dictionary key exists. If the expression that produces the default value is an expensive one or has side effects, the programmer might want to use the try/except variant instead.
Nice tips. One nitpick: the "inline if statement" is handy because it works as an expression, not just as a statement.
A few more useful things:
frozenset: immutable set values. these can be hashed, so you can use them as keys in dicts or put them in sets.
poor-man's transpose via zip:
A few more useful things:
frozenset: immutable set values. these can be hashed, so you can use them as keys in dicts or put them in sets.
poor-man's transpose via zip:
>>> x = [('a', 'b'), ('c', 'd')]
>>> zip(*x)
[('a', 'c'), ('b', 'd')]
>>> f = lambda x, s : x[s]
>>> first3 = slice(3)
>>> last3 = slice(-3, None)
>>> rev = slice(None, None, -1)
>>> f('hello', first3)
'hel'
>>> f('hello', last3)
'llo'
>>> f('hello', rev)
'olleh'Good list. My only thoughts:
Prefer itertools.izip instead of zip to avoid materializing a new list.
Appending the comma operator to the print statement suppresses the newline character and appends a space instead, which is how print 1, "world" works.
The only tip I'd add is using mapping keys in string formatting operations:
Prefer itertools.izip instead of zip to avoid materializing a new list.
Appending the comma operator to the print statement suppresses the newline character and appends a space instead, which is how print 1, "world" works.
The only tip I'd add is using mapping keys in string formatting operations:
>>> d = {'cow': 'moo'}
>>> print 'the cow says %(cow)s' % d
the cow says mooIn Python 3, zip() fortunately already returns an iterator.
For python beginners i would not mention the print statement. It won't work for python 3.x.
So, beginners: Please use print() instead of print, to save you some hazzle when using python3 :)
So, beginners: Please use print() instead of print, to save you some hazzle when using python3 :)
Without `from __future__ import print_function`, print doesn't work the same way in Py2k, though.
In 2.7, it does.
Unfortunately not.. atleast not in my 2.7.3 prompt.
Only with the __future__ import :(
In 2.6.6 also works.
If you use print() in py2k, you're still using the print statement and group the argument in parentheses. It falls apart, if you try to use more than one argument, because it's interpreted as a tuple then.
Python3:
Python3:
>>> print("hello", "world")
hello world
>>> print("hello", "world")
('hello', 'world')I actually would prefer people on my team NOT use these shortcuts. For example:
numbers = [1, 2, 3, 4, 5, 6]
even = []
for number in numbers:
if number % 2 == 0:
even.append(number)
numbers = [1, 2, 3, 4, 5, 6]
even = [number for number in numbers if number % 2 == 0]
for x in range(1,101):print"Fizz"[x%3*4:]+"Buzz"[x%5*4:]or x
While it's OK for you to enforce not using trivial list-comprehensions on your team, I think you'll find the majority of Python's community disagreeing. Your example is really tame as far as comprehensions are concerned, and "beginners" are going to need these basics to comprehend more advanced patterns.
It's especially tame given the friendly variable name chosen.
There is a fundamental difference between the loop and the comprehension: the latter is far more declarative.
That is, the comprehension is equivalent to saying something like "even contains every number from numbers that is even". The loop is like saying "start with even as the empty list; for each number in numbers, append it to even". It's much easier to understand what even is from the first description.
The for-loop version is much less direct and has too many low-level details--why are you appending to the list and using extra state? From the second definition, you can know what even is just by looking at it; for the first one, you have to think about what the code is doing.
This is the fundamental delineation between imperative and declarative code. The former is about how and the latter is about what. In general, specifying the what is much simpler--and therefore easier to write, easier to work with and easier to maintain--than specifying how to get it.
I suspect you find the for-loop version easier not because it's simpler but because that's what you're used to. And while familiarity is certainly an important factor, it's always relative and temporary: every person is familiar with different things, and you get more familiar with different constructs over time.
Rich Hickey's "Simple Made Easy"[1] talk is a great description of this whole idea. He makes the matter far clearer than I have any hope of doing.
[1]: http://www.infoq.com/presentations/Simple-Made-Easy
That is, the comprehension is equivalent to saying something like "even contains every number from numbers that is even". The loop is like saying "start with even as the empty list; for each number in numbers, append it to even". It's much easier to understand what even is from the first description.
The for-loop version is much less direct and has too many low-level details--why are you appending to the list and using extra state? From the second definition, you can know what even is just by looking at it; for the first one, you have to think about what the code is doing.
This is the fundamental delineation between imperative and declarative code. The former is about how and the latter is about what. In general, specifying the what is much simpler--and therefore easier to write, easier to work with and easier to maintain--than specifying how to get it.
I suspect you find the for-loop version easier not because it's simpler but because that's what you're used to. And while familiarity is certainly an important factor, it's always relative and temporary: every person is familiar with different things, and you get more familiar with different constructs over time.
Rich Hickey's "Simple Made Easy"[1] talk is a great description of this whole idea. He makes the matter far clearer than I have any hope of doing.
[1]: http://www.infoq.com/presentations/Simple-Made-Easy
There is a fundamental difference between the loop and the comprehension: the latter is far more declarative.
I completely agree with this, and the wider fundamental point throughout your post.
However, I’m not a fan of comprehension syntax. It often gets noisy even for trivial cases like this one: the letters “number” appear four times in just a single line here, which as it turns out is just as much accidental complexity as using the explicit loop control variable in the imperative version and you’ve lost the visual cues to what each means that the indentation gives with the loop. For more complicated transformations, I find comprehension syntax also scales poorly.
I suspect (though I’ve no hard data to back it up) that comprehension syntax actually isn’t very readable in many cases, and that this may be why some people prefer the kind of code in the imperative example rather than any innate preference for imperative style per se. Personally, I’d prefer to highlight the data flow but using more explicit transformations instead, such as (in a hypothetical functional programming syntax):
I completely agree with this, and the wider fundamental point throughout your post.
However, I’m not a fan of comprehension syntax. It often gets noisy even for trivial cases like this one: the letters “number” appear four times in just a single line here, which as it turns out is just as much accidental complexity as using the explicit loop control variable in the imperative version and you’ve lost the visual cues to what each means that the indentation gives with the loop. For more complicated transformations, I find comprehension syntax also scales poorly.
I suspect (though I’ve no hard data to back it up) that comprehension syntax actually isn’t very readable in many cases, and that this may be why some people prefer the kind of code in the imperative example rather than any innate preference for imperative style per se. Personally, I’d prefer to highlight the data flow but using more explicit transformations instead, such as (in a hypothetical functional programming syntax):
evens = filter {_ % 2 == 0} numbers
numbers = [1, 2, 3, 4, 5, 6]
evens = filter(lambda n: n % 2 == 0, numbers)To be fair, we should be comparing like tokens, if the proof is using them as part of its advantage:
evens = filter(lambda n: n % 2 == 0, numbers)
evens = [n for n in numbers if n % 2 == 0]
evens = [n for n in numbers if not n % 2]
Fair comment. I suppose that’s why a more declarative style tends to work much better in a language designed for it. For example, functional programming languages tend to have neat syntactic sugar for things like simple lambda expressions or applying a series of transformations like the filter here, without introducing accidental complexity like extra identifiers that the reader than has to keep track of. The moment you’ve added that kind of baggage, which is almost inevitable to some degree in a language like Python, the clarity tends to suffer.
Slicing a list is not the same as taking subsets, the examples he provides are also misleading in this context.
Great post! For those who know Python, this may be common knowledge, but for the uninitiated, this is a great showcase of some simple ways that Python makes coding more intuitive and enjoyable.
You might also consider mentioning both dictionary and set comprehensions along with list comprehensions, as they are the exact same concept, yet even a lot of intermediate Python programmers don't know about them!
You might also consider mentioning both dictionary and set comprehensions along with list comprehensions, as they are the exact same concept, yet even a lot of intermediate Python programmers don't know about them!
Except the silly 'False = True' at the end. How's that useful?
I think it's just demonstrating how its possible to redefine even Python keywords.
Thanks for the idea! I added a dictionary comprehension section.
The last one is terrible ... I have seen
#define TRUE 0 #define FALSE 1
back in the day.
Too bad there was no source control in the company then, so I could not find out who was responsible for that travesty and "talk calmly" some sense into them.
#define TRUE 0 #define FALSE 1
back in the day.
Too bad there was no source control in the company then, so I could not find out who was responsible for that travesty and "talk calmly" some sense into them.
Processes (and a common design for c functions) return zero on success and an error code otherwise. Although it might be unexpected (and certainly breaks flow constructs), it's probably not so bad with some context.
Worse, though, Windows defines TRUE and FALSE for you somewhere in windef.h - so you would have to be careful about where your code was included..
Worse, though, Windows defines TRUE and FALSE for you somewhere in windef.h - so you would have to be careful about where your code was included..
[deleted]
[deleted]
Shouldn't "the last 3" be [-3:] instead of [3:] ? Inyour case it gives the correct result, but that's because your list has 6 elements i think. ( note : typing on my phone so i can't verify).
Don't forget itertools.product
http://stackoverflow.com/questions/13885234/python-nested-lo...
http://stackoverflow.com/questions/13885234/python-nested-lo...
Could it be possible to explain what does
Print "Fizz" [x%3*4::]
"fizz" is a string - treated as a list in python
"fizz"[0] is the zeroth character in the list / string
Note "fizz"[:] will output all chars in the string (implicitly it's [0:] - from zeroth string to end
X % 3 is x modulo 3, producing 0 only if x is divisible by three - so we want to print fizz here. 4 is the number of chars in both fizz and buzz - so the meat is
"fizz"[x%3*4:] is "fizz"[0:] if x%3 is 0 - when we want tp print fizz, otherwise it's [somevaluegreaterthan4: to the end of the list (ie nothing). The extra : stops index error
"fizz"[0] is the zeroth character in the list / string
Note "fizz"[:] will output all chars in the string (implicitly it's [0:] - from zeroth string to end
X % 3 is x modulo 3, producing 0 only if x is divisible by three - so we want to print fizz here. 4 is the number of chars in both fizz and buzz - so the meat is
"fizz"[x%3*4:] is "fizz"[0:] if x%3 is 0 - when we want tp print fizz, otherwise it's [somevaluegreaterthan4: to the end of the list (ie nothing). The extra : stops index error
Now I understand it. I wasn't aware one could append a subscript operator after a litteral string. I also didn't know of the second : role. Thank you.
But what do you get if x is 0 ? As I now uneerstand it, you would get "fizzbuzz". Shouldn't the list start at value 1 ? So shouldn't the range be (1, 101) instead of (101) ?
But what do you get if x is 0 ? As I now uneerstand it, you would get "fizzbuzz". Shouldn't the list start at value 1 ? So shouldn't the range be (1, 101) instead of (101) ?
You're correct. That was my mistake. Here's the updated version:
for x in range(1,101):print"Fizz"[x%34:]+"Buzz"[x%54:]or x
I basically just removed the extra colons and added 1, to the range so that it starts at 1. lifeisstillgood was spot on with the reasoning that this works.
for x in range(1,101):print"Fizz"[x%34:]+"Buzz"[x%54:]or x
I basically just removed the extra colons and added 1, to the range so that it starts at 1. lifeisstillgood was spot on with the reasoning that this works.
It prints a substring from "Fizz" using slicing.
The thing is, the x%3*4 determines the start of that slice. It's either 0, which is when X modulo 3 == 0 (which is every third number in range(101) ), or something larger than 4, in which case the slice would start at the end of "Fizz" thus yielding an empty string.
nice list, agree with the other comments that the Fizzbuzz example is cool, but can be confusing to work out what it does, especially since this post is aimed at beginners.
I would also mention `getattr` similarly to `get`.
I would also mention `getattr` similarly to `get`.
It's confusing that output is on the >>> lines while input is not -- backwards from the REPL.
More things to consider: dict.iteritems, collections.defaultdict, enumerate(seq, 1)
More things to consider: dict.iteritems, collections.defaultdict, enumerate(seq, 1)
Somethings's up with your site. All I see are black boxes where your examples should be: http://imgur.com/N8vdzGX
Expression `False = True` reminds me of http://stackoverflow.com/a/771974/458610.
Are inline if statements considered good form? I rarely see them in use and I've heard people complain about them before.
Very good list except the fizzbuzz example. It solves the problem but not easy to read, which is not python way.
[deleted]
Also good read for seasoned pythonistas, nice work, mburst
you should always check the length of lists before zip, otherwise you end up with surprises (try running zip with unequal lengths)
I didn't know about some of these. Nice!
Sharing this with my AS Computer Science students. Very clear explanations.
The article requires some corrections if presented to beginners.
`something` should be written as repr(something). `` (backticks) are gone in Python 3.
if 0 < x > 1: is syntactically correct but it should be written as: if x > 1. The combining syntax could be used for the same direction e.g., if -1 < x < 1.
Code golf is not the strong side of Python and it is not the point of FizzBuzz. Code golf might demonstrate language features but it doesn't provide the correct context for their usage i.e., code golf doesn't show to a beginner how something should be used correctly.
True/False are keywords Python 3 (you can't assign to them).
`something` should be written as repr(something). `` (backticks) are gone in Python 3.
if 0 < x > 1: is syntactically correct but it should be written as: if x > 1. The combining syntax could be used for the same direction e.g., if -1 < x < 1.
Code golf is not the strong side of Python and it is not the point of FizzBuzz. Code golf might demonstrate language features but it doesn't provide the correct context for their usage i.e., code golf doesn't show to a beginner how something should be used correctly.
True/False are keywords Python 3 (you can't assign to them).
You can do this:
This is super-useful for configuration in frameworks, for example - it's a one-liner to set a default config value if the user didn't provide one.