Is there a good reason to use * for multiplication?

[Ram Rachum]

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.

[Ram Rachum]

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

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?

 

I think you'll find strong opposition to adding any non-ASCII
characters or characters that don't occur on almost all keyboards as
part of the language.

Mike

[Ethan Furman]

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~

[Ram Rachum]

On Fri, Oct 12, 2012 at 10:40 PM, Blake Hyde <syr...@gmail.com> wrote:

Is anything gained from this addition?

To give a practical answer, I could say that for newbies it's one small confusion that could removed from the language. You and I have been programming for a long time so we take it for granted that * means multiplication, but for any other person that's just another weird idiosyncrasy that further alienates programming.

Also, I think that using * for multiplication is ugly.

 

> _______________________________________________
> Python-ideas mailing list
> Python...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>

[Mike Graham]

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 Graham]

On Fri, Oct 12, 2012 at 4:45 PM, Ram Rachum <ram.r...@gmail.com> wrote:
> On Fri, Oct 12, 2012 at 10:40 PM, Blake Hyde <syr...@gmail.com> wrote:
>>
>> Is anything gained from this addition?
>
>
> To give a practical answer, I could say that for newbies it's one small
> confusion that could removed from the language. You and I have been
> programming for a long time so we take it for granted that * means
> multiplication, but for any other person that's just another weird
> idiosyncrasy that further alienates programming.
>
> Also, I think that using * for multiplication is ugly.

You're emphatically not getting rid of *, though, which means 1)
you're only making it harder for new people to learn and deal with,
and b) you're at best not eliminating any perceived ugliness, in
reality probably compounding it.

[Victor Stinner]

2012/10/12 Ram Rachum <ram.r...@gmail.com>:
> What do you think?

It's maybe time to implement
http://python.org/dev/peps/pep-3117/

Victor

[Ethan Furman]

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~

[Tarek Ziadé]

On 10/12/12 10:31 PM, Victor Stinner wrote:

2012/10/12 Ram Rachum <ram.r...@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...

[MRAB]

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.

[Mike Meyer]

On Fri, Oct 12, 2012 at 4:37 PM, Ethan Furman <et...@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.

[Steven D'Aprano]

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.

--
Steven

[Bruce Leban]

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 <st...@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

[Devin Jeanpierre]

On Fri, Oct 12, 2012 at 10:41 PM, Steven D'Aprano <st...@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

[Greg Ewing]

Ram Rachum wrote:
> I could say that for newbies it's one small
> confusion that could removed from the language. You and I have been
> programming for a long time so we take it for granted that * means
> multiplication, but for any other person that's just another
> weird idiosyncrasy that further alienates programming.

Do you have any evidence that a substantial number of
beginners are confused by * for multiplication, or that
they have trouble remembering what it means once they've
been told?

If you do, is there further evidence that they would
find a dot to be any clearer?

The use of a raised dot to indicate multiplication of
numbers is actually quite rare even in mathematics, and I
would not expect anyone without a mathematical background
to even be aware of it.

In primary school we're taught that 'x' means multiplication.
Later when we come to algebra, we're taught not to use
any symbol at all, just write things next to each other.
A dot is only used in rare cases where there would
otherwise be ambiguity -- and even then it's often
preferred to parenthesise things instead.

And don't forget there's great potential for confusion
with the decimal point.

--
Greg

[Yuval Greenfield]

On Oct 13, 2012 6:45 AM, "Devin Jeanpierre" <jeanpi...@gmail.com> wrote:
>
> On Fri, Oct 12, 2012 at 10:41 PM, Steven D'Aprano <st...@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

[Steven D'Aprano]

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)



--
Steven

[Serhiy Storchaka]

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)

[Yuval Greenfield]

On Sat, Oct 13, 2012 at 10:18 AM, Steven D'Aprano <st...@pearwood.info> wrote:

[..]

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

[Chris Angelico]

On Sat, Oct 13, 2012 at 7:18 PM, Steven D'Aprano <st...@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.

http://rosuav.com/1/?id=683

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

[Cameron Simpson]

On 12Oct2012 13:27, Ram Rachum <ram.r...@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,
--
Cameron Simpson <c...@zip.com.au>

Climber: "I don't know, I can't see the next bolt."
Belayer: "Remember X, when in doubt, run it out."
This should be read with a good Birmingham accent, something like "Remember
'oids, win in dowt, roon it owt"

[Masklinn]

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.html#v:negate

[Masklinn]

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…

[Mark Lawrence]

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.

--
Cheers.

Mark Lawrence.

[Mike Meyer]

On Sat, 13 Oct 2012 19:18:12 +1100

Steven D'Aprano <st...@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
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

[Joshua Landau]

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 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. 

[Sturla Molden]

Den 13. okt. 2012 kl. 06:44 skrev Devin Jeanpierre <jeanpi...@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

[Joshua Landau]

On 13 October 2012 19:29, Sturla Molden <stu...@molden.no> wrote:

Den 13. okt. 2012 kl. 06:44 skrev Devin Jeanpierre <jeanpi...@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!

[Sturla Molden]

Den 13. okt. 2012 kl. 21:14 skrev Joshua Landau <joshua.l...@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

[Mathias Panzenböck]

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.

[Mathias Panzenböck]

On 10/13/2012 07:37 AM, Greg Ewing wrote:
> Ram Rachum wrote:
>> I could say that for newbies it's one small confusion that could removed from the language. You
>> and I have been programming for a long time so we take it for granted that * means multiplication,
>> but for any other person that's just another weird idiosyncrasy that further alienates programming.
>
> Do you have any evidence that a substantial number of
> beginners are confused by * for multiplication, or that
> they have trouble remembering what it means once they've
> been told?
>
> If you do, is there further evidence that they would
> find a dot to be any clearer?
>
> The use of a raised dot to indicate multiplication of
> numbers is actually quite rare even in mathematics, and I
> would not expect anyone without a mathematical background
> to even be aware of it.
>
> In primary school we're taught that 'x' means multiplication.
> Later when we come to algebra, we're taught not to use
> any symbol at all, just write things next to each other.
> A dot is only used in rare cases where there would
> otherwise be ambiguity -- and even then it's often
> preferred to parenthesise things instead.
>
> And don't forget there's great potential for confusion
> with the decimal point.
>

I'm -1 on the whole idea.

Also why use · and not ×? I think unicode in source code is a bad idea.

[Mathias Panzenböck]

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 <st...@pearwood.info <mailto:st...@pearwood.info>>

> _________________________________________________
> Python-ideas mailing list
> Python...@python.org <mailto:Python...@python.org>
> http://mail.python.org/__mailman/listinfo/python-ideas
> <http://mail.python.org/mailman/listinfo/python-ideas>

[Joshua Landau]

On 13 October 2012 21:20, Mathias Panzenböck <grosser.me...@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? Mînè łeŧs mê······

[Mathias Panzenböck]

On 10/13/2012 10:45 PM, Joshua Landau wrote:
> On 13 October 2012 21:20, Mathias Panzenböck <grosser.me...@gmx.net

> 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.)

[Greg Ewing]

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):
...

--
Greg

[MRAB]

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):
...

[Yuval Greenfield]

On Sun, Oct 14, 2012 at 2:04 AM, MRAB <pyt...@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

[Steven D'Aprano]

On 14/10/12 02:22, Mike Meyer wrote:
> On Sat, 13 Oct 2012 19:18:12 +1100
> Steven D'Aprano<st...@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? :)


--
Steven

[Mike Meyer]

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
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

[Joshua Landau]

On 14 October 2012 20:57, Mike Meyer <m...@mired.org> wrote:

On Sun, 14 Oct 2012 07:40:57 +0200
Yuval Greenfield <ubers...@gmail.com> wrote:

> On Sun, Oct 14, 2012 at 2:04 AM, MRAB <pyt...@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.

[MRAB]

On 2012-10-14 22:06, Joshua Landau wrote:
> On 14 October 2012 20:57, Mike Meyer <m...@mired.org

> <mailto:m...@mired.org>> wrote:
>
> On Sun, 14 Oct 2012 07:40:57 +0200
> Yuval Greenfield <ubers...@gmail.com

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.

[Joshua Landau]

On 14 October 2012 23:08, MRAB <pyt...@mrabarnett.plus.com> wrote:

On 2012-10-14 22:06, Joshua Landau wrote:

On 14 October 2012 20:57, Mike Meyer <m...@mired.org

<mailto:m...@mired.org>> wrote:

    On Sun, 14 Oct 2012 07:40:57 +0200
    Yuval Greenfield <ubers...@gmail.com

    <mailto:ubers...@gmail.com>> wrote:

     > On Sun, Oct 14, 2012 at 2:04 AM, MRAB <pyt...@mrabarnett.plus.com

No, no. "\\" would have priority, still. "\\uXXXX" is invalid outside of a string, anyway, so we're allowed to say that. 

[MRAB]

On 2012-10-14 23:42, Joshua Landau wrote:
> On 14 October 2012 23:08, MRAB <pyt...@mrabarnett.plus.com

> <mailto:pyt...@mrabarnett.plus.com>> wrote:
>
> On 2012-10-14 22:06, Joshua Landau wrote:
>
> On 14 October 2012 20:57, Mike Meyer <m...@mired.org
> <mailto:m...@mired.org>

> <mailto:m...@mired.org <mailto:m...@mired.org>>> wrote:
>
> On Sun, 14 Oct 2012 07:40:57 +0200
> Yuval Greenfield <ubers...@gmail.com
> <mailto:ubers...@gmail.com>

> <mailto:ubers...@gmail.com

> <mailto:ubers...@gmail.com>>__> wrote:
>
> > On Sun, Oct 14, 2012 at 2:04 AM, MRAB

> <pyt...@mrabarnett.plus.com <mailto:pyt...@mrabarnett.plus.com>
> <mailto:python@mrabarnett.__plus.com

OK, but what about raw string literals? Currently, "\\u0190" ==
r"\u0190", but "\\u0190" != r"Ɛ".

[Joshua Landau]

On 15 October 2012 00:46, MRAB <pyt...@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 ;).

[MRAB]

On 2012-10-15 01:12, Joshua Landau wrote:
> On 15 October 2012 00:46, MRAB <pyt...@mrabarnett.plus.com

> <mailto:pyt...@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. :-)

[Joshua Landau]

On 15 October 2012 01:35, MRAB <pyt...@mrabarnett.plus.com> wrote:

On 2012-10-15 01:12, Joshua Landau wrote:

On 15 October 2012 00:46, MRAB <pyt...@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. :-)

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.

[Stephen J. Turnbull]

Ram Rachum writes:
> On Fri, Oct 12, 2012 at 10:40 PM, Blake Hyde <syr...@gmail.com> wrote:
>
> > Is anything gained from this addition?
>
>
> To give a practical answer, I could say that for newbies it's one small

> confusion that could removed from the language.

Get Microsoft to agree and implement it in Excel and you might have a
point. But as long as Excel uses * for multiplication, I don't think
anybody who uses computers is going to have trouble learning this.

Anyway, Python believes in TOOWTDI ("the one old way to do it").[1]

Footnotes:
[1] With apologies to Tim Peters.

[Mike Graham]

On Sun, Oct 14, 2012 at 3:57 PM, Mike Meyer <m...@mired.org> wrote:
> On Sun, 14 Oct 2012 07:40:57 +0200
> Yuval Greenfield <ubers...@gmail.com> wrote:
>
>> On Sun, Oct 14, 2012 at 2:04 AM, MRAB <pyt...@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

[Jasper St. Pierre]

On Mon, Oct 15, 2012 at 3:12 PM, Mike Graham <mikeg...@gmail.com> wrote:
>> 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?

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...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas

--
Jasper

[Joao S. O. Bueno]

On 15 October 2012 16:12, Mike Graham <mikeg...@gmail.com> wrote:
> On Sun, Oct 14, 2012 at 3:57 PM, Mike Meyer <m...@mired.org> wrote:
>> On Sun, 14 Oct 2012 07:40:57 +0200
>> Yuval Greenfield <ubers...@gmail.com> wrote:
>>
>>> On Sun, Oct 14, 2012 at 2:04 AM, MRAB <pyt...@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?
>

" 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()

[MRAB]

On 2012-10-15 20:37, Jasper St. Pierre wrote:
> On Mon, Oct 15, 2012 at 3:12 PM, Mike Graham <mikeg...@gmail.com> wrote:
>>> 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?
>
> 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"

[Oleg Broytman]

On Mon, Oct 15, 2012 at 03:12:15PM -0400, Mike Graham <mikeg...@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.
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.

[Mike Graham]

On Mon, Oct 15, 2012 at 3:23 PM, Oleg Broytman <p...@phdru.name> wrote:
> On Mon, Oct 15, 2012 at 03:12:15PM -0400, Mike Graham <mikeg...@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.

Obviously we'd make those pesky semicolons optional in the process.

Mike

[Steven D'Aprano]

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 None
>
> Can 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!


--
Steven

[Stephen J. Turnbull]

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 None
>
> Can 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.

[Jim Jewett]

On 10/12/12, Ethan Furman <et...@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