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?
- klass
- cls
- something else
- class_
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
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.
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.
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
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})
.
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.
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.