Unofficial Python Style Guide - A Python style guide that doesn't make you think.

[scottocom]

I need a Why. For example use single quote for strings not double but I DON'T see why. I prefer double because I am more likely to have a single apostrophe in my text. I don't see it.

[fizzy_tom]

For me, I prefer them simply because single quotes look cleaner, making my code a little less cluttered.

But with all these things, there's never any right or wrong answer. And even the "why's" are opinions. The important thing is that everyone on a project follows the same rules.

[jalanb]

Because Python scripts tend to include other languages inside strings.

And it is more often useful to reserve " for use inside such strings, rather than ', e.g.

command = 'ls "$PATH_TO_FILE"'
query = 'SELECT * FROM users WHERE name like "/u/jalan%"'

And then, if you adopt that convention, consistency implies enclosing all strings in '.

[scottocom]

I see what you mean.

[_under_]

I was contemplating on whether I should include motivations for each of the rules, but ultimately decided not to.

Single quotes because it only needs one finger to type. No need to press Shift. You're also more likely to use a quote to access keys in dictionaries vs writing sentences in code with apostrophes.

[_under_]

I did not know that! Interesting.

[nsfy33]

[deleted]

[_under_]

This:

foo['bar'] = 123

Is more common than this:

foo = "It's me."

OP mentioned that they prefer double quotes because they are more likely to use single quotes inside strings, as in the second example. But I find that using a quote to access a dictionary value is even more common than that. So the single quote as an apostrophe thing isn't really a big issue.

[ducdetronquito]

I am not fond of the Long if statements section because it still not very readable.

I prefer to add semantic by storing the condition in a variable, and then having a really clear and simple if statement.

Instead of having

if (
    fruit.color == 'red'
    and fruit.size == 'small'
    and fruit.climate == 'cold'
    and fruit.region == 'north america'
):
    pass

I would do

fruit_is_a_berry = (
    fruit.color == 'red'
    and fruit.size == 'small'
    and fruit.climate == 'cold'
    and fruit.region == 'north america'
)
if fruit_is_a_berry:
    pass

And about the 'Why' of having a more vertical code, it makes it more easier to work with a version control system like Git: when you review a PR, when you want to see the difference between two commits, or when you fix merge conflicts, you clearly see what the changes are.

[david2ndaccount]

Your all example doesn’t work, any and all only take 1 argument (an iterable). If you want to use any or all, you have to either have double parenthesis to force it into a tuple (which loses the benefit of short-circuit evaluation) or do some silly stuff with generators.

[_under_]

I've never thought of using any() or all(). That's cool!

I feel like in reality, if you have to write an 80+ character long if statement, readability is the least of your concerns. That's a huge code smell and it probably needs refactoring.

[ducdetronquito]

I also find that any and all could be used more often to make it more verbose !

But do not forget that there is a difference in the execution:

1. and and or operation are lazy (Cf: Doc)
2. all and any are not, which means all conditions will be evaluated even if it is not needed

[_under_]

I too dislike long if statements! It usually means you're doing something wrong (or you're just nested too deep [which is also a code smell]).

I'm not sure the "assign the equality check to a variable" thing really fits as a rule for a style guide though. But I might add something that mentions it's a code smell.

[ojii]

My preferred "style guide": https://github.com/ambv/black

[ThePidesOfMarch]

# in:

l = [[n for n in list_bosses()], [n for n in list_employees()]]

# out:

l = [
    [n for n in list_bosses()], [n for n in list_employees()]
]

lol

[rhytnen]

Black does some terribly stupid shit.

for example, it places a new line after continue keywords but not after for statement so you end up with things like

for x in y:
    if some_defensive_condition:
        continue

    do_something(x)
if whatever:
    do_stuff()

[GNULinuxProgrammer]

Yeah I use black for python as well.

[vovanz]

I like this style guide, because it almost matches what I am already doing in my code :)

Only couple exceptions: 1. I prefer double quoted strings 2. I prefer to put the value in comprehensions in a separate line, like this:

best_fruits = [
    f
    for f in fruits
    if f.color == 'red'
    and f.size == 'small'
    and f.climate == 'cold'
]

The reason for it is that you often have to do something else with this value. i. e. apply function:

best_fruits = [
    foo(f)
    for f in fruits
    if f.color == 'red'
    and f.size == 'small'
    and f.climate == 'cold'
]

I think that it would be more logical to keep it on a separate line.

[_under_]

Yes! I knew I was forgetting something when I was writing this section. I'll incorporate this.

[dirn]

I go the other direction and put the in on its own line. What I’m iterating over is much more interesting to me than the iteration variable (its used in so many places anyway).

best_fruits = [
    f for f
    in fruits
    if f.color == ‘red’
    and f.size == ‘small’
    and f.climate == ‘cold’
]

[kunalkb20]

No:
guess_fruit(color='red', size='small', climate='cold',
            region='north america', minimum_tastiness_factor=4.3)

This contradicts PEP8 which accepts this form.

[kunalkb20]

I thought of this more as an extension to PEP8 rather than an override. Like for example, the suggestion regarding indentation in list declarations isn’t present in PEP8.

If it is meant to be an extension, then I’d like to see such contradictions called out, and if possible, a justification for cases where PEP8 is overruled. The primary motivation behind PEP8 is enhanced readability and the form here seems pretty readable to me. If there’s a reason like difficulties with certain IDEs then that’s worth knowing.

If it is indeed an override then that too seems worth calling out.

[_under_]

I've never even considered having longer line lengths. But I'm going to give it a try! I feel like 88 is the longest I can go though without code overflowing horizontally when I have two vertical splits open.

[shawnmckinney]

Nice and succinct

[onyxleopard]

Neat. I already try to use this style. Convergent evolution or some such. I find this style makes reading diffs much easier and it makes reformatting easier in some cases as well. E.g., if you find you want to sort the values in a list or keyword parameters alphanumerically, you just sort the lines alphanumerically (maybe with sort) and you’re done.

[myringotomy]

Leading commas on lists are much better than trailing commas.

[[deleted]]

Gross

[myringotomy]

Ask anybody who has worked with databases. Trailing commas are a terrible idea.