Should Python allow reserved keywords as property names?

Yeah, it’s not a hard indicator, but it does help. Ultimately, the important thing is to figure out unambiguously whether it’s to be a keyword or an identifier.

The case for the current set of soft keywords is the opposite of the OP.

Soft keywords were introduced because making them hard (recognized by the tokenizer) would have broken too much existing code.

So are you proposing to make from soft?

Side note: the only problem I have with keywords is with class, and I use klass, not class_. I never use underscores at the end of a name, I find it unreadable and ugly. IMHO.

I never had problems with from, but probably instead of using from I’ll use origin, or start, or begin, or something else.

Out of interest, how many people here prefer klass, how many prefer class_, and how many prefer cls? I’m in the third camp, myself.

Can I give a vote?

  1. klass
  2. cls
  3. something else
  4. class_

:smiley:

These serve different roles:
cls is the preferred spelling for a class instance, in class methods for example
class_ (similar to from_), a way to name something that’s not a python class (like an HTML class)
klass (or frm) is an ugly form, hard to read and not recommended by PEP 8

1 Like

I was thinking about it, but I think this discussion made clear that even if the need to name things “from” is really common, making it a soft keywod is not as simple as I thought (I totally forgot about yield from and raise from too!), and probably a bad idea overall.

1 Like

If make keywords soft, how is the compiler expected to interpret expression “not and - 1”?

  • not and (-1)
    if not is a variable and and is an operator.

  • not (and - 1)
    if not is an operator and and is a variable.

This kind of stuff is why I only would argue for soft keywords that are not part of expressions, e.g. class, def, match/case are fine, but not and and aren’t. I thought from was fine because I forgot about yield from.

I agree that the different “class” spellings serve different purposes, but I have another usage to include in the list.

In code which handles Python classes which is not part of a class definition (classmethods, __init_subclass__, etc), I avoid cls because it helps make it visually distinct from a classmethod.

e.g. If an object defines a class decorator, I’ll avoid calling the method input cls to reduce confusion.

Between class_ and klass, I think both are ugly and I’ve used them both in the past. :person_shrugging:


If someone wants to make the case for from, specifically, becoming soft, I think that might fare best in a separate thread.

The discussion is clearest if it’s done one keyword at a time. And if making from soft flops, IMO that’s a sign that probably nothing else will succeed. The usage numbers shown above support the idea that from has the strongest case.

cls, pls

Would be nice to have a way to mark a word as a not-keyword:

class Data:
    id: int
    \for: str

msg = Data.from_json('{"id": 113, "for": "me"}')
print(f"a message for {msg.\for}")

or:

closed = False
\not = 32   # not = Number of Tracks
if not closed and \not >= 10 :
    print("enough tracks")

There is! Stick an underscore after it :slight_smile:

1 Like

I’ve seen this argument a couple of times now and while I don’t completely disagree with it, I also think it’s a little disingenuous, because it ignores that sometimes you actually want to be able to call an attribute exactly the keyword, so you don’t have to transform it back later on when e.g. rendering the object’s attributes as HTML attributes. class is a very common attribute in HTML, so having to indirectly pass it via a mapping or having to special-case class_ can get annoying.

I’m still not sure it’s a common enough case to warrant new syntax, just so you can use a handful of keywords as identifiers, but I also think it’s unfair to reject it on the basis that adding an underscore is equivalent, which it clearly is not, a much better equivalent is setattr(Foo, 'keyword', bar) or Foo(**{'keyword': bar}).

1 Like

I’m not disputing that, but I just think that any proposal for a way to mark something as a non-keyword is going to be duplicating what can already be done.

The trailing underscore is a convention only. We want to get rid of a translation between names used by external systems and mangled names used in the program if the original ones happen to be keywords. Please have a look at my post again.

Data.from_json(
    '{"id": 113, "for": "me"}')   # it's "for", NOT "for_"

Sorry for necroposting, but from as a soft keyword would be amazing for alternative constructors:

class Foo:
    @classmethod
    def from(self, bar: Bar):
        """Create a `Foo` from a `Bar`."""

I don’t think about imports when I read that, also because from isn’t just imports and mentioned many places in this thread.

And at the call site Foo.from(bar) reads natural, too.

1 Like

Unlike Rust (where this style works well) Python doesn’t have overloading on parameter types, so you’ll have a problem when you later realise that you also want to create Foo objects from Baz objects. You can’t do Foo.from(baz), so you need Foo.from_baz(baz). And at that point you realise you should have done that in the first place, and used from_bar for the original method.

So no, I don’t think this works well in Python.

6 Likes