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

"render_METHOD" method names violate PEP8 naming conventions #14

Closed
aellwein opened this issue Feb 13, 2015 · 4 comments
Closed

"render_METHOD" method names violate PEP8 naming conventions #14

aellwein opened this issue Feb 13, 2015 · 4 comments

Comments

@aellwein
Copy link
Contributor

"render_METHOD" method names violate PEP8 naming conventions.
may be it is better to use lowercase names, "get", "post", "put", "delete" etc. ?

@chrysn
Copy link
Owner

chrysn commented Feb 24, 2015

that naming stems from the original txthings, which seems to implement some more generic twisted interface. one could argue that the METHOD verbs of both HTTP and CoAP are always uppercased, which forms a prevailing style, but on the other hand we don't have to care much about compatibility yet (no api-stable release has been made, my concern is mainly about doing changes in a way that allows library users to easily migrate, eg. with search/replace).

i'm willing to do that change, but would also accept a pull request; thanks for reporting.

@aellwein
Copy link
Contributor Author

No problem. Here is the pull request.

chrysn pushed a commit that referenced this issue Feb 24, 2015
use render_$method callbacks (instead of render_$METHOD),
as the uppercase methods violate PEP8 conventions.

to follow the change, replace render_GET, render_POST, render_PUT and
render_DELETE occurrences with their lower-cased counterparts.
@chrysn
Copy link
Owner

chrysn commented Feb 24, 2015

cherry-picked and done, thank you.

i've changed two minor things:

  • commit messages should have a short single-line description followed by an empty line. (i don't strictly follow the 50 chars limit, but the general formatting has good reasons.
  • use str(x) instead of x.__str__(), avoiding python internals

@aellwein
Copy link
Contributor Author

Sounds reasonable, thank you!

@chrysn chrysn closed this as completed Feb 24, 2015
aellwein added a commit to aellwein/myLwM2M that referenced this issue Mar 31, 2015
aellwein added a commit to aellwein/myLwM2M that referenced this issue Mar 31, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants