For a match statement, yes, and that’s because match is meant use an expression of existing names. A class statement on the other hand does not have the same problem because a class statement always defines a new name so you can’t be in a position having to rename a variable named class when you have to define a new class later.
Yes, just like any other new language syntax, even for something as subtle as multiple exceptions no longer needing parentheses for except, any code that uses a new language syntax is expected to work only for the Python version that introduces it and onwards. So this reason alone should not be what prevents a meaningful new syntax from being considered.
Yes, I don’t think existing APIs should be bothered to adopt class as a parameter. It should be recommended only for newly developed APIs.
But my argument for class as a soft keyword is simply that in many cases it makes generic wrapper APIs intuitively work without needing to special-case. For example, if I have a pandas dataframe df sourced from someone else with a column named class, currently writing df.class.unique() would produce a syntax error, but if class is made a soft keyword the convenient expression would just work as expected. And class is a rather common column name.
Indeed, if that was to be a negative example of outcomes of making class a soft keyword, it is effectively null : the new error message just points to where the problem actually is.
Looks like you overlooked their “I could not find a proper regex to search for cls” (which I guessed they said because they - and now you - found quite a few “clear screen” cases).
The spelling of a variable cls irks me a bit but not that much because yeah people including myself have already gotten used to translating cls into class in our minds when reading Python codes, although it adds a bit to the mental load of a newcomer.
Again I believe the main benefit of this proposal comes from wrapping around existing data sources outside of our own control, since class is a commonly used column name, e.g.
from enum import Enum
import sqlalchemy as sa
from sqlalchemy.orm import DeclarativeBase
class Vehicle(DeclarativeBase):
id = sa.Column(sa.Integer, primary_key=True)
model = sa.Column(sa.String)
class = sa.Column(sa.Enum(Enum('VehicleClass', ['Car', 'Truck', 'SUV'])))
PEP 8 specifically recommends against this, for whatever that’s worth:
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.
Ironically, however, just before that it says the opposite for the classmethod case:
Always use cls for the first argument to class methods.
It’s also not clear why this section specifically refers to argument names rather than just variables in general.
The role of first parameter in a method is special in the runtime even if the name self is not. It is reasonable to have a stylistic rule that says it should always be called self. Same goes for cls and class methods.
What should PEP 8 say about this apart from saying not to do it because it would be confusing:
Actually, I considered cls used as the first argument to classmethod as false positives for the point I was trying to make here. I (and somewhat by extension, python community) have internalized it to the point that I don’t view it as breaking the mental model. I was trying to highlight cases like this, where there is a direct parallel to the literal word 'class' with the domain being modeled:
from datetime import datetime
from typing import Literal
from pydantic import BaseModel, Field
class Ticket(BaseModel):
price: int
klass: Literal["first", "economy", "business"] = Field(alias="class")
departure_time: datetime
arrival_time: datetime
code: str
origin_airport: str
destination_airport: str
Here, just the word klass sticks out like a sore thumb. In that vein, cls would bring up lot of false positives. It doesn’t help cls is a very well established abbreviation of "clear screen". However, in the example I cited in my post, cls is being used exactly for the purpose I wanted to demonstrate. Which is why I think cls is being used for this purpose quite a lot, but it is hard to gauge with a regex. Whereas something like klass/class_ is being used solely because the author wanted to use class but they simply couldn’t.
EDIT: I should note, even the search results I presented have some false positives, especially kls, but it still has lot of hits in line with what I was trying to demonstrate.
It depends on the domain. It wasn’t clear what the cls command was for (poor naming), partly due to decades of not clearing anything on Windows.
I would recommend against using cls for anything other than a class object. In the examples above, simply choosing a longer name would suffice, for example, ticket_class or a synonym like category. The use of the word “class” in those examples is about categorization, not class definitions.
Whenever I saw klass or class_, my first thought was, “hmm, a class object, too much abstraction, but why not just cls?” However, it was simply a field.
What I am trying to say is that using “cls” as an abbreviation for “class” is acceptable as a last resort, but it still conflicts mentally with cls used in classmethod. Making class a soft keyword would create even more confusion.