Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code Like a Pythonista: Idiomatic Python

python.net

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Code Like a Pythonista: Idiomatic Python

#51

Post by billjings »

rubergly wrote: post #49

Is it really idiomatic to use intrinsic truth values (eg, using "if x" instead of "if x != 0")? Here are my arguments against it: - "Explicit is better than implicit." - If there's need for a table as reference for what is intrinsically true and what is intrinsically false, then it's clearly not "elegant" enough for people to just understand from looking at the code. - Conventions vary across languages. You're basica…

- But readability counts. Having written a lot of Java and Obj-C lately, I honestly prefer the ability to write "if (foo && foo->bar && foo->bar->baz)" in the latter.

- Frankly, it's not a very complicated table. "Zero, empty, or none" summarizes it pretty well. http://docs.python.org/release/2.5.2/lib/truth.html

- Of course conventions vary across languages. If you're familiar with perl, awk, or ruby, some of these conventions will be familiar to you. If you're more familiar with Java, they'll feel odd and you'll feel an uncertainty using them.

Re: Code Like a Pythonista: Idiomatic Python

#52

Post by Derbasti »

arctangent wrote: post #25

One thing that has always bugged me about PEP8 is the advice about trying to keep line length to I basically just completely ignore this part of the guidance, even though I know that in theory it makes it hard to edit code via a terminal. But this is not something we ever do in practice where I work - code on servers gets there only by being checked out of SVN. I personally find it incredibly irritating when I see pe…

I used to disregard this for the same reasons you are disregarding it. But at some point I realized that

(a) I prefer big font sizes (~13 pt regardless of with/without glasses)

(b) I like to have two columns of code next to each other.

(c) IDEs love to cramp up my work space with vertical side bars.

All that conspires to put horizontal space at a premium. I usually go for 80 chars now. Some languages are more verbose than others though. Cocoa at 80 chars just looks wrong, so in that case, I will take 100 chars.

Addendum: (d) Vim sucks at horizontal scrolling.

Re: Code Like a Pythonista: Idiomatic Python

#53

Post by donatzsky »

epenn wrote: post #3
grammati wrote: post #2

I have just skimmed this so far, but it looks very good. A lot of the Python scripts that I see at work look like either C programs or glorified batch files. I'll definitely point people to this when they are ready and willing to move on to the next level. Well done. Suggestion: one thing I didn't see mentioned is switching from "if s.find(c) == -1: ..." to "if c in s: ...". I see people do that a lot.

one thing I didn't see mentioned is switching from "if s.find(c) == -1: ..." to "if c in s: ...". I see people do that a lot. I think this is covered implicitly by the two "Use in where possible" sections. Although as Tim Peter's The Zen of Python states, which is also quoted in the tutorial, "explicit is better than implicit." If people are doing that despite knowledge of the in keyword then I suppose that just prov…

I don't know. I'd argue that

  if c not in s: ...
is more explicit (and readable) than

  if s.find(c) == -1: ...

Re: Code Like a Pythonista: Idiomatic Python

#55

Post by Ixiaus »

bendotc wrote: post #45
Ixiaus wrote: post #19

Earlier quoted context omitted.

I suppose I didn't say it correctly, you're still maintaining two objects though (xrange the iterable, and the new list being built by the comprehension). The "optimization" I suppose is a moot point because Python's handling of lists is pretty solid and this isn't the 90's anymore, but at least with the while loop you've only got one list object and an integer (which is faster, I would think, to increment than it is…

This is way premature optimization, and it's based on a lot of assumptions. Did you know that, on CPython, your integer increment creates a new object each time (outside of the range -5 to 255 or so, IIRC)? Now, xrange might do its own increment, so let's call it even on object creation. If either xrange or list comprehensions are implemented in C instead of Python, do you still think your version will run quicker? W…

Fair enough, thanks for the comment.

Re: Code Like a Pythonista: Idiomatic Python

#56

Post by sixtofour »

levesque wrote: post #47
sixtofour wrote: post #29

Earlier quoted context omitted.

It's easier to read something quickly if your eyes don't have to travel far. This is why newspapers (remember them?) are written in multiple columns across the page. This may be less of an issue with code, due to its structure, but I still find it much easier to read 80 column code than code that stretches across the screen. If I'm reading code in an 80 column terminal I prefer the line breaks to come from the human…

This is an interesting bit of information. I sometimes find that an equation is harder to read after breaking it in many parts due to the 80 columns limit. It seems there is a compromise to make between the readability of single statements versus the readability of the code as a whole.

Personal preference can confound any rule of thumb.

Cherry picked from here: https://duckduckgo.com/?q=readability+%22column+width%22

https://en.wikipedia.org/wiki/Column_%28typography%29

"For best legibility, typographic manuals suggest that columns should contain roughly 60 characters per line.[1] One formula suggests multiplying the point size of the font by 2 to reach how wide a column should be in picas[2] — in effect a column width of 24 ems. Following these guidelines usually results in multiple narrow columns being favored over a single wide column.[3]"

http://psychology.wikia.com/wiki/Readability

"Ease-of-reading is the result of the interaction between the text and the reader. In the reader, those features affecting readability are 1. prior knowledge, 2. reading skill, 3. interest, and 4. motivation. In the text, those features are 1. content, 2. style, 3. design, and 4. structure[1]. The design can include the medium, layout, illustrations, reading and navigation aids, typeface, and color. Correct use of type size, line spacing, column width, text-color-background contrast and white space make text easy to read. "

Re: Code Like a Pythonista: Idiomatic Python

#57

Post by Goladus »

DasIch wrote: post #54
Goladus wrote: post #22

Just a note: the optparse module is deprecated, in python 2.7+ argparse is preferred.

Doesn't really matter though because using argparse means an additional dependency on <2.7. In practice nobody really uses argparse atm.

It's worth knowing given the intent of the original post.

Re: Code Like a Pythonista: Idiomatic Python

#58

Post by nikatwork »

sixtofour wrote: post #29
arctangent wrote: post #25

One thing that has always bugged me about PEP8 is the advice about trying to keep line length to I basically just completely ignore this part of the guidance, even though I know that in theory it makes it hard to edit code via a terminal. But this is not something we ever do in practice where I work - code on servers gets there only by being checked out of SVN. I personally find it incredibly irritating when I see pe…

It's easier to read something quickly if your eyes don't have to travel far. This is why newspapers (remember them?) are written in multiple columns across the page. This may be less of an issue with code, due to its structure, but I still find it much easier to read 80 column code than code that stretches across the screen. If I'm reading code in an 80 column terminal I prefer the line breaks to come from the human…

Code is not prose. The layout rules that apply to a written article do not (necessarily) apply.

I prefer code that can be quickly scanned, and hard wrapping at 80 columns (IMO) doesn't facilitate this.

If someone doesn't like it, they can turn on text wrap.

Re: Code Like a Pythonista: Idiomatic Python

#59

Post by sixtofour »

nikatwork wrote: post #58
sixtofour wrote: post #29

Earlier quoted context omitted.

It's easier to read something quickly if your eyes don't have to travel far. This is why newspapers (remember them?) are written in multiple columns across the page. This may be less of an issue with code, due to its structure, but I still find it much easier to read 80 column code than code that stretches across the screen. If I'm reading code in an 80 column terminal I prefer the line breaks to come from the human…

Code is not prose. The layout rules that apply to a written article do not (necessarily) apply. I prefer code that can be quickly scanned, and hard wrapping at 80 columns (IMO) doesn't facilitate this. If someone doesn't like it, they can turn on text wrap.

"I prefer code that can be quickly scanned, and hard wrapping at 80 columns (IMO) doesn't facilitate this."

Then you shouldn't hard wrap at 80. Subject to any agreements with your team members. :)

I'm just speculating on why some people recommend to break at 80, which was originally the length of a physical punch card and so has nothing much to do with readability in and of itself. Fundamentally, 80 is likely just the most likely common denominator (MLCD).

Post reply on HN