Skip to content
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

add support for pep257 #29

Closed
techdragon opened this issue Jun 30, 2014 · 6 comments
Closed

add support for pep257 #29

techdragon opened this issue Jun 30, 2014 · 6 comments

Comments

@techdragon
Copy link

https://pypi.python.org/pypi/pep257/0.3.2

@thedrow
Copy link

thedrow commented Sep 10, 2014

+1

@jayclassless
Copy link
Contributor

Looks like it'd be a good addition. I started integrating it here. The problem I'm running into, though, is that it's incredibly sensitive when it's trying to parse __all__. It fails on most all of my code, where I format it as:

__all__ = (
    'something',
    'something_else',
)

Until/Unless it gets better at parsing __all__, I'm hesitant to recommend merging this in.

@carlio
Copy link
Member

carlio commented Oct 2, 2014

@jayclassless I've recently been adding support for 'optional tools' (this commit and this commit). So far I have added vulture and pyroma, both of which are not useful 100% of the time.

It depends how broken pep257 is, but if it's not reliable, it could perhaps still be added as an optional tool?

@techdragon
Copy link
Author

From the look of it, it could be related to this bug ticket they have open here. PyCQA/pydocstyle#78

@jayclassless Are you testing against the pypi package, or the code in github? If its the package, it sounds like it may be worth trying the code from the master branch in Github.

@jayclassless
Copy link
Contributor

@techdragon I was using the latest release they've got on pypi. When I get a chance I'll try it against their master to see if it's something they've fixed. If it is, then maybe we can urge them to package up a release. If not, maybe I/we can take a shot at getting them a PR to fix it.

@carlio Yea, I saw that. I was wondering when the day would come when not every tool we added would automatically be dumped into the "default" list. :) I think in this case it'd depend on how much you want to stretch the meaning of "optional". Right now it basically means "working tools that don't apply to every type of Python project". IMO, to add pep257 at this point would stretch it to include the word "experimental".

@carlio
Copy link
Member

carlio commented Oct 3, 2014

I don't see it as a problem as long as the documentation clearly states that it is experimental or 'possibly broken'. Perhaps a new command line argument would be needed to print a short description of each tool and status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants