Please rename this tool

[gvanrossum]

Tools should not be named after style guide PEPs. A style guide is a document written for humans, and has lots of subtlety. Issues caused by the rigidity or simplicity of the tool end up causing pointless discussion about the letter of the PEP, as if it was a law, which was never the intention of the PEP. If you want to write a tool that checks style, please give it some clever name, don't name it after a PEP, so it's clear that whenever humans don't like what the tool says, it is a tool issue, not an issue with the PEP (which is merely intended to guide humans, not to require them to follow it every time).

FWIW I am happy that pep8 exist! It can be very useful and I use it myself. But I always let it know who's boss. :-)

[sigmavirus24]

But I always let it know who's boss. :-)

So do most projects. Every project configures it and projects that use it with Flake8 can use it to make their very own styleguides enforced by checks. OpenStack is one of the best examples of this. They understand (like I contest most users do) that pep8 is an unoriginal name for a tool that is a collection of checks inspired by PEP-0008 (which is a distinction most bug reports will make).

it is a tool issue, not an issue with the PEP

Is there an issue with the (self-described) "living" PEPs receiving too many revisions or "bugs"? We've had a lot of people ask to add their own style imperatives to the tool that we've refused. I wouldn't be surprised if some filed bugs about the document itself as a result.

not to require them to follow it every time

Right, except that some projects appreciate enforcing a specific style which is why they use tools like, pylint, pep8, flake8, pep257, etc. An increasing number of projects are including these tools in their testing pipelines so that the project style is consistent.

That said, I'm merely a contributor. I don't own the package on PyPI and I'm not the maintainer. I just strongly disagree that an unoriginal name is a significant problem.

[gvanrossum]

There are definitely people who pick a fight with PEP 8 (the document) based on the behavior of pep8 (the tool). I think it's reasonable to have deviations between the tool and the document, because projects often have style rules beyond the document, and it would be useful to have a way to have those rules checked by the same tool. Just disabling existing rules in the config file is not always enough.

In general it's important to me that when people informally refer to "pep 8" it's clear they are talking about the document -- and when they are talking about the tool they should be able to use a different name, not have to disambiguate between the two by adding "the document" or "the tool".

I understand it's a pain to change a tool's name, and I don't mind keeping the old name around for backward compatibility -- but I really don't like that the two names sound so alike while being entirely different entities in the same space (Python coding style).

In the world of de-facto corporate trademarks you wouldn't have a leg to stand on. But I really don't want to play by those rules, and I promise I won't involve lawyers -- I don't want that to be a threat. I'd just like you to understand my position.

[doismellburning]

I think it's reasonable to have deviations between the tool and the document, because projects often have style rules beyond the document

My understanding is that pep8 aims to implement a subset of PEP-0008, and that @sigmavirus24 has been very thorough at maintaining that.

Thus the only "deviations" should be "things specified in PEP-0008 that pep8 doesn't check for".

@sigmavirus24 Am I correct in thinking that?

@gvanrossum It feels (from your language) like part of your objection is "pep8 checks above and beyond PEP-0008" - is that the case? If so, would you be able to point me towards a specific example please?

[sigmavirus24]

In the world of de-facto corporate trademarks you wouldn't have a leg to stand on.

I'll take issue with this based on the PSF's Trademark Usage Policy. Notice that "PEP" isn't trademarked there. And even if you, at this point, tried to trademark "PEP", then in all likelihood this tool (and the few others) would be grandfathered because they existed long before it, just like PepsiCo's stock ticker predates that and Pep Boys likely has their own trademarks around "Pep" and "Pep Boys" as well as a bunch of other companies and products.

not have to disambiguate between the two by adding "the document" or "the tool".

So the tool's actual name, is PEP-0008. People can call it PEP-8, but in face-to-face (oral) conversations it's hard to have a distinction between "the document" and "the third-party tool that most developers love and some want to die in a fire".

I really don't like that the two names sound so alike while being entirely different entities in the same space (Python coding style).

I don't like it either (although it makes the tool more discoverable) but it's what it is and I have no power to change that unless I usurp development from @IanLee1521 and register a new package on PyPI. I can't upload a package like pytest has with py.test for pep8 on PyPI.

---

Thus the only "deviations" should be "things specified in PEP-0008 that pep8 doesn't check for".

As far as I know, most of those are off by default (i.e., in the DEFAULT_IGNORE list). Other things, are (probably) bugs that Guido has filed bugs for in the last ~6 months or so that were imperfections in PEP-0008 that were translated directly to pep8.

[gvanrossum]

My understanding is that pep8 aims to implement a subset of PEP-0008, and that @sigmavirus24 has been very thorough at maintaining that.

How does the tool deal with recommendations like "know when to be inconsistent," which is pretty prominent in the opening section of the PEP (titled "A Foolish Consistency is the Hobgoblin of Little Minds")? And the claim "it's a subset" doesn't apply to this -- the tool just can't ever maintain the spirit of the PEP. And that's why I think it should not be named "pep8" (nor "pep-0008" or whatever capitalization).

If you are interested in solving this issue I am sure all the practical concerns (like who owns the pypi keys) can be solved. If you are not interested, just let me know by closing this as "won't fix". But please do understand this is a real concern of mine.

[IanLee1521]

I can solve the practical concerns, as I do have the keys for PyPI, ReadTheDocs, and here. I don't disagree enough to say "won't fix", so we should keep the discussion going (I've also been following the conversation over on python-dev).

A couple of other practical issues that I see are:

• What to rename it to?
• The likely fairly long switching over effort for projects (a check on PyPI shows ~ 800k downloads in the last month).

As a bit of an aside, I personally would be happy to see more contributions from the PEP authors to move it into better alignment as needed. Though in all fairness I need to get myself more active on fixing some of the existing issues that have happened since I took over the maintainership.

Additionally, as a full disclaimer I'd personally rather see the tool and document become more in line and more of a requirement for Python syntax, in the way that go / gofmt seem to. E.g. that a uniform style for all Python code is a requirement / expectation and that this is just one style for all code. (Before everyone explodes, I do accept that this is unlikely to ever happen, but I can dream can't I?)

[sigmavirus24]

How does the tool deal with recommendations like "know when to be inconsistent,"

It's a simple tool. At the moment it has no such capabilities. That said, most people don't want inconsistencies. PEP-0008 describes a super-set of style guidelines. When you combine those with other style guidelines (e.g., Google's as some people have done in varying degrees) then you have a custom style-guide which can be enforced by these projects. People who set-up those style guides often (in my interactions) do not want inconsistency.

What to rename it to?

Preferably something obvious. What we won't be able to do is rename the actual module or the entry-point because that will horribly break people's testing integrations and anyone importing pep8. We can change the package, but the entry-point will take a while before we can properly rename.

That said, downloads don't equate to dependencies. Also the download size is likely a factor larger than what PyPI reports because recent versions of pip cache wheels of pep8 and anything depending on pep8 will continue using that cached version so long as the version is satisfactory.

Additionally, as a full disclaimer I'd personally rather see the tool and document become more in line and more of a requirement for Python syntax, in the way that go / gofmt seem to.

That brings up autopep8 as maintained by @myint. What is to be the fate of that tool? There are other tools that are working on autoformatting and I'm working on making Flake8 handle extensions that auto-format code.

The community is heading this way but they want tools that will do it for them (like gofmt does) so they don't have to think about it. The tooling is heading that way. And yet we're still having discussions about tools not being sufficiently flexible.

The Zen of Python encourages us to write the simplest solution, pep8 and pep257 are exactly that.

---

As an aside, @IanLee1521 if you want me to take a more active role in the project, I'm happy to do so. I've avoided it because I haven't heard from you and I'm not sure what benefit there is to having an appearance of activity without being able to publish new releases.

[gvanrossum]

I like these tools. But I can't take on helping to maintain them. If the community wants to encourage automatic formatting I am happy with that too (even though my own needs in this area are mostly taken care of by Emacs and muscle memory :-). But as the primary author of the PEP I want there to be clarity about the difference of the recommendations given by the PEP and the rules implemented by the tool, and that clarity will remain lacking as long as the tool is named after the PEP, attempts to improve the tool notwithstanding.

[scherrey]

pep8lint? Still easy to find in search, isn't confused with PEP8 the document, says what it does and most people know that a lint tool is limited in scope whereas PEP8 may have higher aspirations.

[scherrey]

Of course that name is already taken. Sorry.

[zoidyzoidzoid]

@gvanrossum mentioned in the discussion for pep257's rename, he'd rather not have PEP or the number of the PEP in the tool's name.

[Nurdok]

pep257 is going to be renamed. If pep8 will be renamed as well, it might be a good idea to choose similiarly styled names. Like pycodestyle and pydocstyle, or pycodelint and pydoclint.

[IanLee1521]

@Nurdok, I think this is reasonable. Did you decide if you're leaning more towards *style or *lint ?

Also, is the py prefix redundant? Would not just codelint / doclint work, are is there a concern with those being to general?

[Nurdok]

I was leaning towards *lint, but pycodelint is definitly the worst name in that group, since it will be hard to distinguish from pylint by just the name. I don't mind going with *style, and taking on the name change together will be worth it.

[sigmavirus24]

+1 for *style

[Nurdok]

Since scripts are installed in PATH, there is collision potential with different languages. Also, it makes for a consistent style with pylint and pyflakes (where I work we call them "pychecks" as a group).

[hawkowl]

This is certainly a good idea, I am personally sick of people complaining that Twisted or Twisted-ecosystem projects do not follow PEP 8, because they run flake8 and pep8 freaks out about our newline convention, even though Twisted follows the golden rule of PEP 8 ("A Foolish Consistency is the Hobgoblin of Little Minds") -- we have our own style guide, and our style conventions are older than PEP 8, so it is entirely reasonable we stick with them.

[sigmavirus24]

So I would disagree that the name causes that problem. Different style guides will always cause problems with people who are used to a different style guide. I think it's more likely that a name like pycodestyle will cause problems than pep8.

[hawkowl]

But the problem is that pep8 does not and can not check PEP 8 compliance. It checks compliance for a grab bag of suggestions from the PEP8 document, with none of the sublety of the  document's meaning or stated goal -- which is where I believe gvr's core issue lies. pycodestyle doesn't make any assumptions about what it checks for from the outside alone, and will hopefully break the idea of pep8 throws up on this project vs this project not being PEP 8 compliant. (Seriously, if I had a penny for every time someone said Twisted was not PEP 8 compliant because they've associated the tool's output with the actual PEP, I wouldn't need to worry about writing PSF grant proposals to fund my work ;) )
On 14 Jan 2016 00:11, Ian Cordasco [email protected] wrote:So I would disagree that the name causes that problem. Different style guides will always cause problems with people who are used to a different style guide. I think it's more likely that a name like pycodestyle will cause problems than pep8.

—Reply to this email directly or view it on GitHub.

[Nurdok]

@IanLee1521 so do you like pycodestyle and pydocstyle?

[sigmavirus24]

@Nurdok I registered pycodestyle for Ian (and added him as a package owner). He seemed to be in favor of those names.

Also to answer his question about the py being redundant, downstream packagers will definitely have problems with us not adding some kind of classifier (e.g., py or something else) because codestyle/codelint are way too general.

[IanLee1521]

Thanks Ian. Yes, I think that that pycodestyle and pydocstyle are good ways to go.

Now for the actual transition roadmap, what should be the best order? Just do everything at once (repo , package, and script name), or should there be a more gradual transition?

[sigmavirus24]

I know @gvanrossum will probably hate this but I think both tools should have a deprecation period of ~1 year. pycodestyle/pydocstyle should ship command-line entry-points for pep8/pep257 that issue deprecation warnings when using them.

[gvanrossum]

It's okay. You guys are great for listening!

On Fri, Jan 22, 2016 at 11:30 AM, Ian Cordasco [email protected]
wrote:

I know @gvanrossum https:/gvanrossum will probably hate
this but I think both tools should have a deprecation period of ~1 year.
pycodestyle/pydocstyle should ship command-line entry-points for
pep8/pep257 that issue deprecation warnings when using them.

—
Reply to this email directly or view it on GitHub
#466 (comment).

--Guido van Rossum (python.org/~guido)