On Mon, May 2, 2022 at 11:48 AM Steven D'Aprano <st...@pearwood.info> wrote:
> 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? > totally forgot decorators, my bad! > > What other languages support this feature, and what syntax do they use? > you mean languages other than those two? I haven't found any. In case you mean the syntax for those two, I know a tiny bit Crystal's. It leverages the fact that they use `@` for referring to `self`, as in Ruby. so you would be able to write something like this: ``` class Person def initialize(@name : String) end def greet print("Hello, ", @name) end end p = Person.new "Terry" p.greet ``` > > 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__`. Yes, it's a good point. Allowing functions in the wild to use this syntax would simplify the usage for monkeypatching... but how often would you want to monkeypatch an `__init__`? and how often would you want to use the auto-assign outside of the `__init__`? i believe that it's too little. so in that case, maybe we can make it legal only in all methods. I agree, if we forego monkeypatching, that semantically it wouldn't be meaningful in functions; but, in methods, I think that semantically it would make sense apart from the `__init__`; the thing is that probably it wouldn't be that useful. > > 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 -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/C5I33AB2WLW77I77QAJFKZFBJOVNJ7RR/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JOFVYZG5CSV4C4GVE3QCAKBAENAYROMO/ Code of Conduct: http://python.org/psf/codeofconduct/
