spam `spam` eggs `baked` beans `spam` spam
I'm not sure if the backticks help. When you read that, I think you're reading the spacing not the ticks. You can already do something very similar by using built-in operators to "quote" the custom "operators", if you set the appropriate operator overloads.
spam *spam* eggs <baked> beans /spam/ spam
"<spam>" is potentially the most readable, for it's parenthesis like shape , but you can't overload the "and" it expands into. Mark Daoust On Thu, Mar 20, 2014 at 11:40 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 20, 2014, at 19:49, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Mar 21, 2014 at 12:28 PM, Brandon W Maister <bwmaister@gmail.com> wrote:
We could, hypothetically, create an "operators" dict (or dicts) alongside locals and globals. Then, if an unexpected token shows up in operator position (which is probably well-defined?) before a SyntaxError is raised the token is looked up in the operators dict.
The SyntaxError is raised at compilation time; locals and globals are at run time. The only way that would work is if you do something like this:
operators["b"] = lambda left, right: whatever import module_using_b
Or, alternatively, instead of a SyntaxError this would compile into a call to b, which would then give a NameError at runtime. And I suppose you could argue that's just taking dynamic typing one step further. But I seriously doubt anyone actually wants typos like "esle" to compile successfully...
Also, imagine what it would look like to chain these:
spam spam eggs baked beans spam spam
Maybe the parser can figure out that the spam, baked, and spam are operators and the spam, eggs, beans, and spam are operands, but what hope does any human have? Obviously that example is over the top, but try it with a tree constructor or the other examples from this thread and it's still painful.
The Haskell-style backticks solve all of these problems: the coder can't accidentally write an infix operator when he meant something else, the parser can distinguish infix operators from typos at compile time, and the reader can tell (unless he's stolen Tim's monitor grit) which things are operators and which are operands. (Of course you could deliberately confuse people with weird spacing, but Python doesn't have to make it impossible to write intentionally obfuscated code, it just has to avoid making it easy to write accidentally obfuscated code.) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/