On Wed, Dec 1, 2021 at 7:51 AM Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Dec 1, 2021 at 10:30 PM André Roberge <andre.robe...@gmail.com> > wrote: > > >> 2) Independently: Is the syntactic distinction between "=" and "=>" a > >> cognitive burden? > > > > Yes. > > I really think that using a keyword like defer, or from_calling_scope > ;-), would significantly reduce the cognitive burden. > > Also fair. I'm not a fan of keywords for this sort of thing, since it > implies that you could do this: > > def f(x=defer []): ... > > dflt = defer [] > def f(x=dflt): ... > > which is a completely different proposal (eg it would be evaluated > only when you "touch" that, rather than being guaranteed to be > evaluated before the first line of the function body). That's why I > want to adorn the equals sign and nothing else. > Shouldn't the PEP contain a rejected idea section where this could be mentioned? > > >> 4) If "no" to question 1, is there some other spelling or other small > >> change that WOULD mean you would use it? (Some examples in the PEP.) > > > > > > *Perhaps* if a keyword would be used instead of symbols, I might > reconsider. > > > > I find the emphasis of trying to cram too much information in single > lines of code to be really a burden. Many years ago, I argued very > unsuccessfully for using a 'where:' code block for annotations. (To this > day, I still believe it would make the code much more readable, at the cost > of a slight duplication.) Using what is at first glance a cryptic operator > like => for late binding is not helping readability, especially when type > annotations are thrown in the mix. > > > > Aside: at the same time, I can see how using => instead of lambda as a > potential win in readability, including for beginners. > > It's interesting how different people's views go on that sort of > thing. It depends a lot on how much people expect to use something. > Features you use a lot want to have short notations, features you > seldom use are allowed to have longer words. > > I rarely use lambda in my own code, and have never written a line of code anywhere that uses a '=>' operator. If Python had a 'function' keyword instead of 'lambda', I would prefer to keep the function keyword instead of adding => as a symbol. For me, it is not a question of terseness for commonly used features, but one of easing the learning curve. Starting from zero, I do believe that => would be easier to grasp than learning about lambda as a keyword and the syntactic rules to use with it. With function as a keyword, I believe that it is the other way around. No doubt many others will disagree! André Roberge > _______________________________________________ > 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/WTU355AA46KWI6QJNMC3HR52SEEXQS65/ > 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/AS7PEMRTLV4BR6NA6VP3UQALYTCMDWLG/ Code of Conduct: http://python.org/psf/codeofconduct/
