Hello, On Sun, 14 Feb 2021 13:57:14 +1100 Steven D'Aprano <st...@pearwood.info> wrote:
> On Sun, Feb 14, 2021 at 12:47:30AM +0300, Paul Sokolovsky wrote: > > Hello, > > > > On Sat, 13 Feb 2021 16:25:24 -0500 > > Cade Brown <brown.c...@gmail.com> wrote: > > > > > In my humble opinion, arrows should be '->' instead of '=>'. It > > > always annoys me when languages use that symbol > > > > That's unlikely, as was discussed in this thread previously: > > > > a) JavaScript already uses "=>", and it doesn't make sense to be > > different just for the purpose of being different. That will only > > confuse people. > > It's not being different for the sake of being different. It's being > different because Javascript gets it wrong, and we should get it > right. > > *semi-wink* > > I wouldn't worry about being inconsistent with Javascript. We are > already inconsistent with Javascript in many, many, many ways. One > more is no big deal. There're 2 things about that from an experienced JavaScript-hater (but a pragmatic guy otherwise): 1. We aren't talking about all of JavaScript, but a recent features added to JS. 2. JS has real money being poured into it, and no longer designed on two-week vacations, when nobody looks. On the JS committees/proposal author lists are guys who have publications in serious programming language design matters and "grown up" languages, like proverbial Haskell. And they peer-review each other. So, with due understanding of the baseline https://en.wikipedia.org/wiki/Design_by_committee process, some recent features in JS are well-designed. > > Other popular and influential languages include: Please make sure this list ends up in the PEP, because we really, really should explicitly learn/compare Python with other languages (that's what actual users (or leavers) of the language do). [] > The question we should be asking is not so much how popular > Javascript is in absolute terms, but: > > - how many people coming to Python will be familiar with Javascript > as opposed to R, Julia, Maple, etc, or no language at all? I think that the answer is "very many". JS is both companion and competitor of Python. Companion, as very many people work on webapps (best practice in application-level (not sytem-level) development nowadays), and constantly switch between backend code in Python and frontend (in-browser) code in JS. Competitor in everything else (and making Python purposely different, which oftentimes translates to "worse" doesn't help here). > - given how many other things they will have to learn that is > different, is one comparatively rarely used feature more that much of > a burden? Again, we're talking about specific recent things (one now, but we'll be returning to that). And arrow functions are now very popular in JS, so someone hearing that Python added will immediately proceed to check, and on discovery that they look different, they'd conclude it was done on purpose, to confuse people. > > b) Python already uses "->" for function return *type*. And there's > > idea to generalize it to *function type* in general. E.g. a function > > "(a, b) => a + b" can have type "(int, int) -> int". > > This supports the idea of using "->" as the "return operator". In > annotations, it annotates the return *type* and in function bodies it > marks the return *value*. > > (a:int, b:int -> int) -> a*b > > Why have two different "return operators"? That can only lead to > confusion: Because even calling them "return operators" is "abuse of notation". And because things "returned" are wildly different. If first case, it's *value*, in second - it's *type*. These concepts are from different levels (types are at meta-level of values), and mean very different things. > > # Which of these are correct? > > (a, b) -> a*b This is a function type, where arbitrary types are accepted, and the function returns product type of them, i.e. a tuple. We unlikely would use that notation, rather literal tuple notation, so it would be: (a, b) -> (a, b) (But that's an idea how to "free up" tuple syntax in new-style annotations for something else. But I don't think it would fly). > (a, b) => a*b This is a function which returns things multiplied. > > def func(a, b) -> Spam: pass Normal familiar by now function annotation. > def func(a, b) => Spam: pass This is syntax error. > # and if arrow functions allow annotations, it's even worse! It's better, because it allows to distinguish value-level from type meta-level. > (a, b -> Type) -> a*b > (a, b => Type) -> a*b > (a, b -> Type) => a*b > (a, b => Type) => a*b In first approximation, these all are syntax errors. Practically, I guess for arrow functions, we'll need to allow single args without parens, e.g. "a => a + 1", then some of the above will make sense. (But as I mentioned, IMHO exception shouldn't apply for types, or we go to the land of functional-egghead confusion). > Let's keep it nice and simple. We already use "->" as the "return > operator", so let's use it for arrow functions too. > > > (All of this assumes that arrow functions are justified in the first > place.) +1 on that predicate. I myself not sure ;-). -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/7OBPHGUSBHGPJUEXCSZJLOZ4IHEMBNKV/ Code of Conduct: http://python.org/psf/codeofconduct/
