Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69049 > unrolled thread

unicode as valid naming symbols

Back to article view | Back to comp.lang.python

Contents

  unicode as valid naming symbols Mark H Harris <harrismh777@gmail.com> - 2014-03-25 13:30 -0500
    Re: unicode as valid naming symbols wxjmfauth@gmail.com - 2014-03-25 11:52 -0700
      Re: unicode as valid naming symbols Mark H Harris <harrismh777@gmail.com> - 2014-03-25 14:24 -0500
      Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-03-25 19:16 -0700
    Re: unicode as valid naming symbols MRAB <python@mrabarnett.plus.com> - 2014-03-25 19:24 +0000
      Re: unicode as valid naming symbols Mark H Harris <harrismh777@gmail.com> - 2014-03-25 14:29 -0500
        Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-03-25 21:48 +0200
          Re: unicode as valid naming symbols Skip Montanaro <skip@pobox.com> - 2014-03-25 14:54 -0500
          Re: unicode as valid naming symbols Cameron Simpson <cs@zip.com.au> - 2014-03-26 09:16 +1100
        Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-25 13:49 -0600
        Re: unicode as valid naming symbols Tim Chase <python.list@tim.thechases.com> - 2014-03-25 15:29 -0500
        Re: unicode as valid naming symbols Ethan Furman <ethan@stoneleaf.us> - 2014-03-25 15:47 -0700
        Re: unicode as valid naming symbols Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 23:58 +0000
          Re: unicode as valid naming symbols Mark H Harris <harrismh777@gmail.com> - 2014-03-27 10:28 -0500
            Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-03-27 08:51 -0700
              Re: unicode as valid naming symbols Mark H Harris <harrismh777@gmail.com> - 2014-03-27 11:03 -0500
                Re: unicode as valid naming symbols Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-28 12:45 +1300
              Re: unicode as valid naming symbols MRAB <python@mrabarnett.plus.com> - 2014-03-27 17:17 +0000
                Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-03-27 10:53 -0700
            Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-27 10:22 -0600
              Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-03-27 10:41 -0700
            Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-03-28 03:23 +1100
            Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-31 11:55 +0200
            Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-31 11:40 -0600
            Re: unicode as valid naming symbols Tim Chase <python.list@tim.thechases.com> - 2014-03-31 13:02 -0500
            Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-31 12:10 -0600
            Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-31 21:31 +0200
            Re: unicode as valid naming symbols Terry Reedy <tjreedy@udel.edu> - 2014-03-31 16:12 -0400
            Re: unicode as valid naming symbols Terry Reedy <tjreedy@udel.edu> - 2014-03-31 16:15 -0400
              Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-03-31 23:34 +0300
            Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-31 18:47 -0600
            Re: unicode as valid naming symbols David Hutto <dwightdhutto@gmail.com> - 2014-03-31 23:58 -0400
            Re: unicode as valid naming symbols David Hutto <dwightdhutto@gmail.com> - 2014-04-01 00:11 -0400
            Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-04-01 10:19 +0200
            Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 03:18 -0600
              Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-04-01 12:32 +0300
                Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 03:58 -0600
                  Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-04-01 15:02 +0300
                    Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-01 23:54 +1100
                      Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-04-01 16:16 +0300
                        Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-02 00:32 +1100
                          Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-04-01 18:59 +0300
                            Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-04-01 19:58 -0700
                              Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-04-01 20:16 -0700
                                Re: unicode as valid naming symbols Marko Rauhamaa <marko@pacujo.net> - 2014-04-02 08:55 +0300
                Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-01 21:39 +1100
            Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-04-01 12:37 +0200
            Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-01 21:58 +1100
            Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-04-01 13:59 +0200
              Re: unicode as valid naming symbols Roy Smith <roy@panix.com> - 2014-04-01 08:29 -0400
                Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-02 00:08 +1100
                  Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-04-01 06:34 -0700
            Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-02 00:00 +1100
            Re: unicode as valid naming symbols Ned Batchelder <ned@nedbatchelder.com> - 2014-04-01 09:33 -0400
            Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-04-02 00:44 +1100
              Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-04-01 06:58 -0700
            Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 09:53 -0600
        Re: unicode as valid naming symbols MRAB <python@mrabarnett.plus.com> - 2014-03-26 02:56 +0000
        Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-03-26 14:09 +1100
        Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-26 09:25 +0100
        Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-26 09:52 +0100
        Re: unicode as valid naming symbols Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-26 10:37 -0600
        Re: unicode as valid naming symbols Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-27 10:36 +0100
          Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-03-27 08:10 -0700
            Re: unicode as valid naming symbols Tim Chase <python.list@tim.thechases.com> - 2014-03-27 10:34 -0500
            Re: unicode as valid naming symbols random832@fastmail.us - 2014-03-28 14:55 -0400
              Re: unicode as valid naming symbols Rustom Mody <rustompmody@gmail.com> - 2014-03-28 22:00 -0700
                Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-03-29 16:12 +1100
                Re: unicode as valid naming symbols Ben Finney <ben+python@benfinney.id.au> - 2014-03-29 16:32 +1100
                Re: unicode as valid naming symbols Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-29 14:11 -0400
                Re: unicode as valid naming symbols Chris Angelico <rosuav@gmail.com> - 2014-03-30 09:01 +1100
                  Re: unicode as valid naming symbols Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-30 19:16 +1300
      Re: unicode as valid naming symbols Mark H Harris <harrismh777@gmail.com> - 2014-03-25 14:29 -0500
    Re:unicode as valid naming symbols Dave Angel <davea@davea.name> - 2014-03-25 15:45 -0400
    Re: unicode as valid naming symbols Terry Reedy <tjreedy@udel.edu> - 2014-03-25 22:26 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#69049 — unicode as valid naming symbols

greetings, I would like to create a lamda as follows:

√ = lambda n: sqrt(n)


On my keyboard mapping the "problem" character is alt-v which produces 
the radical symbol. When trying to set the symbol as a name within the 
name-space gives a syntax error:

 >>> from math import sqrt
 >>>
 >>> √ = lambda n: sqrt(n)
SyntaxError: invalid character in identifier
 >>>
 >>>

however this works:

 >>>
 >>> λ = lambda n: sqrt(n)
 >>>
 >>> λ(2)
1.4142135623730951
 >>>

   The question is which unicode(s) are capable of being proper name 
characters, and which ones are off-limits, and why?


marcus

[toc] | [next] | [standalone]

#69052

Le mardi 25 mars 2014 19:30:34 UTC+1, Mark H. Harris a écrit :
> greetings, I would like to create a lamda as follows:
> 
> 
> 
> √ = lambda n: sqrt(n)
> 
> 
> 
> 
> 
> On my keyboard mapping the "problem" character is alt-v which produces 
> 
> the radical symbol. When trying to set the symbol as a name within the 
> 
> name-space gives a syntax error:
> 
> 
> 
>  >>> from math import sqrt
> 
>  >>>
> 
>  >>> √ = lambda n: sqrt(n)
> 
> SyntaxError: invalid character in identifier
> 
>  >>>
> 
>  >>>
> 
> 
> 
> however this works:
> 
> 
> 
>  >>>
> 
>  >>> λ = lambda n: sqrt(n)
> 
>  >>>
> 
>  >>> λ(2)
> 
> 1.4142135623730951
> 
>  >>>
> 
> 
> 
>    The question is which unicode(s) are capable of being proper name 
> 
> characters, and which ones are off-limits, and why?
> 
> 
> 
> 
> 
> marcus

>>> '√'.isidentifier()
False
>>> 'λ'.isidentifier()
True
>>> '$'.isidentifier()
False
>>> '啕'.isidentifier()
True
>>> 'a'.isidentifier()
True
>>> '啕2z'.isidentifier()
True
>>> print(''.isidentifier.__doc__)
S.isidentifier() -> bool

Return True if S is a valid identifier according
to the language definition.
>>>

cf "unicode.org" doc

jmf

[toc] | [prev] | [next] | [standalone]

#69055

On 3/25/14 1:52 PM, wxjmfauth@gmail.com wrote:
 >>>> '√'.isidentifier()
 > False
 >>>> 'λ'.isidentifier()
 > True


 > S.isidentifier() -> bool
 >
 > Return True if S is a valid identifier according
 > to the language definition.
 >>>>
 >
 > cf "unicode.org" doc

Excellent, thanks!

marcus

[toc] | [prev] | [next] | [standalone]

#69092

On Wednesday, March 26, 2014 12:22:40 AM UTC+5:30, wxjm...@gmail.com wrote:
> Le mardi 25 mars 2014 19:30:34 UTC+1, Mark H. Harris a écrit :
> > greetings, I would like to create a lamda as follows:
> > √ = lambda n: sqrt(n)
> > On my keyboard mapping the "problem" character is alt-v which produces 
> > the radical symbol. When trying to set the symbol as a name within the 
> > name-space gives a syntax error:
> >  >>> from math import sqrt
> >  >>> √ = lambda n: sqrt(n)
> > SyntaxError: invalid character in identifier
> > however this works:
> >  >>> λ = lambda n: sqrt(n)
> >  >>> λ(2)
> > 1.4142135623730951
> >    The question is which unicode(s) are capable of being proper name 
> > characters, and which ones are off-limits, and why?
> > marcus

> >>> '√'.isidentifier()
> False
> >>> 'λ'.isidentifier()
> True
> >>> '$'.isidentifier()
> False
> >>> '啕'.isidentifier()
> True
> >>> 'a'.isidentifier()
> True
> >>> '啕2z'.isidentifier()
> True
> >>> print(''.isidentifier.__doc__)
> S.isidentifier() -> bool

> Return True if S is a valid identifier according
> to the language definition.

Thanks jmf!
You obviously have more unicode knowledge than many (most?) of us here.
And when you contribute that knowledge in short-n-sweet form as above
it is helpful to all.

> cf "unicode.org" doc

Ummm...
Less helpful here.
What/where do you expect someone to start reading?
If a python beginner asks some basic question and someone here were to say
"Go read up on http://python.org"
who is helped?

[toc] | [prev] | [next] | [standalone]

#69056

On 2014-03-25 18:30, Mark H Harris wrote:
> greetings, I would like to create a lamda as follows:
>
> √ = lambda n: sqrt(n)
>
>
> On my keyboard mapping the "problem" character is alt-v which produces
> the radical symbol. When trying to set the symbol as a name within the
> name-space gives a syntax error:
>
>   >>> from math import sqrt
>   >>>
>   >>> √ = lambda n: sqrt(n)
> SyntaxError: invalid character in identifier
>   >>>
>   >>>
>
> however this works:
>
>   >>>
>   >>> λ = lambda n: sqrt(n)
>   >>>
>   >>> λ(2)
> 1.4142135623730951
>   >>>
>
>     The question is which unicode(s) are capable of being proper name
> characters, and which ones are off-limits, and why?
>
It's explained in PEP 3131.

Basically, a name should to start with a letter (this has been extended
to include Chinese characters, etc) or an underscore.

λ is a classified as Lowercase_Letter.

√ is classified as Math_Symbol.

[toc] | [prev] | [next] | [standalone]

#69057

On 3/25/14 2:24 PM, MRAB wrote:
 > It's explained in PEP 3131.
 >
 > Basically, a name should to start with a letter (this has been extended
 > to include Chinese characters, etc) or an underscore.
 >
 > λ is a classified as Lowercase_Letter.
 >
 > √ is classified as Math_Symbol.

    Thanks much!  I'll note that for improvements. Any unicode symbol 
(that is not a number) should be allowed as an identifier.

   marcus

[toc] | [prev] | [next] | [standalone]

#69061

Mark H Harris <harrismh777@gmail.com>:

>    Thanks much!  I'll note that for improvements. Any unicode symbol
> (that is not a number) should be allowed as an identifier.

I don't know if that's a good idea, but that's how it is in lisp/scheme.

Thus, "*" and "1+" are normal identifiers in lisp and scheme.


Marko

[toc] | [prev] | [next] | [standalone]

#69064

On Tue, Mar 25, 2014 at 2:48 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> I don't know if that's a good idea, but that's how it is in lisp/scheme.
>
> Thus, "*" and "1+" are normal identifiers in lisp and scheme.

But parsing Lisp is pretty trivial.

Skip

[toc] | [prev] | [next] | [standalone]

#69077

On 25Mar2014 21:48, Marko Rauhamaa <marko@pacujo.net> wrote:
> Mark H Harris <harrismh777@gmail.com>:
> >    Thanks much!  I'll note that for improvements. Any unicode symbol
> > (that is not a number) should be allowed as an identifier.
> 
> I don't know if that's a good idea, but that's how it is in lisp/scheme.

I think it is a terrible idea. Doing that preemptively prevents
allowing them for any other purpose in the future, ever.

Identifiers are easy if you stick to the corresponding Unicode class.

Sucking in every other symbol prevents other uses later. Such as using the
square root symbol as a prefix operator. Etc.

Don't be too grabby with syntax; it leaves no room  later for better syntax.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

[toc] | [prev] | [next] | [standalone]

#69062

On Tue, Mar 25, 2014 at 1:29 PM, Mark H Harris <harrismh777@gmail.com> wrote:
> On 3/25/14 2:24 PM, MRAB wrote:
>> It's explained in PEP 3131.
>>
>> Basically, a name should to start with a letter (this has been extended
>> to include Chinese characters, etc) or an underscore.
>>
>> λ is a classified as Lowercase_Letter.
>>
>> √ is classified as Math_Symbol.
>
>    Thanks much!  I'll note that for improvements. Any unicode symbol (that
> is not a number) should be allowed as an identifier.

√ cannot be used in identifiers for the same reasons that + and ~
cannot: identifiers are intended to be alphanumeric. √ is not
currently the name of an operator, but who knows what may happen in
the future?

Python generally follows Annex 31 of the Unicode standard in this regard:

http://www.unicode.org/reports/tr31/

[toc] | [prev] | [next] | [standalone]

#69067

On 2014-03-25 14:29, Mark H Harris wrote:
>  > It's explained in PEP 3131.
>  >
>  > Basically, a name should to start with a letter (this has been
>  > extended to include Chinese characters, etc) or an underscore.
>  >
>  > λ is a classified as Lowercase_Letter.
>  >
>  > √ is classified as Math_Symbol.  
> 
>     Thanks much!  I'll note that for improvements. Any unicode
> symbol (that is not a number) should be allowed as an identifier.

It's not just about number'ness:

  >>> letter = "a"
  >>> number = "2"
  >>> letter.isidentifier()
  True
  >>> number.isidentifier()
  False
  >>> (letter + number).isidentifier()
  True

-tkc

[toc] | [prev] | [next] | [standalone]

#69079

On 03/25/2014 12:29 PM, Mark H Harris wrote:
> On 3/25/14 2:24 PM, MRAB wrote:
>> It's explained in PEP 3131.
>>
>> Basically, a name should to start with a letter (this has been extended
>> to include Chinese characters, etc) or an underscore.
>>
>> λ is a classified as Lowercase_Letter.
>>
>> √ is classified as Math_Symbol.
>
>     Thanks much!  I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an
> identifier.

No, it shouldn't.  Doing so would mean we could not use √ as the square root operator in the future.

Identifiers are made up of letters, numbers, and the underscore.  Considering all the unicode letters and unicode 
numbers out there, you shouldn't be lacking for names.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#69083

On Tue, 25 Mar 2014 14:29:06 -0500, Mark H Harris wrote:

> On 3/25/14 2:24 PM, MRAB wrote:
>  > It's explained in PEP 3131.
>  >
>  > Basically, a name should to start with a letter (this has been
>  > extended to include Chinese characters, etc) or an underscore.
>  >
>  > λ is a classified as Lowercase_Letter.
>  >
>  > √ is classified as Math_Symbol.
> 
>     Thanks much!  I'll note that for improvements. Any unicode symbol
> (that is not a number) should be allowed as an identifier.


To quote a great Spaniard:

    “You keep using that word, I do not think it means what you
     think it means.”


Do you think that the ability to write this would be an improvement?

import ⌺
⌚ = ⌺.╩░
⑥ = 5*⌺.⋨⋩
❹ = ⑥ - 1
♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
⌺.˘˜¨´՛՜(♅⚕⚛)


Of course, it's not even necessary to be that exotic. "Any unicode symbol 
that is not a number"... that means things like these:

x+y
spam.eggs
cheese["toast"]

would count as identifiers, which could lead to a little bit of parsing 
ambiguity... *wink*

There are languages that can allow arbitrary symbols as identifiers, like 
Lisp and Forth. You will note that they have a certain reputation for 
being, um, different, and although both went through periods of 
considerable popularity, both have faded in popularity since. While they 
have their strengths, and their defenders, nobody argues that they are 
readily accessible to the average programmer.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#69195

On 3/25/14 6:58 PM, Steven D'Aprano wrote:

> To quote a great Spaniard:
>
>      “You keep using that word, I do not think it means what you
>       think it means.”

    In~con~theveable !      My name is Inigo Montoya, you killed my 
father, prepare to die...

> Do you think that the ability to write this would be an improvement?
>
> import ⌺
> ⌚ = ⌺.╩░
> ⑥ = 5*⌺.⋨⋩
> ❹ = ⑥ - 1
> ♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
> ⌺.˘˜¨´՛՜(♅⚕⚛)

    Steven, you're killing me here; argument by analogy does not work!

    √ = lambda n: sqrt(n)      <===== but this should work...

    In point of fact, it should be built-in !   OK, IMHO.

> Of course, it's not even necessary to be that exotic. "Any unicode symbol
> that is not a number"... that means things like these:

   No, any unicode character (except numerals) should be able to begin a 
name identifier.   alt-l  λ   and  alt-v  √   should be valid first 
character name identifier symbols.

> There are languages that can allow arbitrary symbols as identifiers, like
> Lisp and Forth. You will note that they have a certain reputation for
> being, um, different, and although both went through periods of
> considerable popularity, both have faded in popularity since.

    Actually, there is a recent resurgence of popularity in both common 
lisp and scheme these days.  But, again, that has nothing to do with my 
argument.  No modern language should limit the use of certain symbols to 
say, only math  √ .    The radical symbol is more often than not going 
to be useful only with math (which , by the way is why it should be 
built-in as  √ = squre-rooot) but why limit its use elsewhere.

    Whether this can work in python is also beside the point, because 
I'm not demanding anything here either, at this point.

have a good day!

marcus

[toc] | [prev] | [next] | [standalone]

#69200

On Thursday, March 27, 2014 8:58:51 PM UTC+5:30, Mark H. Harris wrote:
> On 3/25/14 6:58 PM, Steven D'Aprano wrote:

> > To quote a great Spaniard:
> >      “You keep using that word, I do not think it means what you
> >       think it means.”

>     In~con~theveable !      My name is Inigo Montoya, you killed my 
> father, prepare to die...

> > Do you think that the ability to write this would be an improvement?
> > import ⌺
> > ⌚ = ⌺.╩░
> > ⑥ = 5*⌺.⋨⋩
> > ❹ = ⑥ - 1
> > ♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
> > ⌺.˘˜¨´՛՜(♅⚕⚛)

>     Steven, you're killing me here; argument by analogy does not work!

>     √ = lambda n: sqrt(n)      <===== but this should work...

>     In point of fact, it should be built-in !   OK, IMHO.

> > Of course, it's not even necessary to be that exotic. "Any unicode symbol
> > that is not a number"... that means things like these:

>    No, any unicode character (except numerals) should be able to begin a 
> name identifier.   alt-l  λ   and  alt-v  √   should be valid first 
> character name identifier symbols.

> > There are languages that can allow arbitrary symbols as identifiers, like
> > Lisp and Forth. You will note that they have a certain reputation for
> > being, um, different, and although both went through periods of
> > considerable popularity, both have faded in popularity since.

>     Actually, there is a recent resurgence of popularity in both common 
> lisp and scheme these days.  But, again, that has nothing to do with my 
> argument.  No modern language should limit the use of certain symbols to 
> say, only math  √ .    The radical symbol is more often than not going 
> to be useful only with math (which , by the way is why it should be 
> built-in as  √ = squre-rooot) but why limit its use elsewhere.

>     Whether this can work in python is also beside the point, because 
> I'm not demanding anything here either, at this point.

> have a good day!

The problem is that mathematicians invent notations in a completely
laissez-faire manner.

Language implementers having to unrestrainedly keep up would go mad.
And then us vanilla users (aka programmers) would have to deal with maddened
implementers.

Observe:
Good ol infix -- x+y..
prefix (with paren) -- foo(x)
prefix without  -- ¬ x
In case you thought alphanumerics had parens --  sin x
Then theres postfix   -- n!
Inside fix   -- nCr (Or if you prefer ⁿCᵣ ??)
And outside fix -- mod -- |x|

And Ive probably forgotten 2 dozen other common ones

[toc] | [prev] | [next] | [standalone]

#69201

On 3/27/14 10:51 AM, Rustom Mody wrote:
>
> Observe:
> Good ol infix -- x+y..
> prefix (with paren) -- foo(x)
> prefix without  -- ¬ x
> In case you thought alphanumerics had parens --  sin x
> Then theres postfix   -- n!
> Inside fix   -- nCr (Or if you prefer ⁿCᵣ ??)
> And outside fix -- mod -- |x|
>
> And Ive probably forgotten 2 dozen other common ones
>

Oh, I know... that's why I'm not demanding anything (what a head-ache).

[toc] | [prev] | [next] | [standalone]

#69227

Mark H Harris wrote:
>> Good ol infix -- x+y..
>> prefix (with paren) -- foo(x)
>> prefix without  -- ¬ x
>> In case you thought alphanumerics had parens --  sin x
>> Then theres postfix   -- n!
>> Inside fix   -- nCr (Or if you prefer ⁿCᵣ ??)
>> And outside fix -- mod -- |x|

And mismatched delimiters:

    [5, 7)

    |x>

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#69213

On 2014-03-27 15:51, Rustom Mody wrote:
> On Thursday, March 27, 2014 8:58:51 PM UTC+5:30, Mark H. Harris wrote:
>> On 3/25/14 6:58 PM, Steven D'Aprano wrote:
>
>> > To quote a great Spaniard:
>> >      “You keep using that word, I do not think it means what you
>> >       think it means.”
>
>>     In~con~theveable !      My name is Inigo Montoya, you killed my
>> father, prepare to die...
>
>> > Do you think that the ability to write this would be an improvement?
>> > import ⌺
>> > ⌚ = ⌺.╩░
>> > ⑥ = 5*⌺.⋨⋩
>> > ❹ = ⑥ - 1
>> > ♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
>> > ⌺.˘˜¨´՛՜(♅⚕⚛)
>
>>     Steven, you're killing me here; argument by analogy does not work!
>
>>     √ = lambda n: sqrt(n)      <===== but this should work...
>
>>     In point of fact, it should be built-in !   OK, IMHO.
>
>> > Of course, it's not even necessary to be that exotic. "Any unicode symbol
>> > that is not a number"... that means things like these:
>
>>    No, any unicode character (except numerals) should be able to begin a
>> name identifier.   alt-l  λ   and  alt-v  √   should be valid first
>> character name identifier symbols.
>
>> > There are languages that can allow arbitrary symbols as identifiers, like
>> > Lisp and Forth. You will note that they have a certain reputation for
>> > being, um, different, and although both went through periods of
>> > considerable popularity, both have faded in popularity since.
>
>>     Actually, there is a recent resurgence of popularity in both common
>> lisp and scheme these days.  But, again, that has nothing to do with my
>> argument.  No modern language should limit the use of certain symbols to
>> say, only math  √ .    The radical symbol is more often than not going
>> to be useful only with math (which , by the way is why it should be
>> built-in as  √ = squre-rooot) but why limit its use elsewhere.
>
>>     Whether this can work in python is also beside the point, because
>> I'm not demanding anything here either, at this point.
>
>> have a good day!
>
> The problem is that mathematicians invent notations in a completely
> laissez-faire manner.
>
> Language implementers having to unrestrainedly keep up would go mad.
> And then us vanilla users (aka programmers) would have to deal with maddened
> implementers.
>
> Observe:
> Good ol infix -- x+y..
> prefix (with paren) -- foo(x)
> prefix without  -- ¬ x
> In case you thought alphanumerics had parens --  sin x
> Then theres postfix   -- n!
> Inside fix   -- nCr (Or if you prefer ⁿCᵣ ??)
> And outside fix -- mod -- |x|
>
> And Ive probably forgotten 2 dozen other common ones
>
You haven't mentioned implicit multiplication: xy

Then there's raising to a power sin²(x), except that what looks like
raising to -1 actually means the inverse function (arcsin).

[toc] | [prev] | [next] | [standalone]

#69215

On Thursday, March 27, 2014 10:47:04 PM UTC+5:30, MRAB wrote:
> On 2014-03-27 15:51, Rustom Mody wrote:
> > On Thursday, March 27, 2014 8:58:51 PM UTC+5:30, Mark H. Harris wrote:
> >> On 3/25/14 6:58 PM, Steven D'Aprano wrote:
> >> > To quote a great Spaniard:
> >> >      “You keep using that word, I do not think it means what you
> >> >       think it means.”
> >>     In~con~theveable !      My name is Inigo Montoya, you killed my
> >> father, prepare to die...
> >> > Do you think that the ability to write this would be an improvement?
> >> > import ⌺
> >> > ⌚ = ⌺.╩░
> >> > ⑥ = 5*⌺.⋨⋩
> >> > ❹ = ⑥ - 1
> >> > ♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
> >> > ⌺.˘˜¨´՛՜(♅⚕⚛)
> >>     Steven, you're killing me here; argument by analogy does not work!
> >>     √ = lambda n: sqrt(n)      <===== but this should work...
> >>     In point of fact, it should be built-in !   OK, IMHO.
> >> > Of course, it's not even necessary to be that exotic. "Any unicode symbol
> >> > that is not a number"... that means things like these:
> >>    No, any unicode character (except numerals) should be able to begin a
> >> name identifier.   alt-l  λ   and  alt-v  √   should be valid first
> >> character name identifier symbols.
> >> > There are languages that can allow arbitrary symbols as identifiers, like
> >> > Lisp and Forth. You will note that they have a certain reputation for
> >> > being, um, different, and although both went through periods of
> >> > considerable popularity, both have faded in popularity since.
> >>     Actually, there is a recent resurgence of popularity in both common
> >> lisp and scheme these days.  But, again, that has nothing to do with my
> >> argument.  No modern language should limit the use of certain symbols to
> >> say, only math  √ .    The radical symbol is more often than not going
> >> to be useful only with math (which , by the way is why it should be
> >> built-in as  √ = squre-rooot) but why limit its use elsewhere.
> >>     Whether this can work in python is also beside the point, because
> >> I'm not demanding anything here either, at this point.
> >> have a good day!
> > The problem is that mathematicians invent notations in a completely
> > laissez-faire manner.
> > Language implementers having to unrestrainedly keep up would go mad.
> > And then us vanilla users (aka programmers) would have to deal with maddened
> > implementers.
> > Observe:
> > Good ol infix -- x+y..
> > prefix (with paren) -- foo(x)
> > prefix without  -- ¬ x
> > In case you thought alphanumerics had parens --  sin x
> > Then theres postfix   -- n!
> > Inside fix   -- nCr (Or if you prefer ⁿCᵣ ??)
> > And outside fix -- mod -- |x|
> > And Ive probably forgotten 2 dozen other common ones

> You haven't mentioned implicit multiplication: xy

Yeah -- thats a bad one!

Can mean 
- ordinary multiply (if you are in school)
- overloaded (scalar-field or scalar-vector) multiply in linear algebra
- function application (tensors??)
- concatenation (awk, snobol (with space))
- a 2 char variable (for 'normal' (whatever that means) programmer)

> Then there's raising to a power sin²(x), except that what looks like
> raising to -1 actually means the inverse function (arcsin).

Non-linear notations is another can (barrel?) of worms
Matrices/Determinants anyone?

Yeah... Copying the *notations* of mathematicians is not such a great idea.

And yet doing away with it too summarily leads to Cobol, Sql etc.
The math remains willy-nilly... just under a steaming pile of alphanumeriage.

[toc] | [prev] | [next] | [standalone]

#69206

On Thu, Mar 27, 2014 at 9:28 AM, Mark H Harris <harrismh777@gmail.com> wrote:
>> Do you think that the ability to write this would be an improvement?
>>
>> import ⌺
>> ⌚ = ⌺.╩░
>> ⑥ = 5*⌺.⋨⋩
>> ❹ = ⑥ - 1
>> ♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
>> ⌺.˘˜¨´՛՜(♅⚕⚛)
>
>
>    Steven, you're killing me here; argument by analogy does not work!

That's not an analogy.  That's an example of valid Python code if
arbitrary Unicode characters could be used to name identifiers.

>   No, any unicode character (except numerals) should be able to begin a name
> identifier.   alt-l  λ   and  alt-v  √   should be valid first character
> name identifier symbols.

What's a numeral?  The circled numbers in the example above are
categorized as No ("Number, Other").  Currently Python only allows the
ASCII digits in numeric literals, but who's to say that ٤٢ --
categorized as Nd ("Number, Decimal Digit") shouldn't be a valid way
to write 42?  ㊷ seems a bit excessive for a literal, though, so should
that be permitted to start an identifier?

>> There are languages that can allow arbitrary symbols as identifiers, like
>> Lisp and Forth. You will note that they have a certain reputation for
>> being, um, different, and although both went through periods of
>> considerable popularity, both have faded in popularity since.
>
>
>    Actually, there is a recent resurgence of popularity in both common lisp
> and scheme these days.  But, again, that has nothing to do with my argument.
> No modern language should limit the use of certain symbols to say, only math
> √ .    The radical symbol is more often than not going to be useful only
> with math (which , by the way is why it should be built-in as  √ =
> squre-rooot) but why limit its use elsewhere.
>
>    Whether this can work in python is also beside the point, because I'm not
> demanding anything here either, at this point.

One of the things that Python is widely known for is its readability.
Allowing symbols such as √ to denote identifiers may be quite
expressive and appreciable to the person writing the code. However it
damages readability considerably, as seen in Steven's example above.
Personally I'm not interested in having to maintain another
programmer's code that arbitrarily uses ⌚ as a timer function, ╩ as
intersection or ░ as a matrix constructor.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web