Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
Do you think that we can make Python support · in addition to *?
I can think of a couple of problems, but none of them seem like deal-breakers:
- Backward compatibility: Python already uses *, but I don't see a backward compatibility problem with supporting · additionally. Let people use whichever they want, like spaces and tabs. - Input methods: I personally use an IDE that could be easily set to automatically convert * to · where appropriate and to allow manual input of ·. People on Linux can type Alt-. . Anyone else can set up a script that'll let them type · using whichever keyboard combination they want. I admit this is pretty annoying, but since you can always use * if you want to, I figure that anyone who cares enough about using · instead of * (I bet that people in scientific computing would like that) would be willing to take the time to set it up.
What do you think?
Ram.
2012/10/12 Ram Rachum ram.rachum@gmail.com:
What do you think?
It's maybe time to implement http://python.org/dev/peps/pep-3117/
Victor
Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
Because it is too easy to confuse · with .
Because it is not solving a problem.
Because it would still take work, and then easily cause confusion.
<aside> In college we dropped the · and just wrote stuff like:
(x + z)(x - y)
but we can't do that in Python because they are function calls. </aside>
In short, I don't see it happening.
~Ethan~
On 10/12/12 10:31 PM, Victor Stinner wrote:
2012/10/12 Ram Rachum ram.rachum@gmail.com:
What do you think?
It's maybe time to implement http://python.org/dev/peps/pep-3117/
I'd use ? ?? to speed up a piece code, not for exceptions...
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 2012-10-12 22:37, Ethan Furman wrote:
Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
Why not use × ?
Because it is too easy to confuse · with .
Because it is too easy to confuse × with x
Because it is not solving a problem.
Ditto.
Because it would still take work, and then easily cause confusion.
Ditto.
<aside> In college we dropped the · and just wrote stuff like:
(x + z)(x - y)
but we can't do that in Python because they are function calls.
</aside>
In short, I don't see it happening.
Ditto.
On Fri, Oct 12, 2012 at 4:37 PM, Ethan Furman ethan@stoneleaf.us wrote:
Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
Because it is too easy to confuse · with .
Because it is not solving a problem.
Because it would still take work, and then easily cause confusion.
Because, unlike *, it's a valid character in identifiers. Which means allowing it either breaks backwards compatibility or makes for some very confusing usage conventions.
On 13/10/12 07:27, Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
25 or so years ago, I used to do some programming in Apple's Hypertalk language, which accepted ÷ in place of / for division. The use of two symbols for the same operation didn't cause any problem for users. But then Apple had the advantage that there was a single, system-wide, highly discoverable way of typing non-ASCII characters at the keyboard, and Apple users tended to pride themselves for using them.
I'm not entirely sure about MIDDLE DOT though: especially in small font sizes, it falls foul of the design principle:
"syntax should not look like a speck of dust on Tim's monitor"
(paraphrasing... can anyone locate the original quote?)
and may be too easily confused with FULL STOP. Another problem is that MIDDLE DOT is currently valid in identifiers, so that a·b would count as a single name. Fixing this would require some fairly heavy lifting (a period of deprecation and warnings for any identifier using MIDDLE DOT) before introducing it as an operator. So that's a lot of effort for very little gain.
If I were designing a language from scratch today, with full Unicode support from the beginning, I would support a rich set of operators possibly even including MIDDLE DOT and × MULTIPLICATION SIGN, and leave it up to the user to use them wisely or not at all. But I don't think it would be appropriate for Python to add them, at least not before Python 4: too much effort for too little gain. Maybe in another ten years people will be less resistant to Unicode operators.
[...]
·. People on Linux can type Alt-. .
For what it is worth, I'm using Linux and that does not work for me. I am yet to find a decent method of entering non-ASCII characters.
Well, I learned x as a multiplication symbol long before I learned either · or *, and in many fonts you can barely see the middle dot. Is there a good reason, we can't just write foo x bar instead of foo * bar? If that's confusing we could use × instead. No one would ever confuse × and x.
Or for that matter how about (~R∊R∘.×R)/R←1↓⍳R
Seriously: learning that * means multiplication is a very small thing. You also need to learn what /, // and % do, and the difference between 'and' and &, and between =, ==, != and /=.
--- Bruce
On Fri, Oct 12, 2012 at 7:41 PM, Steven D'Aprano steve@pearwood.infowrote:
On 13/10/12 07:27, Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
t 25 or so years ago, I used to do some programming in Apple's Hypertalk language, which accepted ÷ in place of / for division. The use of two symbols for the same operation didn't cause any problem for users. But then Apple had the advantage that there was a single, system-wide, highly discoverable way of typing non-ASCII characters at the keyboard, and Apple users tended to pride themselves for using them.
I'm not entirely sure about MIDDLE DOT though: especially in small font sizes, it falls foul of the design principle:
"syntax should not look like a speck of dust on Tim's monitor"
(paraphrasing... can anyone locate the original quote?)
and may be too easily confused with FULL STOP. Another problem is that MIDDLE DOT is currently valid in identifiers, so that a·b would count as a single name. Fixing this would require some fairly heavy lifting (a period of deprecation and warnings for any identifier using MIDDLE DOT) before introducing it as an operator. So that's a lot of effort for very little gain.
If I were designing a language from scratch today, with full Unicode support from the beginning, I would support a rich set of operators possibly even including MIDDLE DOT and × MULTIPLICATION SIGN, and leave it up to the user to use them wisely or not at all. But I don't think it would be appropriate for Python to add them, at least not before Python 4: too much effort for too little gain. Maybe in another ten years people will be less resistant to Unicode operators.
[...]
·. People on Linux can type Alt-. .
For what it is worth, I'm using Linux and that does not work for me. I am yet to find a decent method of entering non-ASCII characters.
-- Steven
______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideashttp://mail.python.org/mailman/listinfo/python-ideas
On 12Oct2012 13:27, Ram Rachum ram.rachum@gmail.com wrote: | Today a funny thought occurred to me. Ever since I've learned to program | when I was a child, I've taken for granted that when programming, the sign | used for multiplication is *. But now that I think about it, why? Now that | we have Unicode, why not use · ?
Because it looks astonishingly like ".". Reason enough to avoid it altogether, for any purpose, in a language that uses "." quite a like, as Python does.
A big -100 from me.
Besides, "*" works well and has a long history as multiplication in many languages. This isn't broken.
As a child, I was taught "x" (that's intened as a small cross diagonally oriented, not the letter I've used here) for multiplication. Let's support that too! It also looks like another character (specifically, a lot like the letter "x").
Seriously, I think this is a bad idea on a readability/usability basis, and an unnecessary idea from a functional point of view - it adds noting not already there and mucks with the "one obvious way to do it" notion into the bargain.
Cheers,
On Fri, Oct 12, 2012 at 10:41 PM, Steven D'Aprano steve@pearwood.info wrote:
If I were designing a language from scratch today, with full Unicode support from the beginning, I would support a rich set of operators possibly even including MIDDLE DOT and × MULTIPLICATION SIGN, and leave it up to the user to use them wisely or not at all. But I don't think it would be appropriate for Python to add them, at least not before Python 4: too much effort for too little gain. Maybe in another ten years people will be less resistant to Unicode operators.
Python has cleverly left the $ symbol unused.
We can use it as a quasiquote to embed executable TeX.
for x in xrange($b \cdot \sum_{i=1}^n \frac{x^n}{n!}$): ...
No need to wait for that new language, we can have a rich set of math operators today!
-- Devin
On Oct 13, 2012 6:45 AM, "Devin Jeanpierre" jeanpierreda@gmail.com wrote:
On Fri, Oct 12, 2012 at 10:41 PM, Steven D'Aprano steve@pearwood.info
wrote:
If I were designing a language from scratch today, with full Unicode
support
from the beginning, I would support a rich set of operators possibly
even
including MIDDLE DOT and × MULTIPLICATION SIGN, and leave it up to the
user
to use them wisely or not at all. But I don't think it would be
appropriate
for Python to add them, at least not before Python 4: too much effort
for
too little gain. Maybe in another ten years people will be less resistant to Unicode operators.
Python has cleverly left the $ symbol unused.
We can use it as a quasiquote to embed executable TeX.
for x in xrange($b \cdot \sum_{i=1}^n \frac{x^n}{n!}$): ...
I hope this was in jest because that line of TeX for general programming made my eyes bleed.
A PEP for defining operators sounds interesting for 4.0 indeed. Though it might be messy to allow a module to meddle with the python syntax.
Perhaps instead I would like it if all operators were objects with e.g. special __infix__ methods.
Yuval
On 13/10/12 19:05, Yuval Greenfield wrote:
A PEP for defining operators sounds interesting for 4.0 indeed. Though it might be messy to allow a module to meddle with the python syntax.
You mean more than classes already do? :)
Perhaps instead I would like it if all operators were objects with e.g. special __infix__ methods.
I believe that Haskell treats operators as if they were function objects, so you could do something like:
negative_values = map(-, values)
but I think that puts the emphasis on the wrong thing. If (and that's a big if) we did something like this, it should be a pair of methods __op__ and the right-hand version __rop__ which get called on the *operands*, not the operator/function object:
def __op__(self, other, symbol)
On 13.10.12 05:41, Steven D'Aprano wrote:
If I were designing a language from scratch today, with full Unicode support from the beginning, I would support a rich set of operators possibly even including MIDDLE DOT and × MULTIPLICATION SIGN, and leave it up to the user to use them wisely or not at all.
But they are a different operators.
(1, 2, 3)·(6, 5, 4) = 28 (1, 2, 3)×(6, 5, 4) = (-7, 14, -7)
On Sat, Oct 13, 2012 at 10:18 AM, Steven D'Aprano steve@pearwood.infowrote:
[..] but I think that puts the emphasis on the wrong thing. If (and that's a big if) we did something like this, it should be a pair of methods __op__ and the right-hand version __rop__ which get called on the *operands*, not the operator/function object:
def __op__(self, other, symbol)
I thought the operator should have a say in how it operates, e.g. the operater `dot` could call __dot__ in its operands.
class Vector: def _dot(self, other): return sum([i * j for i, j in zip(self, other)])
class dot(operator): def __infix__(self, left, right): return left._dot(left, right)
Vector([1,2,3]) dot Vector([3,4,5])
26
Making the declaration and import of operators more explicit than the `def __op__(self, other, symbol)` version. We could put [/, *, ., //, etc...] in __builtins__
Yuval
On Sat, Oct 13, 2012 at 7:18 PM, Steven D'Aprano steve@pearwood.info wrote:
On 13/10/12 19:05, Yuval Greenfield wrote:
A PEP for defining operators sounds interesting for 4.0 indeed. Though it might be messy to allow a module to meddle with the python syntax.
You mean more than classes already do? :)
Yes, more than classes already do. You could completely redefine Python into another language.
Here, I wrote a program. It uses the letter d as an infix operator that means "sum N random numbers up to M". You know the language, it's Python same as you work with all the time! Oh, but I don't use + for addition, I use $, and # is my "turn tuple into dictionary" operator, and I use parentheses as a sort of C-style ternary operator.
But it's still Python, so you should be able to read and understand the code, right?
I actually wrote up a language design spec to highlight what would happen if this sort of thing were possible. And the writing of that spec was what demonstrated to me how fundamentally BAD the idea was.
It could certainly be done. All you need to do is make abuttal of three objects into second_object.__infix__(first_object, third_object) and then handle the mess of prefix and postfix objects. I just don't recommend ever doing it.
ChrisA
On 2012-10-13, at 10:18 , Steven D'Aprano wrote:
Perhaps instead I would like it if all operators were objects with e.g. special __infix__ methods.
I believe that Haskell treats operators as if they were function objects
That is correct for binary operators. The unary minus is (currently) a keyword and sugar for the negate function[0].
So `map (-) values` is not going to negate all values, it's going to partially apply the binary `(-)` to all values.
but I think that puts the emphasis on the wrong thing.
I'm not sure I understand that, what does it put the emphasis on? Note that these operators — when generic — tend to live in typeclasses, so the actual implementation of the behavior of the operator for the set of its arguments is defined where and when the corresponding typeclass instance is created. This is essentially how Python's own operators (and some builtins e.g. ``divmod`` or ``pow``) work (except Haskell doesn't have a reflected operands fallback)
[0] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.htm...
On 2012-10-12, at 23:37 , Ethan Furman wrote:
In college we dropped the · and just wrote stuff like:
(x + z)(x - y)
but we can't do that in Python because they are function calls.
Numbers could be callable with __call__ aliasing to a multiplication…
On 13/10/2012 05:27, Cameron Simpson wrote:
As a child, I was taught "x" (that's intened as a small cross diagonally oriented, not the letter I've used here) for multiplication. Let's support that too! It also looks like another character (specifically, a lot like the letter "x").
Cheers,
Another problem with "x" is actually writing it out correctly on your coding sheets for the data preparation team. IIRC Hagar the Horrible had an issue with this as he couldn't get the lines to cross.
On Sat, 13 Oct 2012 19:18:12 +1100 Steven D'Aprano steve@pearwood.info wrote:
On 13/10/12 19:05, Yuval Greenfield wrote: I believe that Haskell treats operators as if they were function objects, so you could do something like:
For the record, Haskell allows operators to be used as functions by quoting them in ()'s (to provide the functionality of operator) and to turn functions into operators by quoting them in ``'s.
negative_values = map(-, values)
but I think that puts the emphasis on the wrong thing. If (and that's a big if) we did something like this, it should be a pair of methods __op__ and the right-hand version __rop__ which get called on the *operands*, not the operator/function object:
def __op__(self, other, symbol)
Yeah, but then your function has to dispatch for *all* operators. Depending on how we handle backwards compatibility with __add__ et. al.
I'd rather slice it the other way (leveraging $ being unsused):
def __$<op>__(self, other, right):
so it only has to dispatch on left/right invocation.
<op> must match a new grammer symbol "operator_symbol", with limits on it to for readability reasons: say at most three characters, all coming from an appropriate unicode class or classes (you want to catch the current operators and dollar sign).
Both of these leave both operator precedence and backwards compatibility to be dealt with.
<mike
On 13 October 2012 16:22, Mike Meyer mwm@mired.org wrote:
On Sat, 13 Oct 2012 19:18:12 +1100 Steven D'Aprano steve@pearwood.info wrote:
On 13/10/12 19:05, Yuval Greenfield wrote: I believe that Haskell treats operators as if they were function objects, so you could do something like:
For the record, Haskell allows operators to be used as functions by quoting them in ()'s (to provide the functionality of operator) and to turn functions into operators by quoting them in ``'s.
negative_values = map(-, values)
but I think that puts the emphasis on the wrong thing. If (and that's a
big
if) we did something like this, it should be a pair of methods __op__ and the right-hand version __rop__ which get called on the *operands*, not
the
operator/function object:
def __op__(self, other, symbol)
Yeah, but then your function has to dispatch for *all* operators. Depending on how we handle backwards compatibility with __add__ et. al.
I'd rather slice it the other way (leveraging $ being unsused):
def __$<op>__(self, other, right):
so it only has to dispatch on left/right invocation.
<op> must match a new grammer symbol "operator_symbol", with limits on it to for readability reasons: say at most three characters, all coming from an appropriate unicode class or classes (you want to catch the current operators and dollar sign).
Both of these leave both operator precedence and backwards compatibility to be dealt with.
If anyone is taking this as more than a bit of fun, *stop it*.
How'er, for all you wanting something a bit more concrete to play with, I've got something that simulates infix based off something I'd found on the netz sometime who's author I do not remember.
The code is one Codepad http://codepad.org/TnuehfQH for brevity, and it lets you do things like this:
(2 *dot* "__mul__" |mappedover| 10-to-25) >> tolist
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48]
Note that this is a contrived example equivalent to:
list(map((2).__mul__, range(10, 25)))
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48]
and mixing the styles you can get a quite nice:
map((2).__mul__, 10-to-25) >> tolist
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48]
which would actually look readable if it was considered mainstream.
Note that making an in-line function is as simple as:
@Inline
... def multiply(x, y): return x*y ...
3 ^multiply^ 3
9
and that you can use any surrounding operators (other than comparisons) to chose your operator priority or what reads well:
1 |div| 3 |div| 3
0.1111111111111111
1 |div| 3 *div* 3
1.0
and finally you also get "coercion" to functions á la Haskell:
2 |(div|3)
0.6666666666666666
(div|3)(2)
0.6666666666666666
but I wouldn't even hope of calling it stable code or low on WTFs (if the above wasn't enough):
(div|(div|3))(3) # Go on, guess why!
1.0
2 + (div|3) # 'Cause you can, yo
0.6666666666666666
These could both be "fixed" by making an infix require the same operator on both sides, which would make these both errors, but that wouldn't catch cases like (or*(div|3))(3) anyway.
So enjoy. Or not. Preferably not.
Den 13. okt. 2012 kl. 06:44 skrev Devin Jeanpierre jeanpierreda@gmail.com:
Python has cleverly left the $ symbol unused.
We can use it as a quasiquote to embed executable TeX.
for x in xrange($b \cdot \sum_{i=1}^n \frac{x^n}{n!}$): ...
No need to wait for that new language, we can have a rich set of math operators today!
LOL :D
But hey, this is valid Python :D :D
for x in texrange(r"$b \cdot \sum_{i=1}^n \frac{x^n}{n!}$"): pass
Sturla
On 13 October 2012 19:29, Sturla Molden sturla@molden.no wrote:
Den 13. okt. 2012 kl. 06:44 skrev Devin Jeanpierre <jeanpierreda@gmail.com
:
Python has cleverly left the $ symbol unused.
We can use it as a quasiquote to embed executable TeX.
for x in xrange($b \cdot \sum_{i=1}^n \frac{x^n}{n!}$): ...
No need to wait for that new language, we can have a rich set of math operators today!
LOL :D
But hey, this is valid Python :D :D
for x in texrange(r"$b \cdot \sum_{i=1}^n \frac{x^n}{n!}$"): pass
I am glad someone else shares the same progressive attitude. I, personally, wrap my whole code like so:
import texcode
texcode.texecute("""
\eq{y}{\range{1}{10}} \for{x}{y}{ \print{x} } """) # Alas, the joy has to end
Which has tremendously improved the quality of my output. Recently, rendering my code, too, has sped up to a remarkable 3 pages-per-minute!
Den 13. okt. 2012 kl. 21:14 skrev Joshua Landau joshua.landau.ws@gmail.com:
I am glad someone else shares the same progressive attitude. I, personally, wrap my whole code like so:
import texcode
texcode.texecute(""" \eq{y}{\range{1}{10}} \for{x}{y}{ \print{x} } """) # Alas, the joy has to end
Which has tremendously improved the quality of my output. Recently, rendering my code, too, has sped up to a remarkable 3 pages-per-minute!
Gee, I thought texecution was the Texas death penalty :-)
Sturla
On 10/12/2012 10:27 PM, Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
Do you think that we can make Python support · in addition to *?
I can think of a couple of problems, but none of them seem like deal-breakers:
- Backward compatibility: Python already uses *, but I don't see a backward compatibility problem
with supporting · additionally. Let people use whichever they want, like spaces and tabs.
- Input methods: I personally use an IDE that could be easily set to automatically convert * to ·
where appropriate and to allow manual input of ·. People on Linux can type Alt-. .
I use Linux (KDE4). When I press Alt-. in kwrite I simply get . in gvim I get ® and here in Thunderbird I get nothing. So I don't think this is very practical.
Anyone else can set up a script that'll let them type · using whichever keyboard combination they want. I admit this is pretty annoying, but since you can always use * if you want to, I figure that anyone who cares enough about using · instead of * (I bet that people in scientific computing would like that) would be willing to take the time to set it up.
What do you think?
Ram.
On 10/13/2012 06:20 AM, Bruce Leban wrote:
Well, I learned x as a multiplication symbol long before I learned either · or *, and in many fonts you can barely see the middle dot. Is there a good reason, we can't just write foo x bar instead of foo * bar? If that's confusing we could use × instead. No one would ever confuse × and x.
Or for that matter how about (~R∊R∘.×R)/R←1↓⍳R
On related news: The source code of the APL complier (interpreter?) was released. http://www.osnews.com/story/26464/The_APL_programming_language_source_code
I'm still baffled that this programming language was ever in production use.
Seriously: learning that * means multiplication is a very small thing. You also need to learn what /, // and % do, and the difference between 'and' and &, and between =, ==, != and /=.
--- Bruce
On Fri, Oct 12, 2012 at 7:41 PM, Steven D'Aprano <steve@pearwood.info mailto:steve@pearwood.info> wrote:
On 13/10/12 07:27, Ram Rachum wrote: Hi everybody, Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ? t 25 or so years ago, I used to do some programming in Apple's Hypertalk language, which accepted ÷ in place of / for division. The use of two symbols for the same operation didn't cause any problem for users. But then Apple had the advantage that there was a single, system-wide, highly discoverable way of typing non-ASCII characters at the keyboard, and Apple users tended to pride themselves for using them. I'm not entirely sure about MIDDLE DOT though: especially in small font sizes, it falls foul of the design principle: "syntax should not look like a speck of dust on Tim's monitor" (paraphrasing... can anyone locate the original quote?) and may be too easily confused with FULL STOP. Another problem is that MIDDLE DOT is currently valid in identifiers, so that a·b would count as a single name. Fixing this would require some fairly heavy lifting (a period of deprecation and warnings for any identifier using MIDDLE DOT) before introducing it as an operator. So that's a lot of effort for very little gain. If I were designing a language from scratch today, with full Unicode support from the beginning, I would support a rich set of operators possibly even including MIDDLE DOT and × MULTIPLICATION SIGN, and leave it up to the user to use them wisely or not at all. But I don't think it would be appropriate for Python to add them, at least not before Python 4: too much effort for too little gain. Maybe in another ten years people will be less resistant to Unicode operators. [...] ·. People on Linux can type Alt-. . For what it is worth, I'm using Linux and that does not work for me. I am yet to find a decent method of entering non-ASCII characters. -- Steven _________________________________________________ Python-ideas mailing list Python-ideas@python.org <mailto:Python-ideas@python.org> http://mail.python.org/__mailman/listinfo/python-ideas <http://mail.python.org/mailman/listinfo/python-ideas>
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 13 October 2012 21:20, Mathias Panzenböck grosser.meister.morti@gmx.netwrote:
On 10/12/2012 10:27 PM, Ram Rachum wrote:
Hi everybody,
Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ?
Do you think that we can make Python support · in addition to *?
I can think of a couple of problems, but none of them seem like deal-breakers:
- Backward compatibility: Python already uses *, but I don't see a
backward compatibility problem with supporting · additionally. Let people use whichever they want, like spaces and tabs.
- Input methods: I personally use an IDE that could be easily set to
automatically convert * to · where appropriate and to allow manual input of ·. People on Linux can type Alt-. .
I use Linux (KDE4). When I press Alt-. in kwrite I simply get . in gvim I get ® and here in Thunderbird I get nothing. So I don't think this is very practical.
Are y'all using your Alt Grill http://en.wikipedia.org/wiki/AltGr_key? Mînè łeŧs mê······
On 10/13/2012 10:45 PM, Joshua Landau wrote:
On 13 October 2012 21:20, Mathias Panzenböck <grosser.meister.morti@gmx.net mailto:grosser.meister.morti@gmx.net> wrote:
On 10/12/2012 10:27 PM, Ram Rachum wrote: Hi everybody, Today a funny thought occurred to me. Ever since I've learned to program when I was a child, I've taken for granted that when programming, the sign used for multiplication is *. But now that I think about it, why? Now that we have Unicode, why not use · ? Do you think that we can make Python support · in addition to *? I can think of a couple of problems, but none of them seem like deal-breakers: - Backward compatibility: Python already uses *, but I don't see a backward compatibility problem with supporting · additionally. Let people use whichever they want, like spaces and tabs. - Input methods: I personally use an IDE that could be easily set to automatically convert * to · where appropriate and to allow manual input of ·. People on Linux can type Alt-. . I use Linux (KDE4). When I press Alt-. in kwrite I simply get . in gvim I get ® and here in Thunderbird I get nothing. So I don't think this is very practical.Are y'all using your Alt Grill http://en.wikipedia.org/wiki/AltGr_key? Mînè łeŧs mê······
With Alt Gr I always get …
Ah, Alt Gr-, produces · (German keyboard here, of course.)
Mike Meyer wrote:
def __$<op>__(self, other, right):
<op> must match a new grammer symbol "operator_symbol", with limits on it to for readability reasons: say at most three characters, all coming from an appropriate unicode class or classes
If it's restricted it to single Unicode character, we could use its Unicode name as the method name:
def __CIRCLE_PLUS__(x, y): ...
On 2012-10-14 00:42, Greg Ewing wrote:
Mike Meyer wrote:
def __$<op>__(self, other, right):
<op> must match a new grammer symbol "operator_symbol", with limits on it to for readability reasons: say at most three characters, all coming from an appropriate unicode class or classes
If it's restricted it to single Unicode character, we could use its Unicode name as the method name:
def __CIRCLE_PLUS__(x, y): ...
If it's more than one codepoint, we could prefix with the length of the codepoint's name:
def __12CIRCLED_PLUS__(x, y): ...
On Sun, Oct 14, 2012 at 2:04 AM, MRAB python@mrabarnett.plus.com wrote:
If it's more than one codepoint, we could prefix with the length of the codepoint's name:
def __12CIRCLED_PLUS__(x, y): ...
That's a bit impractical, and why reinvent the wheel? I'd much rather:
def \u2295(x, y): ....
So readable I want to read it twice. And that's not legal python today so we don't break backwards compatibility!
Yuval
On 14/10/12 02:22, Mike Meyer wrote:
On Sat, 13 Oct 2012 19:18:12 +1100 Steven D'Apranosteve@pearwood.info wrote:
On 13/10/12 19:05, Yuval Greenfield wrote: I believe that Haskell treats operators as if they were function objects, so you could do something like:
For the record, Haskell allows operators to be used as functions by quoting them in ()'s (to provide the functionality of operator) and to turn functions into operators by quoting them in ``'s.
negative_values = map(-, values)
but I think that puts the emphasis on the wrong thing. If (and that's a big if) we did something like this, it should be a pair of methods __op__ and the right-hand version __rop__ which get called on the *operands*, not the operator/function object:
def __op__(self, other, symbol)
Yeah, but then your function has to dispatch for *all* operators. Depending on how we handle backwards compatibility with __add__ et. al.
It looks like I didn't make myself clear. I didn't think it was necessary to go into too much detail for an off-the-cuff comment about an idea that can't go anywhere for at least another five years. I should have known better :)
What I meant was that standard Python operators like +, -, &, etc. would continue to dispatch at the compiler level to dunder methods __add__, __sub__, __and__ etc. But there could be a way to add new operators, in which case Python could call a dedicated dunder method __op__ with two arguments, the "other" operand and the operator itself. Your class needs to define the __op__ method, but it only needs to dispatch on operators it cares about.
I have no idea how this would work out in practice, given that presumably Python would still want to raise SyntaxError on illegal/unknown operators at compile time.
As I said, this is Python 4 territory. Let's sleep on it for four or six years, hey? :)
On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield ubershmekel@gmail.com wrote:
On Sun, Oct 14, 2012 at 2:04 AM, MRAB python@mrabarnett.plus.com wrote:
If it's more than one codepoint, we could prefix with the length of the codepoint's name:
def __12CIRCLED_PLUS__(x, y): ...
That's a bit impractical, and why reinvent the wheel? I'd much rather:
def \u2295(x, y): ....
So readable I want to read it twice. And that's not legal python today so we don't break backwards compatibility!
Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking:
def __\u2295__(self, other):
Now *that's* pretty!
<mike
On 14 October 2012 20:57, Mike Meyer mwm@mired.org wrote:
On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield ubershmekel@gmail.com wrote:
On Sun, Oct 14, 2012 at 2:04 AM, MRAB python@mrabarnett.plus.com
wrote:
If it's more than one codepoint, we could prefix with the length of the codepoint's name:
def __12CIRCLED_PLUS__(x, y): ...
That's a bit impractical, and why reinvent the wheel? I'd much rather:
def \u2295(x, y): ....
So readable I want to read it twice. And that's not legal python today so we don't break backwards compatibility!
Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking:
def __\u2295__(self, other):
Now *that's* pretty!
<mike
I much preferred your first choice: def __$⊕__(self, other):
But to keep the "$" unused we can write: def __op_⊕__(self, other): (new methods will take precedence over the older __add__ and so forth)
What we can do then is use the "\u" syntax to let people without unicode editors have accessibility: def __op_\u2295__(self, other): ...later in the code... new = first \u2295 second
Which adds consistency whereas before we could only use that in specific circumstances (inside strings), reducing cognitive burden.
On 2012-10-14 22:06, Joshua Landau wrote:
On 14 October 2012 20:57, Mike Meyer <mwm@mired.org mailto:mwm@mired.org> wrote:
On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield <ubershmekel@gmail.com <mailto:ubershmekel@gmail.com>> wrote: > On Sun, Oct 14, 2012 at 2:04 AM, MRAB <python@mrabarnett.plus.com <mailto:python@mrabarnett.plus.com>> wrote: > > > If it's more than one codepoint, we could prefix with the length of the > > codepoint's name: > > > > def __12CIRCLED_PLUS__(x, y): > > ... > > > > > That's a bit impractical, and why reinvent the wheel? I'd much rather: > > def \u2295(x, y): > .... > > So readable I want to read it twice. And that's not legal python today so > we don't break backwards compatibility! Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking: def __\u2295__(self, other): Now *that's* pretty! <mikeI much preferred your first choice: def __$⊕__(self, other):
But to keep the "$" unused we can write: def __op_⊕__(self, other): (new methods will take precedence over the older __add__ and so forth)
What we can do then is use the "\u" syntax to let people without unicode editors have accessibility: def __op_\u2295__(self, other): ...later in the code... new = first \u2295 second
Which adds consistency whereas before we could only use that in specific circumstances (inside strings), reducing cognitive burden.
I don't think we should change what happens inside a string literal.
Consider what would happen if you wanted to write "\u0190". It would convert that into "\Ɛ".
IIRC, Java can suffer from that kind of problem because \uXXXX is treated as that codepoint wherever it occurs.
On 14 October 2012 23:08, MRAB python@mrabarnett.plus.com wrote:
On 2012-10-14 22:06, Joshua Landau wrote:
On 14 October 2012 20:57, Mike Meyer <mwm@mired.org mailto:mwm@mired.org> wrote:
On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield <ubershmekel@gmail.com <mailto:ubershmekel@gmail.com>**> wrote: > On Sun, Oct 14, 2012 at 2:04 AM, MRAB <python@mrabarnett.plus.com <mailto:python@mrabarnett.**plus.com <python@mrabarnett.plus.com>>>wrote: > > > If it's more than one codepoint, we could prefix with the length of the > > codepoint's name: > > > > def __12CIRCLED_PLUS__(x, y): > > ... > > > > > That's a bit impractical, and why reinvent the wheel? I'd much rather: > > def \u2295(x, y): > .... > > So readable I want to read it twice. And that's not legal python today so > we don't break backwards compatibility!
Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking: def __\u2295__(self, other): Now *that's* pretty! <mikeI much preferred your first choice: def __$⊕__(self, other):
But to keep the "$" unused we can write: def __op_⊕__(self, other): (new methods will take precedence over the older __add__ and so forth)
What we can do then is use the "\u" syntax to let people without unicode editors have accessibility: def __op_\u2295__(self, other): ...later in the code... new = first \u2295 second
Which adds consistency whereas before we could only use that in specific circumstances (inside strings), reducing cognitive burden.
I don't think we should change what happens inside a string literal.
Consider what would happen if you wanted to write "\u0190". It would convert that into "\Ɛ".
IIRC, Java can suffer from that kind of problem because \uXXXX is treated as that codepoint wherever it occurs.
No, no. "\" would have priority, still. "\uXXXX" is invalid outside of a string, anyway, so we're allowed to say that.
On 2012-10-14 23:42, Joshua Landau wrote:
On 14 October 2012 23:08, MRAB <python@mrabarnett.plus.com mailto:python@mrabarnett.plus.com> wrote:
On 2012-10-14 22:06, Joshua Landau wrote: On 14 October 2012 20:57, Mike Meyer <mwm@mired.org <mailto:mwm@mired.org> <mailto:mwm@mired.org <mailto:mwm@mired.org>>> wrote: On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield <ubershmekel@gmail.com <mailto:ubershmekel@gmail.com> <mailto:ubershmekel@gmail.com <mailto:ubershmekel@gmail.com>>__> wrote: > On Sun, Oct 14, 2012 at 2:04 AM, MRAB <python@mrabarnett.plus.com <mailto:python@mrabarnett.plus.com> <mailto:python@mrabarnett.__plus.com <mailto:python@mrabarnett.plus.com>>> wrote: > > > If it's more than one codepoint, we could prefix with the length of the > > codepoint's name: > > > > def __12CIRCLED_PLUS__(x, y): > > ... > > > > > That's a bit impractical, and why reinvent the wheel? I'd much rather: > > def \u2295(x, y): > .... > > So readable I want to read it twice. And that's not legal python today so > we don't break backwards compatibility! Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking: def __\u2295__(self, other): Now *that's* pretty! <mike I much preferred your first choice: def __$⊕__(self, other): But to keep the "$" unused we can write: def __op_⊕__(self, other): (new methods will take precedence over the older __add__ and so forth) What we can do then is use the "\u" syntax to let people without unicode editors have accessibility: def __op_\u2295__(self, other): ...later in the code... new = first \u2295 second Which adds consistency whereas before we could only use that in specific circumstances (inside strings), reducing cognitive burden. I don't think we should change what happens inside a string literal. Consider what would happen if you wanted to write "\\u0190". It would convert that into "\Ɛ". IIRC, Java can suffer from that kind of problem because \uXXXX is treated as that codepoint wherever it occurs.No, no. "\" would have priority, still. "\uXXXX" is invalid outside of a string, anyway, so we're allowed to say that.
OK, but what about raw string literals? Currently, "\u0190" == r"\u0190", but "\u0190" != r"Ɛ".
On 15 October 2012 00:46, MRAB python@mrabarnett.plus.com wrote:
OK, but what about raw string literals? Currently, "\u0190" == r"\u0190", but "\u0190" != r"Ɛ".
The “r"” prefix escapes all escapes, so will escape this escape too. Hence, this behaviour is un...escaped ;).
On 2012-10-15 01:12, Joshua Landau wrote:
On 15 October 2012 00:46, MRAB <python@mrabarnett.plus.com mailto:python@mrabarnett.plus.com> wrote:
OK, but what about raw string literals? Currently, "\\u0190" == r"\u0190", but "\\u0190" != r"Ɛ".The “r"” prefix escapes all escapes, so will escape this escape too. Hence, this behaviour is un...escaped ;).
If "\u0190" becomes "Ɛ", what happens to "\u000A"? Currently it's legal. :-)
On 15 October 2012 01:35, MRAB python@mrabarnett.plus.com wrote:
On 2012-10-15 01:12, Joshua Landau wrote:
On 15 October 2012 00:46, MRAB <python@mrabarnett.plus.com <mailto:python@mrabarnett.**plus.com python@mrabarnett.plus.com>> wrote:
OK, but what about raw string literals? Currently, "\\u0190" == r"\u0190", but "\\u0190" != r"Ɛ".The “r"” prefix escapes all escapes, so will escape this escape too. Hence, this behaviour is un...escaped ;).
If "\u0190" becomes "Ɛ", what happens to "\u000A"? Currently it's
legal. :-)
The python interpreter could distinguish between its morphed Unicode escapes and the originals - the escapes would never match against already-syntactically-relevant constructs*. Hence "a \u0069s b" is equivalent to "a i\u0073 b" but *not* "a is b": the first two are defined by __op_is__ and the last is just the "is" keyword.
Hence, \u000A would just act like a character, and be definable as an operator, and have little to do with the newline character.
Nice try, but the proposal stands firm.
* Except, of course, the old operators which will be phased into the new mechanism.
On Sun, Oct 14, 2012 at 3:57 PM, Mike Meyer mwm@mired.org wrote:
On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield ubershmekel@gmail.com wrote:
On Sun, Oct 14, 2012 at 2:04 AM, MRAB python@mrabarnett.plus.com wrote:
If it's more than one codepoint, we could prefix with the length of the codepoint's name:
def __12CIRCLED_PLUS__(x, y): ...
That's a bit impractical, and why reinvent the wheel? I'd much rather:
def \u2295(x, y): ....
So readable I want to read it twice. And that's not legal python today so we don't break backwards compatibility!
Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking:
def __\u2295__(self, other):
Now *that's* pretty!
<mike
IMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn None
Can we get this fix applied in Python 2.2 and up?
Mike
On Mon, Oct 15, 2012 at 03:12:15PM -0400, Mike Graham mikegraham@gmail.com wrote:
IMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn None
SyntaxError: a semicolon required after 'except ValueError'.
Oleg.
On Mon, Oct 15, 2012 at 3:12 PM, Mike Graham mikegraham@gmail.com wrote:
def __\u2295__(self, other):
Now *that's* pretty!
<mikeIMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn NoneCan we get this fix applied in Python 2.2 and up?
Yeah, this is how Java works, and it's one of the best features of the language, because any valid program can be expressed using ASCII only.
Of course, it means that there are going to be some edge cases. Like, now:
print "\n"
will be an invalid program, since the newline escape will be translated before the source is tokenized. But who does that? It's just a small price to pay for the big wins of having any program expressed in simple ASCII.
Mike _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 15 October 2012 16:12, Mike Graham mikegraham@gmail.com wrote:
On Sun, Oct 14, 2012 at 3:57 PM, Mike Meyer mwm@mired.org wrote:
On Sun, 14 Oct 2012 07:40:57 +0200 Yuval Greenfield ubershmekel@gmail.com wrote:
On Sun, Oct 14, 2012 at 2:04 AM, MRAB python@mrabarnett.plus.com wrote:
If it's more than one codepoint, we could prefix with the length of the codepoint's name:
def __12CIRCLED_PLUS__(x, y): ...
That's a bit impractical, and why reinvent the wheel? I'd much rather:
def \u2295(x, y): ....
So readable I want to read it twice. And that's not legal python today so we don't break backwards compatibility!
Yes, but we're defining an operator for instances of the class, so it needs the 'special' method marking:
def __\u2295__(self, other):
Now *that's* pretty!
<mikeIMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn NoneCan we get this fix applied in Python 2.2 and up?
" The time machine strikes again!" What you want is _valid_ in Python, likely since 2.2 - You will need at least two lines in the file: # coding:unicode_escape\n def a():\n\tprint "Helo World"\n\na()
Mike _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 2012-10-15 20:37, Jasper St. Pierre wrote:
On Mon, Oct 15, 2012 at 3:12 PM, Mike Graham mikegraham@gmail.com wrote:
def __\u2295__(self, other):
Now *that's* pretty!
<mikeIMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn NoneCan we get this fix applied in Python 2.2 and up?
Yeah, this is how Java works, and it's one of the best features of the language, because any valid program can be expressed using ASCII only.
Of course, it means that there are going to be some edge cases. Like, now:
print "\n"will be an invalid program, since the newline escape will be translated before the source is tokenized. But who does that? It's just a small price to pay for the big wins of having any program expressed in simple ASCII.
Simple:
print "\n"
On Mon, Oct 15, 2012 at 3:23 PM, Oleg Broytman phd@phdru.name wrote:
On Mon, Oct 15, 2012 at 03:12:15PM -0400, Mike Graham mikegraham@gmail.com wrote:
IMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn NoneSyntaxError: a semicolon required after 'except ValueError'.
Oleg.
Obviously we'd make those pesky semicolons optional in the process.
Mike
Deliberately not naming names, 'cos this isn't intended as a personal attack on anyone...
Some people suggested as syntax:
def __12CIRCLED_PLUS__(x, y): ...
def \u2295(x, y): ....
def __\u2295__(self, other):
IMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn NoneCan we get this fix applied in Python 2.2 and up?
As much as I've been wetting yourselves from all the hilarity, I'm afraid that I have to ask you all to stop. Competing to see who can come up with the worst possible joke syntax gets *real old* fast.
Sorry to be a wet blanket spoiling the fun, but this list does have a serious purpose, and it seems to me that sarcastically[1] inventing deliberately awful syntax is off-topic. Or at least off-putting.
Now I enjoy reading the occasional piece of obfuscated code or syntax as much as the next guy, but there are limits, and I think this thread passed them about a dozen posts back.
Believe it or not, there are good, reasonable reasons for wanting more operators, and at least one serious PEP driven by real-world needs:
http://www.python.org/dev/peps/pep-0225/
So can we please drop this thread unless you have a serious suggestion that doesn't need to wait until Python 4?
[1] By all the gods, PLEASE don't tell me these proposals are meant seriously!
Mike Graham writes:
IMO it's essential that we add source code escapes. Imagine the one-liners this will allow!
def f(xs):\n\ttry:\n\t\treturn x.pop()\n\texcept ValueError\n\t\treturn NoneCan we get this fix applied in Python 2.2 and up?
Why not go all the way back to v1.5.2? All it takes is a version bump to v1j.5.2.
On 10/12/12, Ethan Furman ethan@stoneleaf.us wrote:
<aside> In college we dropped the · and just wrote stuff like:
(x + z)(x - y)
but we can't do that in Python because they are function calls.
</aside>
I think your mailer must have stripped out unicode character 0x2062, INVISIBLE TIMES.
Some spelling mistakes are harder to see than others...
-jJ
-
Bruce Leban -
Cameron Simpson -
Chris Angelico -
Devin Jeanpierre -
Ethan Furman -
Greg Ewing -
Jasper St. Pierre -
Jim Jewett -
Joao S. O. Bueno -
Joshua Landau -
Mark Lawrence -
Masklinn -
Mathias Panzenböck -
Mike Graham -
Mike Meyer -
MRAB -
Oleg Broytman -
Ram Rachum -
Serhiy Storchaka -
Stephen J. Turnbull -
Steven D'Aprano -
Sturla Molden -
Tarek Ziadé -
Victor Stinner -
Yuval Greenfield