"""This is not ok because from is a keyword. My proposal is to allow this:"""
class Test:
from: int = 10 # Throws a SyntaxError
to: int = 10
test = Test()
print(test.from)
This is especially useful for dataclasses from API responses that especially tend to use the from keyword in for example times:
import dataclasses
@dataclasses.dataclass
class TimeInterval:
id: int
from: datetime.datetime
to: datetime.datetime
I ran into a similar situation many years ago, when implementing an API to an external simulation program. The modeling language had an element with various properties, two of which were ‘print’ and ‘return’.
In our ORM, you could do stuff like this, but those last to sent us to use setattr instead of the obvious reserved word naming.
part = model.Part()
part.mass = 100
part.location = 10,0,20
debug = model.Debug()
debug.print = True # Oops. Works after 3.0, but in the 2.x days it failed.
debug.return = "OnError" # Still fails.
If I’m remembering right, your idea has come up before, now that the PEG parser would fairly easily allow all these traditionally reserved words to become soft keywords.
Thank you for the input. If I understand you correctly this idea has been brought up before and is also something you would have found useful in a project of yours a while back? And it is probably easier to implement now that CPython uses a PEG parser?
I tried searching for an active issue about this in the CPython GitHub repository, but couldn’t find any. I thought of creating an issue about this myself. The only thing holding me back is any potential obvious caveats that I have not thought of, so I decided to ask here first 
Yes to all three of your questions.
My recollection is that there was discussion on the python-ideas mail list back when PEG was formative, this being one of the arguments to go ahead with that project. I don’t recall if it predated the svn → git conversion, but may very well have (or been coincident with the switch), so I’m not surprised there’s nothing on github.
Could be something in here: PEG Parsing Series Overview. My series of blog posts about PEG… | by Guido van Rossum | Medium
The tradition is to append a _ to the name, e.g. from_ when something clashes with a keyword or built-in object name.
Yes, but that isn’t actually a good thing. We purposefully only use that for extreme situations where new syntax strongly makes sense to, like with match where there was a chance of clashing with pre-existing variable names. We still prefer to keep the grammar relatively simple.
Sure, but (in my cases at least) it’s likely you’ll be de/serializing the class into JSON or whatever, so now you have to configure your serialization library to do a rename. Which is generally possible, but frustrating when it’d be so much easier if the language let you use the right name from the start 
I’m assuming that’s because you don’t control one of the endpoints and thus the format isn’t under your control. In which case that sucks and I’m sorry that Python puts you through that if you’re converting this into object attributes (which I will assume the maintainer of cattrs is doing ), but that’s not going to convince the SC to make all keywords soft for the entire language (I was a part of that discussion around match and bringing in the PEG parser so I’m not speculating here).