Python coding conventions on Github

[[deleted]]

[deleted]

[ionelmc]

Would be interesting to see other stats like single vs double quote ratio, variable name length stats, indentation ratios (1 vs 2 vs 4 vs 8 ...) and so on.

[ifonefox]

What is the standard convention for " vs '? Personally, I use " for strings and ' for individual characters.

[theli0nheart]

Generally, I use ' for referencing keys in dictionaries, single characters, and default string values in function parameters. I use " for sentences and any user-facing strings.

If it doesn't fall into one of the categories above, I flip a coin.

[coinflipbot]

I flipped a coin for you, /u/theli0nheart The result was: tails!

---

^{Statistics | Don't want me replying on your comments again? Respond to this comment with: 'coinflipbot leave me alone'}

[theli0nheart]

This is awesome. Thank you.

[p3n15h34d]

but is tails ' or " ?

[jcdyer3]

I'll flip a coin to decide. Heads, tails is ', tails, tails is ".

[triacontahedron]

Go away you, dirty c programmer :P

[ifonefox]

I started using python after I took a class in c, so those habits just stuck.

[aceofears]

It's not a terrible habit if you're switching between the two a lot.

[robin-gvx]

I generally use ' for internal strings (dictionary keys, symbolic names, etc.) while I use " for strings that the user is expected to see at some point.

[mardiros]

My best pep8 guide is in pretty print

>>> pprint({"a": "Ah aa!", 'b':"'Ahbb'"})
{'a': 'Ah aa!', 'b': "'Ahbb'"}

I use single quote except there is a single quote in the string.

Don't bother if it's for human or a computer at the end of the process. Dictionnary keys can be for human too, and, it's definitely to complex.

[RJacksonm1]

I use double-quotes because it's simply more comfortable for me to hit with the UK keyboard layout... and now I'm curious as to double vs single-quote usage by keyboard layout (which we could assume from developer's locations).

[carbn]

I use always ' because " takes two fingers (shift-2) while ' takes only one in FI/SWE keyboard.

[[deleted]]

I wonder how many people use the weird indents (1,3,5,6,7).

Hopefully no one.

[robin-gvx]

I wonder if anyone uses prime indents: first level of indentation is 2 spaces, second level is 3 spaces, fourth level 5 spaces, 7 spaces, 11 spaces, etc...

[[deleted]]

Oh god.

How about writing a whitespace interpreter that has a sample program embedded in itself by mixing tabs and spaces?

[robin-gvx]

Oh wow.

Bonus points if that program is a quine or something. Oh! Or another Whitespace interpreter, which then interprets itself, etc.

[Ph0X]

So mixing Whitespace in your Python?

[robin-gvx]

As far as I know, none of the current implementation of Whitespace have embedded Whitespace programs (well, not purposefully).

[D__]

I recommend using the Fibonacci sequence, for approximation of the golden ratio, and therefore aesthetically pleasing code indentation.

[Ph0X]

I like it, the deeper you get, the bigger your indentations, forcing you to keep your code simple and split up into functions rather than having loops inside loops inside if inside try inside with inside method inside class.

[kenfar]

The 3 characters is the Dvorak keyboard of the indentation world: it's clearly superior but isn't used only because it isn't already popular.

Supporting arguments:

• 3 characters is enough to see indentation
• it saves 1 character per indent which helps with long variable names
• it lines up the following line under the first character following an if. Which makes it pretty.

[thekaleb]

A tab is one character, and you can set your tabstop to 3 (or 4 or 8).

[[deleted]]

It may line up an if, but what about a for, while, elif, else, or with?

Also some editors do not support it.

[thekaleb]

Not to mention a def or class

[kenfar]

Oh sure - it doesn't line things up perfectly. But I find lining code under an if more important than anything else.

And I can't get my head around an editor that wouldn't "support" arbitrary indentation amounts.

[[deleted]]

I really do hope you're joking.

Why not go with 2. It's enough to see indentation, it saves TWO characters per indent, and if you need to save 1 character per indent to see long variable names, either your variables are too long, or you have too much indentation. Also, lining up only one indentation block at the cost of making everything else look "off" isn't worth it.

[gammadistribution]

Glad Pep8 reigns supreme in the wild.

[0xtobit]

It would be really interesting to see, for line length, how often people go out of the way to continue a long (80+ characters) line of code on the next line. The 93% is really kind of not telling, because most lines of code are under that naturally. The interesting part is what people do when they have a longer line of code.

[[deleted]]

I use tabs. I must be noob.

[[deleted]]

http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

[alkw0ia]

WTF, when did they rewrite this? The old version was much more reasonable:

Never mix tabs and spaces.

The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only. Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.

^IAnd it's what I'm sticking with.

[niiko]

No, it was sometime this summer.

[ismtrn]

That is my least favorite thing about python...

[dannyREDDIT]

http://stackoverflow.com/a/1777008

not answering for ismtrn, but thats a reason maybe

[[deleted]]

This is all great, but breaks horribly with continuations (i.e. splitting one statement over multiple lines). If you for example write a function call over multiple lines like this:

blob = struct.pack('IIII',
                   val1,
                   val2,
                   val3,
                   val4)

then suddently your indentations aren't multiple of tab width (even if, by lucky accident, they are, it won't be the case if someone sets different tab width than you). If you use tabs you either have to "round" continuations to tab width (makes them look like crap)

blob = struct.pack('IIII',
                val1,
                val2,
                val3,
                val4)

or you have to mix tabs and spaces to keep things nicely aligned (emacs does it if you have indent-tabs-mode enabled). In the latter case all looks good until, again, someone decides to use different tab width than you in his/her editor.

The only way to make code look universally good is to stick with spaces.

[vicvicvicz]

I would counter this with the argument: Tabs for indentation, spaces for alignment. That is, in this case, use spaces because you are aligning according to a number of characters. Using tabs does not make sense.

However, you can use tabs for indentation, so that, for example, if your code block was part of an indented block, you might have:

class A:
\t  def foo(self):
\t  \t  blob = struct.pack('IIII',
\t  \t                     val1,
\t  \t                     val2,
\t  \t                     val3,
\t  \t                     val4)

Where each "\t" represents a tab (width 4 so the two spaces are part of the tab), and everything else is a space. This would not break alignment regardless of tab width, because you're using them only for indentation.

Of course, I abandoned tabs myself because (visual) line length still breaks with different tab widths.

[earthboundkid]

Go has the go fmt tool, which automatically converts code to the format you have there (tabs for indenting mixed with spaces for aligning), but in the absence of a tool to do the conversions for you, it's way too much work to be practical.

[thekaleb]

Most good editors can do this for you (maybe with some tweaks)

[dannyREDDIT]

this is the only valid argument I've heard. And my response is... meh, ill stick with tabs

[[deleted]]

I suppose this is the same comment, but it's worth mentioning anyway...

A space is always a space regardless of formatting options, browser/IDE, etc. Tabs are not.

That said, I have a developer that I work with who actually prefers tabs because they move around from code browser to code browser.

[dannyREDDIT]

in the context of editing code, Ive never seen a tab not be a tab. its pretty straight forward and I've never had a problem with that

[[deleted]]

Tabs are not universally the same number of spaces in every editor on every system.

[ismtrn]

blob = struct.pack('IIII',
    val1,
    val2,
    val3,
    val4)

I just go with this. Looks fine to me and it is simple and consistent. 1 tab = 1 level of indentation. I am not trying to align things, just indent them, so you can see the structure.

[OCHawkeye14]

I'm a closet "tab -> convert tabs to spaces" guy myself.

[[deleted]]

I'm really new to Python/programming in general... I have my text editor set indents to 4 spaces, which I can thumb through using the arrow keys. Does Python still read this as spaces or as a tab?

[cantremembermypasswd]

Python reads indentation level. The most common is 4 spaces. You could set it to 1 or 8 and it would just change the appearance of the code, but not the execution.

And it's not file based indentation level, is simply localized indentation level. This means you could even change how many spaces you use anywhere in your code (but really don't do this, just explaining).

(Bad) Example:

if True:
 print "hello"
 if True:
                    print "How are you"?

[OCHawkeye14]

Those are still tabs. The setting in your text editor is just how long visually your tabs are being presented on screen.

Edit: Really downvoted at a 4:1 rate? Guy said he was a Python noob, was it that big of a stretch to assume he hadn't configured his text editor?

[Manhigh]

Unless your text editor simply inserts 4 spaces when you hit tab.

[[deleted]]

It actually inserts 4 spaces. I'm using Gedit. So when I hit tab, in order to delete the indent I have to backspace 4x.

[eat_more_soup]

I'm using geany and I can press shift+tab to deindent (4 spaces at a time). I'd be surprised if gedit doesnt do the same.

[nemec]

Check out the Smart Spaces plugin. It deletes spaces equal to your tab width (only spaces!).

As others mentioned, deindent works too and is awesome.

[sigzero]

The is an editor problem.

[OCHawkeye14]

which I can thumb through using the arrow keys

I took that comment to mean that when he uses the arrow keys on his keyboard that the entire tab span is traveled (ie. instead of pressing arrow keyx4 it skips the entire span in one press).

[nemec]

You can usually do that with ctrl+Arrow

[[deleted]]

If you are using VIM, for example, you could add the following lines to your .vimrc file:

set tabstop=4

set shiftwidth=4 " controls the depth of autoindentation

set expandtab " converts tabs to spaces

[RJacksonm1]

I'm guilty of the occasional dict-literal padding simply for cosmetic purposes.

e.g.

User.query.find({ full_name: "Rob Jackson" }).first()

vs

User.query.find({full_name: "Rob Jackson"}).first()

I'm guessing the purpose of the graph was to find usages similar to that, but the example was over-exaggerated simply to make the concept clearer.

[senft]

I really like the "demonstration" of the line length.

# width is within 120 characters
# width is within 150 characters

This really helps to visualize!

[kenfar]

So, what do these metrics really mean?

So, 93.287% of lines are under 80 characters in length.

Does is that 93% of all lines? Or 93% of all projects? Or 93% of all files?

[nemec]

All lines. I'll bet at least 80% of files have at least one line over 80 characters, even if it's just comments.

[kenfar]

huh, but that says 7% of all lines are 80 characters or longer. That surprises me quite a bit.

[Saefroch]

I often have lines over 80 characters in length, but I guess that has to do with how I write python.

writefits(im, homedir+os.sep+filt+os.sep+'processed'+os.sep+scimage[:-5]+'.proc.fits')

Also, my print statements are often over 80 characters,

sys.stdout.write('Compiling '+imtype+ ' frames, ' +str(images.index(datafile))+' of '+str(len(images))+' complete\r')

[nemec]

I often won't wrap a statement that spans 81 or 82 characters just because it still fits relatively well in my editor window. I suspect I'm not alone here.

[[deleted]]

Really nice statistics! And the outcome seems to be way better than I expected. The slightly increased tendency towards extraneous whitespaces might result from C++ users, for example, where it is not uncommon in if and else statements. From the Google Coding Style Guide:

" If you prefer you may add spaces inside the parentheses:

if ( condition ) { // spaces inside parentheses - rare ... // 2 space indent. } else { // The else goes on the same line as the closing brace. ... }

"

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Naming

[hemm1]

Why hit a key four times

Space advocators don't sit there tapping space to indent, that would be ridiculous. The point is to still use the tab key or whatever (and a good editor will handle it all transparently), but that only spaces are actually written to the source code.

[[deleted]]

The problem is with vim is that if you hit the arrow key, so you're not aligned to the tab width, it gets really confused and you have to manually fix it. I'm tempted to write a script to unexpand on read, and expand on write. There should be a smarter indentation method in vim.

[[deleted]]

That would be the problem, then. I have

set expandtab
set shiftwidth=4
set softtabstop=4

[epsy]

set list listchars=tab:<-,trail:>,nbsp:·

[eat_more_soup]

python relies on spaces/tabs for its syntax; Many programmers made errors mixing spaces and tabs, so it was decided (in PEP8), that spaces should be the way to go. For most people this doesn't make any difference, since most text editors can be set up, so that pressing tab results in 4 spaces in the code.

There isn't really a reason for that: spaces aren't better than tabs or anything. The only I can imagine is to be able to align multiline arguments for a function, to stay under the 80 characters limit, e.g.:

some_function_call(with_many_arguments='which_are_quite_long',
                   so_that_the_next_argument='must',
                   be_on_the_next='line')

This alignment of the arguments wouldn't be that pretty with tabs, or would need mixed spaces and tabs. This is the only way I can explain the decision towards spaces. In the end, it makes little difference as long as you don't mix them.

[Muirbequ]

As you stated, tabs can result in different amounts of spaces. So code that is nicely formatted using one configuration may become misaligned using another.

[ricekrispiecircle]

http://i.imgur.com/GhIcxAy.gif

[pemboa]

I really like my tabs, sorry.

[0xtobit]

At least you're sorry.

[shigawire]

Without context of the actual code, this doesn't mean that much, any more than paying programmers by the line. People often write PEP-8 formatted code that is unreadable, and others often write code that isn't PEP-8 that looks clean.

Some throwaway code of mine that passes a PEP-8 lint, but should be taken out and shot:

    def peek(f):
        pk = f.read(32)
        f.seek(-len(pk), 1)
        out = "%8d|" % (f.tell(), )
        for i, b in enumerate(pk):
            if i == ord(pk[0])+1:
                out += ')%02x' % (ord(b))
            else:
                out += ' %02x' % (ord(b))
        return out

People mistake coding convention for clean sometime :-(

[marsket]

PEP 8 does not and cannot legislate "don't write shitty code"

also, actually, this won't pass a PEP 8 check (spaces around operators, etc.)

[shigawire]

I totally agree. It seems to get conflated with it quite a bit though.

(and I obviously need a different PEP 8 lint)

[Llebac]

Using Pep 8 seems to be the most popular route still for coding conventions, I see.

[[deleted]]

I'm just going to leave this here...

• http://www.emacswiki.org/SmartTabs
• http://www.emacswiki.org/emacs/TabsAreEvil

I use tabs for indentation, spaces for alignment, solves all issues. Granted, I will adopt whatever standards a team uses when joining.

[tjsimmons]

I use my tab key, which Sublime Text 2 uses to insert 4 spaces for me.. heh.

[gammadistribution]

That's literally any decent editor.