On Fri, Oct 12, 2012 at 4:37 PM, Ram Rachum <ram.rachum@gmail.com> wrote:

On Fri, Oct 12, 2012 at 10:34 PM, Mike Graham <mikegraham@gmail.com> wrote:

...

On Fri, Oct 12, 2012 at 4:27 PM, Ram Rachum <ram.rachum@gmail.com> 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-. . 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

Python should not expect characters that are hard for most people to type.

No one will be forced to type it. If you can't type it, use *.

...

Python should not expect characters that are still hard to

display on many common platforms.

We allow people to have unicode variable names, if they wish, don't we? So why not allow them to use unicode operator, if they wish, as a completely optional thing?

1. Non-ASCII unicode identifiers are heavily discouraged in most contexts and are not present anywhere in the core language or stdlib for a reason. 2. Having duplicative features where neither is encouraged is a bad idea. "There should be one-- and preferably only one --obvious way to do it." This is doubly true when one of the ways makes it harder for people to read and edit code others' wrote. Mike

On Fri, Oct 12, 2012 at 4:37 PM, Ram Rachum <ram.rachum@gmail.com> wrote:

On Fri, Oct 12, 2012 at 10:34 PM, Mike Graham <mikegraham@gmail.com> wrote:

...

On Fri, Oct 12, 2012 at 4:27 PM, Ram Rachum <ram.rachum@gmail.com> 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-. . 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

Python should not expect characters that are hard for most people to type.

No one will be forced to type it. If you can't type it, use *.

...

Python should not expect characters that are still hard to

display on many common platforms.

We allow people to have unicode variable names, if they wish, don't we? So why not allow them to use unicode operator, if they wish, as a completely optional thing?

1. Non-ASCII unicode identifiers are heavily discouraged in most contexts and are not present anywhere in the core language or stdlib for a reason. 2. Having duplicative features where neither is encouraged is a bad idea. "There should be one-- and preferably only one --obvious way to do it." This is doubly true when one of the ways makes it harder for people to read and edit code others' wrote. Mike