`yield from` is a case where two keywords are used together to do something new, but they're both keywords independently of each other. If `a` can be variable or a keyword, we'd have to decide when `x is a y` is using `a` as a keyword and when it's using it as a variable. I don't think introducing that possibility is worth the effort. On Fri, May 1, 2020 at 2:13 PM Soni L. wrote:

On 2020-05-01 2:46 p.m., Steele Farnsworth wrote:

So this would make `a` a new keyword. I don't think that could be added into python 4 at the earliest because it would immediately break all code for which `a` is a variable name.

we could have keyphrases instead of keywords, tbh.

I can appreciate wanting to make simple operations easy to read, though I think this relies too much on understanding English and wouldn't be intuitive for people who aren't English speaking. I am native English speaking so I wouldn't know for sure, but I think accepting that "or" is the same as "||" is an easier jump to make than "x is a y" being a construct for indicating that x belongs to the y class.

If you need this English-style syntax, I believe `type(x) is y` is guaranteed to be True if x is exactly of the y type and not one of its super classes.

On Fri, May 1, 2020, 1:27 PM gbs--- via Python-ideas < python-ideas@python.org> wrote:

...

In cases where it makes sense to do explicit type checking (with ABCs or whatever), I really detest the look of the isinstance() function.

if isinstance(thing, Fruit) and not isinstance(thing, Apple):

Yucky.

What I really want to write is:

if thing is a Fruit and thing is not an Apple:

and after thinking about it on and off for a while I wonder if it might indeed be possible to teach the parser to handle that in a way that eliminates almost all possible ambiguity with the regular "is", including perhaps 100% of all existing standard library code and almost all user code?

Maybe this has been considered at some point in the past? The "is [not] a|an" proposal would at least be a strong contender for "hardest thing to search for on the internet" lol.

Thanks!

Gavin _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/YKLNQX... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PQSJ6P... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/JFSNV7... Code of Conduct: http://python.org/psf/codeofconduct/

I guess I need to remind folks about the reasons why infix operators are useful. It's not (primarily) about the lack of parentheses or the resemblance to English (oh horror). It's about the *associative property*. For example, it's a good idea to use a binary operator for string concatenation, since (s1 `concat` s2) `concat` s3 produces the same result as s1 `concat` (s2 `concat` s3), so it's reasonable to write it as s1 `concat` s2 `concat` s3 rather than as concat(s1, concat(s2, s3)) or concat(concat(s1, s2), s3). And sure, you could improve by having a varargs concat() function (which we do: "".join(s1, s2, s3)), but that only goes so far. But for a binary operation that doesn't have this useful (and rare!) property, spelling it as an infix operator doesn't buy you much. This would explain why `json.dump` makes a poor operator (and probably `round` too, though I honestly have no idea what it does). There's also the benefit of being able to combine *different* operators without having to use parentheses (like 2*x + 3*y), but that depends strongly on whether people can remember the priority of the various operators. (Python, following C, takes this a bit too far, and I have to look up the associativity of shift and bitwise operators.) For newly minted operators like `round` this benefit goes away -- presumably there's only one priority for that form, and it probably is lower than all other operators. Finally there's the benefit of matching common mathematical operators that are traditionally spelled as infix operators -- but most people know only a handful of these, and some of those aren't even associative (e.g. subtraction of vector cross product). Nevertheless, it's nice to be able to follow the mathematical tradition, as long as the typical programmer is familiar with that tradition. (Maybe there's a traditional "round" operator in some field of math commonly practiced by numpy users that I've never heard of?) --Guido On Fri, May 1, 2020 at 7:42 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

On May 1, 2020, at 15:35, Steven D'Aprano wrote:

...

but if it is all functions, then I think you have no choice but to either live with it or shift languages, because the syntax for functions is too deeply baked into Python to change now.

Actually, I’m pretty sure Python could add infix calling without complicating the grammar much, or breaking backward compatibility at all. I don’t think it *should*, but maybe others would disagree.

The most obvious way to do it is borrowing straight out of Haskell, so this:

x `spam` y

… compiles to exactly the same code as this:

spam(x, y)

That should be a very easy change to the grammar and no change at all to the later stages of compiling, so it’s about as simple as any new syntax could be. It doesn’t get in the way of anything else to the parser—and, more importantly, I don’t think it’s confusable as meaning something else to humans. (Of course it would be one extra thing to learn, like any syntax change.) Maybe something like $ instead of backticks is better for people with gritty monitors, but no point bikeshedding that (or the precedence) unless the basic idea is sound.

Anyway, it’s up to the user to decide which binary functions to infix and which to call normally, which sounds like a consenting-adults issue, but… does it _ever_ look Pythonic?

For this particular use case:

isa = isinstance

thing `isa` Fruit and not thing `isa` Apple

… honestly, the lack of any parens here makes it seem harder to read, even if it is a bit closer to English.

Here’s the best use cases I can come up with:

xs `cross` ys array([[0,1], [1,1]]) `matrix_power` n prices `round` 2

These are all things I have written infix in Haskell, and can’t in Python/NumPy, so you’d think I’d like the improvement… but if I can’t have real operators, I think I want dot-syntax methods with parens instead in Python:

prices.round(2)

And outside of NumPy, the examples seem to just get worse:

with open(path, 'w') as f: obj `json.dump` f

Of course maybe I’m just failing to imagine good examples. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/AQPPHK... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

On the subject of custom infix operators, there are at least two packages on PyPI that allow you to do this already: https://pypi.org/project/funcoperators/ https://pypi.org/project/infix/ On Sat, May 2, 2020 at 12:51 AM Steven D'Aprano wrote:

On Fri, May 01, 2020 at 07:41:57PM -0700, Andrew Barnert wrote:

...

The most obvious way to do it is borrowing straight out of Haskell, so this:

x `spam` y

… compiles to exactly the same code as this:

spam(x, y)

I really, really want to like that syntax, but I can't. The backticks get in the way. It's not that I don't like backticks. I do. But to the degree that "infix operators" are words:

x is y

rather than symbols, the backticks get in the way of it looking like a word:

x `is` y

Even though they're only grit on Tim's monitor *wink* nevertheless they stand out too much for my liking. (Maybe I wouldn't think so if my native language used more accents?)

So I'm afraid that I can't get past the idea that for a good looking, attractive syntax, you can either go whole-hog for Hypertalk-like natural(-ish) language syntax:

the number of words of line 1 of text

or functional notation:

len(words(lines(text)[0]))

but cramming them into the same language with backticks or dollar signs or some other sygil might be technically possibly but aesthetically ugly.

(Likewise I like Forth-like RPN code, but I don't think trying to cram it into Python would look good.)

[...]

...

For this particular use case:

isa = isinstance thing `isa` Fruit and not thing `isa` Apple

… honestly, the lack of any parens here makes it seem harder to read, even if it is a bit closer to English.

Do you think the same about this?

thing is None and not obj is None

If not, perhaps its just familiarity. Or the backticks getting in the way for you too :-)

-- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/YMYFH3... Code of Conduct: http://python.org/psf/codeofconduct/