DEV Community

Python beyond PEP8

Eddy Ernesto del Valle Pino on October 19, 2018

If you write Python and don't know what PEP8 is go and check it now. PEP8 is the style guide for Python code and I think is quite good and I very ...

Read full post

rhymes • Oct 19 '18

Yeah, PEP8 is a little limited. Fortunately there are automated ways to go beyond that.

My favorite tool is black. I think it's better than the pep8 formatter (which as you highlighted is limited) and yapf (which is sometimes weird).

You can integrate it with pretty much any tool (editor, CI, git hooks...) and forget about most of those issues. Give it a try!

Adrian • Oct 20 '18

Worst disadvantage of black? It forces double quotes on you unless you disable quote management altogether.

rhymes • Oct 20 '18

Surrender to the robots :-)

Prettier for JS defaults to double quotes
Rubocop for Ruby defaults to double quotes
black for Python defaults to double quotes and gives a good reason for it:

The main reason to standardize on a single form of quotes is aesthetics. Having one kind of quotes everywhere reduces reader distraction. It will also enable a future version of Black to merge consecutive string literals that ended up on the same line (see #26 for details).

Why settle on double quotes? They anticipate apostrophes in English text. They match the docstring standard described in PEP 257. An empty string in double quotes ("") is impossible to confuse with a one double-quote regardless of fonts and syntax highlighting used. On top of this, double quotes for strings are consistent with C which Python interacts a lot with.

Clayton Parker • Oct 22 '18

Rubocop defaults to single quotes because double quotes do more escaping and interpolation.

docs.rubocop.org/en/latest/cops_st...

rhymes • Oct 23 '18

Thanks Clayton, I remembered it wrongly!

Eddy Ernesto del Valle Pino • Oct 20 '18

I didn't know... Will take a look into it.. even if it enforces double quotes... hahahaha

John Nyingi • Jan 30 '19

Does this apply to string literals?
lets say you have long strings like

err_obj = {
               "status": 400,
               "error": "images should be in uri format(http://img.png)"
         }

Eddy Ernesto del Valle Pino • Jan 31 '19

I would write that as:

error = {
   "status": 400,
   "error": "images should be in uri format(http://img.png)"
}

Considerations:

4 spaces indentation.
Closing bracket at the same level of indentation of the line containing the opening bracket.
Name, err_obj, everything in Python is an object, naming an object "object" does not explains what's the intention or meaning, like naming a view "view" or class "class". So that lefts us with err, and is not much to ask to write a full world: "err" -> "error", specially if this one is short.

Remember we think we are most of the time power typing, but that's not true, in reality most of the time we are reading code, staring into the abyss. Make your code clear, explicit, avoid useless redundancy and don't leave chance for miss interpretation.

John Nyingi • Jan 31 '19

Thanks I'll make changes to my code.

However, I was asking if you have a really long string e.g. my error object, or a regex string. Is there a way to handle exceptionally long strings without using \ newline ?

Eddy Ernesto del Valle Pino • Jan 31 '19

Yes, you can do something like....

some_stirng = (
    "Bla bla bla bla. "
    "More bla bla bla bla. "
    "More bla bla bla bla"
)

Or use multi-line strings, but usually they are inconvenient because they will get the spaces from the indentation.

Eddy Ernesto del Valle Pino • Jan 31 '19

But keep in mind that this is about taste mostly and subjective, so do what ever you feel fits you and your team...

Comment deleted

John Nyingi • Jan 31 '19

I agree

Vincent Dedo • Oct 24 '18

That's some general good style practice, but I'm going to have to disagree on the mega long import. What's wrong with just importing the module you want to use (from django.db.models import expressions)? That way you can more easily avoid name clashes.

Eddy Ernesto del Valle Pino • Oct 25 '18

I'm fine also with that... this was just to illustrate

Ozkar L. Garcell • Oct 31 '18

Recently I was writing a contributing guide for a medium project of my work. There are some Python newbies (I consider myself a newbie as well), and I need explain them some coding guidelines. Definitely I will send them this article. Greetings from Holguín, Cuba.

Eddy Ernesto del Valle Pino • Oct 31 '18

A pleasure Ozkar, long time didn't know about you!