New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please rename this tool #466

Closed
gvanrossum opened this Issue Jan 4, 2016 · 55 comments

Comments

Projects
None yet
@gvanrossum

gvanrossum commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 4, 2016

Member

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.

Member

sigmavirus24 commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum Jan 4, 2016

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.

gvanrossum commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@doismellburning

doismellburning Jan 4, 2016

Member

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?

Member

doismellburning commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 4, 2016

Member

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.

Member

sigmavirus24 commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum Jan 4, 2016

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.

gvanrossum commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@IanLee1521

IanLee1521 Jan 4, 2016

Member

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?)

Member

IanLee1521 commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 4, 2016

Member

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.

Member

sigmavirus24 commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum Jan 4, 2016

gvanrossum commented Jan 4, 2016

@scherrey

This comment has been minimized.

Show comment
Hide comment
@scherrey

scherrey Jan 9, 2016

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 commented Jan 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@scherrey

scherrey Jan 9, 2016

Of course that name is already taken. Sorry.

scherrey commented Jan 9, 2016

Of course that name is already taken. Sorry.

@zoidbergwill

This comment has been minimized.

Show comment
Hide comment
@zoidbergwill

zoidbergwill Jan 9, 2016

@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.

zoidbergwill commented Jan 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Nurdok

Nurdok Jan 11, 2016

Member

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.

Member

Nurdok commented Jan 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@IanLee1521

IanLee1521 Jan 11, 2016

Member

@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?

Member

IanLee1521 commented Jan 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Nurdok

Nurdok Jan 11, 2016

Member

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.

Member

Nurdok commented Jan 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 11, 2016

Member

+1 for *style

Member

sigmavirus24 commented Jan 11, 2016

+1 for *style

@IanLee1521 IanLee1521 added this to the 1.7 milestone Jan 11, 2016

@Nurdok

This comment has been minimized.

Show comment
Hide comment
@Nurdok

Nurdok Jan 12, 2016

Member

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).

Member

Nurdok commented Jan 12, 2016

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 comment has been minimized.

Show comment
Hide comment
@hawkowl

hawkowl Jan 13, 2016

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.

hawkowl commented Jan 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 13, 2016

Member

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.

Member

sigmavirus24 commented Jan 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hawkowl

hawkowl Jan 13, 2016

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 notifications@github.com 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.

hawkowl commented Jan 13, 2016

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 notifications@github.com 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

This comment has been minimized.

Show comment
Hide comment
@Nurdok

Nurdok Jan 21, 2016

Member

@IanLee1521 so do you like pycodestyle and pydocstyle?

Member

Nurdok commented Jan 21, 2016

@IanLee1521 so do you like pycodestyle and pydocstyle?

@sigmavirus24

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 22, 2016

Member

@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.

Member

sigmavirus24 commented Jan 22, 2016

@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 IanLee1521 modified the milestones: 2.0, 1.7 Jan 22, 2016

@IanLee1521

This comment has been minimized.

Show comment
Hide comment
@IanLee1521

IanLee1521 Jan 22, 2016

Member

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?

Member

IanLee1521 commented Jan 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Jan 22, 2016

Member

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.

Member

sigmavirus24 commented Jan 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum Jan 22, 2016

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

On Fri, Jan 22, 2016 at 11:30 AM, Ian Cordasco notifications@github.com
wrote:

I know @gvanrossum https://github.com/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)

gvanrossum commented Jan 22, 2016

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

On Fri, Jan 22, 2016 at 11:30 AM, Ian Cordasco notifications@github.com
wrote:

I know @gvanrossum https://github.com/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)

@IanLee1521

This comment has been minimized.

Show comment
Hide comment
@IanLee1521

IanLee1521 Feb 1, 2016

Member

Ok, I propose the following as the transition timeline (dates are all approximate at this point):

This week -- Rename the repo here on GitHub to pycodestyle, while leaving the code untouched for the moment. This will alert developers looking for the repo to the change thats coming. Also, push the 1.7.0 code to the pycodestyle package on pypi, meaning there will be both a pep8 and a pycodestyle package available on pypi.

~ March 1 -- Update flake8 and other similar tools to start depending on the new package, pycodestyle, which would likely be transparent to those users that only interact with this package via those tools.

~ April 1 -- Add deprecation warning to the pep8 tool that users should instead install pycodestyle (which at that point should probably start installing a pycodestyle console_entry in addition to the pep8 console command.

~ June 1 -- Update code base to start only referring to pycodestyle as the command, removing references to pep8, except maybe keeping the console script that is installed (still installing both pep8 and pycodestyle. (Though maybe this should technically occur before May 28, e.g. PyCon 2016? Maybe that has value?)

~ September 1 -- Remove pep8 command from installation of both the pep8 and pycodestyle python packages on pypi. Double check that the usage on pypi of pep8 is shrinking.

~ December 1 -- Remove the pep8 package from pypi. @gvanrossum rejoices! :)

Those are my thoughts, trying to keep in line with @sigmavirus24 suggestion of a 1 year deprecation period. I'd be open to moving faster, but probably not less than a month or so for each of the steps, which would move the December 1 target up to July 1. Thoughts?

Member

IanLee1521 commented Feb 1, 2016

Ok, I propose the following as the transition timeline (dates are all approximate at this point):

This week -- Rename the repo here on GitHub to pycodestyle, while leaving the code untouched for the moment. This will alert developers looking for the repo to the change thats coming. Also, push the 1.7.0 code to the pycodestyle package on pypi, meaning there will be both a pep8 and a pycodestyle package available on pypi.

~ March 1 -- Update flake8 and other similar tools to start depending on the new package, pycodestyle, which would likely be transparent to those users that only interact with this package via those tools.

~ April 1 -- Add deprecation warning to the pep8 tool that users should instead install pycodestyle (which at that point should probably start installing a pycodestyle console_entry in addition to the pep8 console command.

~ June 1 -- Update code base to start only referring to pycodestyle as the command, removing references to pep8, except maybe keeping the console script that is installed (still installing both pep8 and pycodestyle. (Though maybe this should technically occur before May 28, e.g. PyCon 2016? Maybe that has value?)

~ September 1 -- Remove pep8 command from installation of both the pep8 and pycodestyle python packages on pypi. Double check that the usage on pypi of pep8 is shrinking.

~ December 1 -- Remove the pep8 package from pypi. @gvanrossum rejoices! :)

Those are my thoughts, trying to keep in line with @sigmavirus24 suggestion of a 1 year deprecation period. I'd be open to moving faster, but probably not less than a month or so for each of the steps, which would move the December 1 target up to July 1. Thoughts?

@doismellburning

This comment has been minimized.

Show comment
Hide comment
@doismellburning

doismellburning Feb 1, 2016

Member

~ December 1 -- Remove the pep8 package from pypi.

How about a new version with a setup.py that errors out with a helpful message (cf. https://github.com/pytest-dev/pytest/blob/1f6988bdec07caa0c6488a488b390beeed32e529/extra/setup-py.test/setup.py)

Then you're still providing downloads for people yet to update (if they're pinned to old versions), while providing a good user experience for people updating existing dependencies AND for those in the habit of just doing pip install pep8

Member

doismellburning commented Feb 1, 2016

~ December 1 -- Remove the pep8 package from pypi.

How about a new version with a setup.py that errors out with a helpful message (cf. https://github.com/pytest-dev/pytest/blob/1f6988bdec07caa0c6488a488b390beeed32e529/extra/setup-py.test/setup.py)

Then you're still providing downloads for people yet to update (if they're pinned to old versions), while providing a good user experience for people updating existing dependencies AND for those in the habit of just doing pip install pep8

@IanLee1521

This comment has been minimized.

Show comment
Hide comment
@IanLee1521

IanLee1521 Feb 1, 2016

Member
Member

IanLee1521 commented Feb 1, 2016

@sigmavirus24

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Feb 1, 2016

Member

Yeah. I think we should not simply remove the pep8 package from PyPI. That will allow someone to re-register that name only further antagonizing Guido.

As for Flake8, we will likely want to keep a fallback import for pep8. And to simplify the changes to flake8, we will likely simply do something like:

try:
   import pycodestyle as pep8
except ImportError:
   import pep8

Sound fair?

Member

sigmavirus24 commented Feb 1, 2016

Yeah. I think we should not simply remove the pep8 package from PyPI. That will allow someone to re-register that name only further antagonizing Guido.

As for Flake8, we will likely want to keep a fallback import for pep8. And to simplify the changes to flake8, we will likely simply do something like:

try:
   import pycodestyle as pep8
except ImportError:
   import pep8

Sound fair?

@IanLee1521

This comment has been minimized.

Show comment
Hide comment
@IanLee1521

IanLee1521 Feb 2, 2016

Member

That's fair. Certainly the not dropping the pep8 package from PyPI.

As far as flake8, I feel like eventually we should update to just inport pycodestyle and use that, though I'd be fine waiting for a while / beyond the end of the timeline listed above.

Member

IanLee1521 commented Feb 2, 2016

That's fair. Certainly the not dropping the pep8 package from PyPI.

As far as flake8, I feel like eventually we should update to just inport pycodestyle and use that, though I'd be fine waiting for a while / beyond the end of the timeline listed above.

@sigmavirus24

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Feb 2, 2016

Member

Right. I'm speaking about the more immediate term. We currently have very loose lower bounds on pep8. I would be happy eventually releasing Flake8 2.6.0 or 2.7.0 with a dependency that looks like:

pycodestyle>=1.7.0,<1.8.0
Member

sigmavirus24 commented Feb 2, 2016

Right. I'm speaking about the more immediate term. We currently have very loose lower bounds on pep8. I would be happy eventually releasing Flake8 2.6.0 or 2.7.0 with a dependency that looks like:

pycodestyle>=1.7.0,<1.8.0
@sigmavirus24

This comment has been minimized.

Show comment
Hide comment
@sigmavirus24

sigmavirus24 Feb 19, 2016

Member

As an aside, pep8.org was just registered but not by anyone associated with this project. Any complaints about what content eventually lands there should be filed elsewhere.

Member

sigmavirus24 commented Feb 19, 2016

As an aside, pep8.org was just registered but not by anyone associated with this project. Any complaints about what content eventually lands there should be filed elsewhere.

@gvanrossum

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum Feb 19, 2016

gvanrossum commented Feb 19, 2016

nick-drozd added a commit to nick-drozd/sawtooth-core that referenced this issue Dec 14, 2017

Update `pep8` to `pycodestyle`
`pep8` the tool was renamed `pycodestyle` to avoid confusion with PEP
8 the document. See PyCQA/pycodestyle#466.

Signed-off-by: Nick Drozd <drozd@bitwise.io>

@naved001 naved001 referenced this issue Dec 19, 2017

Merged

Ci cleanup #927

hakrdinesh pushed a commit to hakrtech/openbsd-ports0-test that referenced this issue Jan 16, 2018

mitzkia pushed a commit to mitzkia/syslog-ng that referenced this issue Mar 18, 2018

Andras Mitzki
pep8: Switch to package pycodestyle from pep8
 * pep8 as package is discontinued, last release version is: 1.7.1
 * references:
   * PyCQA/pycodestyle#466
   * PyCQA/pycodestyle#481
   * https://github.com/PyCQA/pycodestyle/releases/tag/1.7.1

Signed-off-by: Andras Mitzki <andras.mitzki@balabit.com>

mgedmin pushed a commit to vaultit/qvarn that referenced this issue Mar 30, 2018

Update ./check tool to support changes to pep8 and pylint
- pep8 was renamed to pystyleguid

  PyCQA/pycodestyle#466

- pylint introduced new feature inconsistent-return-statements

geckon added a commit to geckon/hockepy that referenced this issue Apr 20, 2018

pep8 -> pycodestyle
Apparently pep8 tool was renamed.
PyCQA/pycodestyle#466

scw added a commit to scw/conda that referenced this issue Apr 26, 2018

The pep8 project has been renamed to pycodestyle
Per [this request from GvR](PyCQA/pycodestyle#466), the project has been renamed, and will emit deprecation warnings when linting conda if the [pep8] section remains.

@TurboTurtle TurboTurtle referenced this issue May 25, 2018

Closed

[watchdog] Add watchdog plugin #1305

4 of 4 tasks complete

ghost pushed a commit to spdk/spdk that referenced this issue Jun 22, 2018

pkgdep: support pycodestyle in check_format.sh
 - install py27-pycodestyle on Freebsd
 - conditionally use pycodestyle in check_format.sh
 - fix various E722 do not use bare except errors caught by pycodestyle
 - see: PyCQA/pycodestyle#466

Change-Id: I64ecf3f204a456134d891d1339f3aa1db281965a
Signed-off-by: John Meneghini <johnm@netapp.com>
Signed-off-by: Ed Rodriguez <ed.rodriguez@netapp.com>
Reviewed-on: https://review.gerrithub.io/416460
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment