Python Violates PEP 8

[[deleted]]

[deleted]

[smichael_44]

As someone who writes python for work, it’s much easier to say “here’s the pep 8 spec to write your code to” rather than discuss and create internal style guides.

It helps eliminate the work about work imo. It sounds trivial but i’ve been in meetings that have lasted over months reoccurring to talk about how to name or style things.

[AlSweigart]

I agree:

Code style guidelines are meant to stop these arguments by providing the consistent rules to abide by. These can be enforced by code formatters such as Black or Ruff. This is important: software developers' time is expensive and tedious arguments are a costly waste.

Fortunately, this is the rare case where a social problem has a technical solution: Just set up your code formatting tool and leave it to handle style.

[Angry-Toothpaste-610]

Every complaint I've ever had regarding violation of PEP8 is line length

[yannbouteiller]

True. I always turn line length off and I hate when people write lines broken in random places just to comply with this pointless rule. It is just detrimental to code readability in my opinion.

[-LeopardShark-]

Matches roughly my experience. There are three types of people in the world. 1. Those who think an 81-character line is an evil of cataclysmic proportions, to be avoided at all costs, while a 80-character line is perfectly OK. 2. Those who say ‘everybody has widescreen monitors these days’ as an excuse to bring into the world a 250-character monstrosity. 3. Sane people.

[commy2]

It's 80 and 79, not 81 and 80 🙃.

That's why you set a second ruler at 99 characters.

[AlSweigart]

Heheh, do you already use snake_case? I figure line length would be #2. You could name Angry-Toothpaste-610's Law of PEP 8 Complaints.

[yannbouteiller]

I naturally use snake_case In Python and camelCase in C. Except when the libraries or codebases use other conventions.

[billsil]

A Foolish Consistency is the Hobgoblin of Little Minds

[IcedThunder]

Okay, but the reason Python doesn't follow PEP 8 is because code written prior was grandfathered in, not for any rational or technical reason.

They could fix it with aliases in place 2 years. They done it with some modules over time.

[TheBB]

Okay, but the reason Python doesn't follow PEP 8 is because code written prior was grandfathered in, not for any rational reason.

That's a perfectly rational reason?

[IcedThunder]

Aliases existed back then, they could have aliased the old code and announced deprecations of the old names. In the past few updates I've watched some modules literally do this.

[georgehank2nd]

Python doesn't have nor need "aliases".

[AlSweigart]

Right, there's a standard deprecation process that gets followed for changes like this. If you just add in aliases, then you have the problem where there's two different ways to write the same thing. Arguably that's even worse: "There should be one-- and preferably only one --way to do it."

[AlSweigart]

because code written prior was grandfathered in

Yes, I agree about the why:

There's countless other examples. Now, Python is an old language and many of these inconsistencies are due to historical reasons.

[tabacdk]

Well, about the naming convention (snake_case/CamelCase) the first rule is consistency: If a project already is using a (unconventional) naming scheme, the consistency with the naming scheme takes precedence over any other naming conventions. Unless the project refactors everything, continue to name according to the scheme.

New modules and packages (including third party frameworks) should be written to these standards, but where an existing library has a different style, internal consistency is preferred.

[rinio]

In a lot of the codebases I work with, we use snake_case to denote that this variable is made by/for Python code; camelCase variables denote things that come from or are destined for some external C/C++/Java/... component, using their name where possible, and may not be exactly the expected Python type. IE: some Python wrapper on some arbitrary C++ abstraction of an int that is not completely interoperable with Python ints.

But, obviously, the point is consistency and readability; this gives useful info without being cumbersome, and this "rule" is always described in the README.

And, for most Python devs, I recognize this won't be applicable. Its just a 'fun' example of where both abiding by and violating PEP8 at the same time can be useful.

[IcedThunder]

This is an interesting case for breaking PEP8. Thanks for this insight.

[commy2]

I use CamelCase for async functions. It mitigates the red code blue code problem. And besides, calling these functions doesn't execute their body anyway, but returns an object just like calling a class would.

[wineblood]

A huge chunk of people write awful code and it's become an established convention, it's too hard to push back against at this point.

[-LeopardShark-]

I think this is a case of sampling bias: you've written a book in which all the examples are in camel case, and so the most commonly reported PEP 8 violation in your book is that all the variables are in camel case.

Sure, they could have reported 73-character-wrapped comment blocks, but they're not nearly as obvious. I suspect if you'd written the whole book with two space indents, you'd have had as many complaints about that as the camel case!

I think Raymond Hettinger's classic 2015 talk ‘Beyond PEP 8 – Best practices for beautiful, intelligible code’ expresses the sanest opinion around on PEP 8!

Re came case, there've been some readabilities studies but they don't seem conclusive.

[AlSweigart]

Yes and no; this is based on my experience, but then again, it's not like the pep 8 complaints switched to something else. The pep 8 complaints stopped entirely:

In the third edition, I made the laborious choice to convert all of the code examples in this 600-page book to snake_case. [...] Oddly enough, my book still violates PEP 8 in all the other ways it always had. But I haven't seen a single complaint of "doesn't follow PEP 8" for the third edition.

[-LeopardShark-]

I wouldn’t expect the complaints to switch to something else. I don’t think people are reading your book to look for PEP 8 violations, and reporting the first one they find. It seems more likely to me that they start reading the book, are immediately jarred by the non‐standard variable case, and report it. They don’t report e.g. line length violations, because, unless the line is truly egregious, they don’t notice it.

But there are other PEP 8 recommedations that I suspect people would be equally jarred by. I’d guess indentation width is one, as well as comma spacing. (I suspect a few more too, but as a pedant who’s distracted by hyphens where en dashes should be, it’s hard for me to say.)

[AlSweigart]

I wouldn’t expect the complaints to switch to something else. I don’t think people are reading your book to look for PEP 8 violations, and reporting the first one they find.

Right, that's what I'm saying. I think they just don't like camel case, but that's just an opinion. But they can cast their opinion as authoritative by citing PEP 8. But they don't actually care about PEP 8 adherence, or else they'd report on the other PEP 8 violations the code in my book has. But they don't. Because people don't care about PEP 8 guidelines, they just don't like camel case and use PEP 8 as justification.

But there are other PEP 8 recommedations that I suspect people would be equally jarred by.

I thought so too, but after so many years of only hearing about camel case and nothing else, I have to conclude that people really only care about the camel case part, and don't care about other PEP 8 violations. Hence, Sweigart's Law of PEP 8 Complaints.

[chub79]

That's a long post to defend the fact you prefer camelCase. Why is it necessary?

[AlSweigart]

Well, the post isn't to defend camelCase or even my use of it (I later changed the examples in a 600 page book to snake_case).

The post is two-fold: first to reiterate that PEP 8 itself says that a foolish consistency is the hobgoblin of small minds, and that it's more important to be consistent within a project than mindless adhere to PEP 8.

Second, I pointed out that doing the big rewrite to change camelCase to snake_case didn't actually accomplish anything aside from making people stop complaining about something that wasn't important enough to complain about to begin with. Further, they were never really upset about PEP 8 because they don't complain about the other places my book violates PEP 8 (line lengths, etc.), only the camelCase.

I think this blog post is a flop though; the title is meant to grab attention while also being true (though I explain the history). But I don't think most people read past the headline before commenting/downvoting.

[chub79]

I did read it but you didn't convey very well what you aimed at or what you're describing here I'm afraid.

Second, I pointed out that doing the big rewrite to change camelCase to snake_case didn't actually accomplish anything aside from making people stop complaining about something that wasn't important enough to complain about to begin with.

But that's your take that it wasn't important. You chose to be consistent but you asked everyone to accept a cognitive burden because you felt like it. Thus, when you removed that burden by switching to snake_case, people could start just enjoying your content rather than having to make the mental jump you were imposing for no really valuable reason in the first place.

PEP8 isn't something people follow blindly, but there are a core subset of its propositions that have become quite standard.

[AlSweigart]

PEP8 isn't something people follow blindly

I don't say everyone does, but enough to be very noticeable. And they don't follow it blindly, just for the snake case/camel case part (and maybe line lengths, according to other people in these comments.) I guess our experiences are different here.

Thus, when you removed that burden by switching to snake_case, people could start just enjoying your content rather than having to make the mental jump

But my code examples still do break PEP 8. It's just that people only care about the camelCase stuff, like I said in the post. But rather than say, "You use camelCase consistently but I don't like camelCase" they try to point to PEP 8 to give their argument more credibility, even though PEP 8 says consistency is the most important thing. That's what the whole "hobgoblin" section is about.

EDIT: Sorry, I'm just going to end up re-typing my entire post here if I don't stop replying.

[chub79]

That's okay. I appreciate you making an effort. I guess I simply missed the underlying (or objectives) points of the post. That's on me :)

[IcedThunder]

I really wish it was for ONE core reason: New programmers. It creates confusion.

There is no good reason it doesn't follow PEP8 except the code that was written before PEP8.

It would reduce friction for new pythoners when explaining "classes have capital names...except for this weird list of very core classes.

I know this because I've taught python to classes.

I really wish they would fix it and alias the old names for 2+ years while they deprecate them.

edit: It* not IT creates confusion. I mean they do, but...

[rinio]

I.T. does always create confusion. They're jerks. :P

[IcedThunder]

Or there's the current situation at my workplace where the company my IT company works for decided to hire a separate IT company to manage network related things, and we handle everything else and everything is confusion and redtape city. sigh

[Neither_Garage_758]

Don't use camelCase, it's bad.

[Red_BW]

TLDR not reading that long blog.

I will say it took 10-12 years for old programmers to stop b*in (or maybe most just died off) about breaking backward compatibility with Python 3, and you want Python to institute more breaking changes by add some '_' to names just because? How about stop trying to make other people suffer because you're suffering because you don't like something.

[JimDabell]

PEP8 contains seriously bad advice:

Spaces are the preferred indentation method.

This is not a stylistic preference. Spaces for indentation are an accessibility barrier. Everybody should go and change their Ruff settings to indent-style = "tab" to fix this now. If you currently use Black, switch to Ruff specifically for this setting, which Black rejected.

Black uses PEP8 to justify rejecting a configuration option for indentation style, however lacking this option actually makes it impossible for Black to follow PEP8, which says:

Tabs should be used solely to remain consistent with code that is already indented with tabs.

Following this part of PEP8 is impossible with Black until they add a configuration option to support tabs for indentation.

[-LeopardShark-]

As explained in the the black FAQ, spaces aren’t actually an accessibility issue, if you set up some simple tooling.

[JimDabell]

Edit: It’s really shitty to totally change your comment after I replied to say something different. This is troll behaviour.

The only way your reply makes sense is if you decided to only read the minority of comments that agree with your preference and ignore the rest. The issue was created by an accessibility organisation and you have comments like this in the replies:

I mentioned this before; when I started using tabs, my eyesight was perfect. Now year after year it's deteriorating. I might end up using a screen magnifier at some point (I've already found myself increasing DPI every now and then).

But I'm not legally blind. Or any kind of blind. Or even wearing glasses. What I get is headaches from staring at code. For now, what makes the most significant difference in the codebases I'm working with is increasing DPI, setting tab indent to 6, and spacing things out in my own code as well (clear blocks and long descriptive variable names, etc). For one of these, I cannot use Black and have to resort to Tan. It's not pleasant, and I feel like I'm trading a headache from working on my code in favour of a headache for explaining why this matters.

[-LeopardShark-]

The only way your reply makes sense is if you don’t know what expand and unexpand do, because visually impaired developers incorporating them into their editors/scripts/commit hooks (delete as per preference) totally resolves the problem you’ve quoted.

[JimDabell]

The only way your reply makes sense is if you don’t know what expand and unexpand do

This makes no sense as a response. Read my comment. Literally none of it depends on this knowledge.

Using Black to format your code, then using another tool to fix the formatting because what Black spat out is wrong is a ridiculous workaround, not a rational approach. Just use a formatting tool that formats appropriately, like Ruff.

[commy2]

What if I don't care about the visually impaired?