Hello, On Tue, 23 Feb 2021 13:24:10 +0000 Stestagg <stest...@gmail.com> wrote:
> I was quite feeling pretty positive about the 'stab' (thanks Steve > for this term!) operator idea, until I tried out some examples > locally, and it just feels a bit too out-of-place in python, for me > (100% subjective opinion here). > > Having used stabs and compact closure syntax in various languages: > swift, c++, javascript, I'd assumed that the joy of just writing > `c=>c.foo()` would translate well to python (sometimes lambda x: > x.foo() just seems too cumbersome to write out, even if this is a > lazy feeling, it's real). But, despite trying a few variants: ->, > =>, different whitespace, etc.. , they all still felt non-ideal. > > I think the main difference, for me, is that the other languages that > have adoped this syntax all rely much more on symbols (non-textual > tokens) for control flow and structure. (braces, ternary operators, > block syntax, etc..) so adding in another non-textual token that also > has structural meaning feels natural. You're already 'reading' the > symbols to understand what the language is doing, so there are no big > surprises when stabs come along. a) Python uses "non-textual tokens" for its operators too. b) And from all the above, the opposite conclusion springs - while in other languages "=>" would be lost in "character soup", in Python it would stand out well enough. > With python there are very few (any?) purely symbolic control flow > tokens, and so I naturally expect words to be present to indicate > what's going on. Suddenly there's a symbol that indicates a new > control structure, and it risks getting lost in the noise. "=>" is not a "control structure". It's a functional abstraction operator. It takes an expression and abstracts it to a function. While an expression is always evaluated "here and now", a function can be passed somewhere else. All that stuff is from functional programming paradigm. Thinking about it in terms of imperative programming ("control structures") may be not that helpful. [] -- 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/MM2SQCCSDQGXYGITRSYBISPYJ6NWS5ZI/ Code of Conduct: http://python.org/psf/codeofconduct/