Mr Kennedy -- this is an interesting course synopsis, it looks like you've put a lot of good work into it. The course itself is not public access, but the materials are.
> The few features that are Python 3 specific will be highlighted as such (e.g. new dictionary merging syntax).
The print statement=>function is a pretty big one too. IMO it's not too much of a wart to import it from the future in order to straddle 2.x/3.x.
Anyone else who came hoping to read actual content on how to write more Pythonic code should consult this popular reference from Pycon '07 [1].
Thanks so much. I do agree with you on the print statement to function, although other than choosing python 3 vs 2 you don't have much control over that.
As for the materials, good link. I'll be releasing 10 of the 50 topics as a free video series outside the course over the next few weeks.
IMO it's not too much of a wart to import it from the future in order to straddle 2.x/3.x.
print() works, without a __future__ import, in Python 2.6. And 2.6 is already well past end-of-life; anyone using a version of Python which doesn't support print-as-function without an import is someone whose timeline for a Python 3 upgrade is "never" -- they'd have moved to at least a later 2.x by now.
print() "works" but it's not a function in 2.6 without the import. It's still the print statement and those parens are just gratuitous. If you happen to pass multiple "function arguments" then what really happens is that you're providing a tuple to the print statement. This will cause the printout to have commas and parens which is not how the print function behaves. There are other subtle differences between the print statement and function (line-ending, etc).
Whoops! I updated the graphic. But "programming" in PowerPoint is super tough with the indentation. It always removes the extra spaces to be helpful. Thanks for pointing it out.
Also, instantiating the dict on each call to the `parse` staticmethod is not very efficient. Why not create the dict as a static/class variable and place the method in a classmethod instead?
17 comments
[ 4.0 ms ] story [ 44.8 ms ] thread> The few features that are Python 3 specific will be highlighted as such (e.g. new dictionary merging syntax).
The print statement=>function is a pretty big one too. IMO it's not too much of a wart to import it from the future in order to straddle 2.x/3.x.
Anyone else who came hoping to read actual content on how to write more Pythonic code should consult this popular reference from Pycon '07 [1].
[1] http://python.net/~goodger/projects/pycon/2007/idiomatic/han...
As for the materials, good link. I'll be releasing 10 of the 50 topics as a free video series outside the course over the next few weeks.
But you do! Add "from __future__ import print_function" to your code and now it can execute identically or near identically among python 2, 3. [1]
[1] https://docs.python.org/2/library/__future__.html
print() works, without a __future__ import, in Python 2.6. And 2.6 is already well past end-of-life; anyone using a version of Python which doesn't support print-as-function without an import is someone whose timeline for a Python 3 upgrade is "never" -- they'd have moved to at least a later 2.x by now.
Example: https://gist.github.com/androm3da/dd257031eeaf3ff09d6654726a...
What materials are you referring to?
1. Instantiate the dict each time, make the code super readable and the choices right next to where they are used.
2. Make the code efficient, move the dict to a static / instance level variable away from the use case at the cost of clarity and maintainability.
My slide chose clarity and I would recommend you write clear code over fast code until you profile it and see it's too slow.
That was my motivation for the slide and demo.