On Mon, May 02, 2022 at 10:34:56AM -0600, Pablo Alcain wrote:
> For what it's worth,
> the choice of the `@` was because of two different reasons: first, because
> we were inspired by Ruby's syntax (later on learned that CoffeeScript and
> Crystal had already taken the approach we are proposing) and because the
> `@` token is already used as an infix for `__matmul__` (
> https://peps.python.org/pep-0465/). I believe it's the only usage that it
> has, so it probably won't be that confusing to give it this new semantic as
> well.
Did you forget decorators?
What other languages support this feature, and what syntax do they use?
Personally, I don't like the idea of introducing syntax which looks
legal in any function call at all, but is only semantically meaningful
in methods, and not all methods. Mostly only `__init__`.
How would this feature work with immutable classes where you want to
assign attributes to the instance in the `__new__` method?
I fear that this is too magical, too cryptic, for something that people
only use in a tiny fraction of method. 17% of `__init__` methods is
probably less than 1% of methods, which means that it is going to be a
rare and unusual piece of syntax.
Beginners and casual coders (students, scientists, sys admins, etc,
anyone who dabbles in Python without being immersed in the language) are
surely going to struggle to recognise where `instance.spam` gets
assigned, when there is no `self.spam = spam` anywhere in the class or
its superclasses. There is nothing about "@" that hints that it is an
assignment.
(Well, I suppose there is that assignment and at-sign both start with A.)
I realise that this will not satisfy those who want to minimize the
amount of keystrokes, but remembering that code is read perhaps 20-100
times more than it is written, perhaps we should consider a keyword:
def __init__(self, auto spam:int, eggs:str = ''):
# spam is automatically bound to self.spam
self.eggs = eggs.lower()
I dunno... I guess because of that "code is read more than it is
written" thing, I've never felt that this was a major problem needing
solving. Sure, every time I've written an __init__ with a bunch of
`self.spam = spam` bindings, I've felt a tiny pang of "There has to be a
better way!!!".
But **not once** when I have read that same method later on have I
regretted that those assignments are explicitly written out, or wished
that they were implicit and invisible.
Oh, by the way, if *all* of the parameters are to be bound:
def __init__(self, spam, eggs, cheese, aardvark):
vars(self).update(locals())
del self.self
Still less magical and more explicit than this auto-assignment proposal.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/C5I33AB2WLW77I77QAJFKZFBJOVNJ7RR/
Code of Conduct: http://python.org/psf/codeofconduct/
