Explore course: Write Pythonic Code Like a Seasoned Developer | Hacker News Reader

Explore course: Write Pythonic Code Like a Seasoned Developer

training.talkpython.fm

77 pointsmikeckennedy17 comments

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].

[1] http://python.net/~goodger/projects/pycon/2007/idiomatic/han...

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.

> other than choosing python 3 vs 2 you don't have much control over that.

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

OK, true. :) But given the course is Python 3 it's moot in that scenario.

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).

Example: https://gist.github.com/androm3da/dd257031eeaf3ff09d6654726a...

> The course itself is not public access, but the materials are.

What materials are you referring to?

In the "Dictionary as a Switch Statement" example, how come the @staticmethod decorator is on a different indent level than the method it wraps?

The class attributes are at the same indentation level. Seems like code that wouldn't parse, which doesn't seem very Pythonic.

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.

Should:

    'n', Moves.Nort

Actually be:

    'n', Moves.North

?

That's not how your spell Nort? ;) Yes, thanks, updated.

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?

Yes, I think I mention that in the lesson. You have a trade off.

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.

Love the podcast. Will most definitely be using this to reinforce Python chops when I need them this Fall.

Thanks so much. Glad you're enjoying Talk Python To Me!

Would be good to add some of these typical code samples on that page. Good vs bad.

Reply on news.ycombinator.com