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

PEP 8: naming | replace class_ example because cls is preferred #4253

Open
templiert opened this issue Feb 5, 2025 · 3 comments
Open

PEP 8: naming | replace class_ example because cls is preferred #4253

templiert opened this issue Feb 5, 2025 · 3 comments

Comments

@templiert
Copy link

Paragraph P1 recommends cls for any variable or argument known to be a class.
Paragraph P2 states that class_ is better than clss.

I think that P2 can mislead users to think that class_ is generally the preferred naming for a class (even if strictly speaking P1 and P2 are not contradictory and mean that cls > class_ > clss).

In P2, I suggest to replace

class_ is better than clss

by

async_ is better than asynk

or, to match the previous enumeration "is preferable to an abbreviation or corrupted spelling"

async_ is better than asnc or asynk

I chose async because of its high use frequency mentioned here.
Other replacement options:

continue_ is better than ctn or kontinue

break_ is better than brk or breac


P1

If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling. (However, notwithstanding this rule, ‘cls’ is the preferred spelling for any variable or argument which is known to be a class, especially the first argument to a class method.)

P2

If a function argument’s name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption. Thus class_ is better than clss.

@AA-Turner
Copy link
Member

I'm not sure there's strictly a need for a change here, indeed as you note the paragraphs are not contradictory, but illustrate different points with similar examples.

A

@willingc
Copy link
Contributor

willingc commented Feb 6, 2025

I agree with @AA-Turner. Thanks for pointing this out @templiert. I would recommend we close this issue and the issue itself can serve as future guidance if there is any confusion. ☀️

@skirpichev
Copy link
Member

I think we can just use a different example for P2. Maybe with type_ (e.g. vs typ).

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