new operators via backquoting
![](https://secure.gravatar.com/avatar/29dab9756bd78b47618ba30628d91d34.jpg?s=120&d=mm&r=g)
In Haskell, foo `baz` bar means (baz foo bar), which translates to baz(foo, bar) in Python. This allows Haskell programmers to use functions as infix operators. If I recall correctly, in Py3k, enclosing something in backticks will no longer cause it to be repr()-ed, leaving the backtick without a meaning in Python. Thus, I propose one of the following as the new use for the backtick (`): [Note: In both, the characters between the backticks must be a valid Python identifier.] (A) `baz` is treated as an operator, named "baz", just as / is "div". foo `baz` bar thus causes python to try to call foo.__baz__(bar), and failing that, bar.__rbaz__(foo), and if both those fail, raise TypeError. This is, if I understand correctly, how the builtin operators work. (B) `baz` is a special way to call a callable. foo `baz` bar is translated to baz(foo, bar) with the standard lookup rules for resolving "baz" Example use cases, stolen from Haskell: The Craft of Functional Programming: 2 `max` 5 => 5 7 `cons` tail => ConsCell(val=7, next=tail) matrix1 `crossproduct` matrix2 => cross-product of the matrices [1, 2, 3] `zip` ['a', 'b', 'c'] => [[1, 'a'], [2, 'c'], [3, 'c']] I believe that this would improve the readability of code, such as Numeric, without going off the deep end and offering programmable syntax. - Chris Rebert
![](https://secure.gravatar.com/avatar/e8600d16ba667cc8d7f00ddc9f254340.jpg?s=120&d=mm&r=g)
On 1/2/07, Chris Rebert <cvrebert@gmail.com> wrote:
In Haskell, foo `baz` bar means (baz foo bar), which translates to baz(foo, bar) in Python. This allows Haskell programmers to use functions as infix operators. If I recall correctly, in Py3k, enclosing something in backticks will no longer cause it to be repr()-ed, leaving the backtick without a meaning in Python.
Right. I removed that back in August at the Google sprint. Thus, I propose one of the following as the new use for the backtick (`):
[Note: In both, the characters between the backticks must be a valid Python identifier.]
(A) `baz` is treated as an operator, named "baz", just as / is "div". foo `baz` bar thus causes python to try to call foo.__baz__(bar), and failing that, bar.__rbaz__(foo), and if both those fail, raise TypeError. This is, if I understand correctly, how the builtin operators work.
(B) `baz` is a special way to call a callable. foo `baz` bar is
translated to baz(foo, bar) with the standard lookup rules for resolving "baz"
Example use cases, stolen from Haskell: The Craft of Functional Programming: 2 `max` 5 => 5 7 `cons` tail => ConsCell(val=7, next=tail) matrix1 `crossproduct` matrix2 => cross-product of the matrices [1, 2, 3] `zip` ['a', 'b', 'c'] => [[1, 'a'], [2, 'c'], [3, 'c']]
I believe that this would improve the readability of code, such as Numeric, without going off the deep end and offering programmable syntax.
Big -1 from me. I hate this feature from Haskell. It is a step towards programmable syntax and I think that's just a messy. And having it become a magic method that is called instead of just some function that takes two arguments really sends us down that road. -Brett
![](https://secure.gravatar.com/avatar/40190c456131372a6346401f6f35dd74.jpg?s=120&d=mm&r=g)
Chris Rebert <cvrebert@gmail.com> wrote:
In Haskell, foo `baz` bar means (baz foo bar), which translates to baz(foo, bar) in Python. This allows Haskell programmers to use functions as infix operators. If I recall correctly, in Py3k, enclosing something in backticks will no longer cause it to be repr()-ed, leaving the backtick without a meaning in Python.
[snip]
I believe that this would improve the readability of code, such as Numeric, without going off the deep end and offering programmable syntax.
Let us break down what you are more or less proposing... foo `baz` bar ... is translated into ... foo.__baz__(bar) bar.__rbaz__(foo) How is that any easier to read or understand than... baz(foo, bar) I don't believe it is easier to understand, and would claim that it is more difficult to understand, especially to users who have seen backticks being used for repr. The only people it could be more undestandable to is those who have used Haskell and have seen such operator use in the past. I dont know how many of those users there are, but I don't believe that the confusion would be worth it. If you want to call a method on an object, call the method. If you want to call a function that does automatic method invocation, that is fine too. But what you are offering is more or less arbitrary infix operators, which I can't see as being anything more than confusing to new and seasoned Python users alike. - Josiah
![](https://secure.gravatar.com/avatar/047f2332cde3730f1ed661eebb0c5686.jpg?s=120&d=mm&r=g)
On 1/2/07, Chris Rebert <cvrebert@gmail.com> wrote:
Thus, I propose one of the following as the new use for the backtick (`):
You're missing one of the main reasons for removing the backtick syntax in the first place: the character itself causes trouble by looking too much like a regular quote (depending on your font), is routinely mangled by typesetting software (as every Python book author can testify), and requires a four-finger chord on Swiss keyboards. No new uses for it will be accepted in Python 3000 no matter how good the idea. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
![](https://secure.gravatar.com/avatar/d91ce240d2445584e295b5406d12df70.jpg?s=120&d=mm&r=g)
Patch 1627052, assigned to Georg, adds backtick-reuse to PEP 3099 (rejected ideas). On 1/2/07, Guido van Rossum <guido@python.org> wrote:
On 1/2/07, Chris Rebert <cvrebert@gmail.com> wrote:
Thus, I propose one of the following as the new use for the backtick (`):
You're missing one of the main reasons for removing the backtick syntax in the first place: the character itself causes trouble by looking too much like a regular quote (depending on your font), is routinely mangled by typesetting software (as every Python book author can testify), and requires a four-finger chord on Swiss keyboards. No new uses for it will be accepted in Python 3000 no matter how good the idea.
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
participants (5)
-
Brett Cannon
-
Chris Rebert
-
Guido van Rossum
-
Jim Jewett
-
Josiah Carlson