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

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

Well, I finally ran into a Python Unicode problem, sort of

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

Contents

  Well, I finally ran into a Python Unicode problem, sort of John Ladasky <john_ladasky@sbcglobal.net> - 2016-07-02 23:58 -0700
    Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 00:07 -0700
      Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-03 10:26 +0300
        Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 01:38 -0700
          Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-03 12:01 +0300
            Re: Well, I finally ran into a Python Unicode problem, sort of Chris Angelico <rosuav@gmail.com> - 2016-07-04 01:14 +1000
            Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 14:21 -0700
      Re: Well, I finally ran into a Python Unicode problem, sort of John Ladasky <john_ladasky@sbcglobal.net> - 2016-07-03 09:24 -0700
    Re: Well, I finally ran into a Python Unicode problem, sort of Rustom Mody <rustompmody@gmail.com> - 2016-07-03 00:26 -0700
    Re: Well, I finally ran into a Python Unicode problem, sort of Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-03 10:29 +0300
      Re: Well, I finally ran into a Python Unicode problem, sort of Robert Kern <robert.kern@gmail.com> - 2016-07-03 10:16 +0100
    Re: Well, I finally ran into a Python Unicode problem, sort of Chris Angelico <rosuav@gmail.com> - 2016-07-03 17:41 +1000
      Re: Well, I finally ran into a Python Unicode problem, sort of John Ladasky <john_ladasky@sbcglobal.net> - 2016-07-03 11:39 -0700
        Re: Well, I finally ran into a Python Unicode problem, sort of MRAB <python@mrabarnett.plus.com> - 2016-07-03 20:41 +0100
        Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 14:28 -0700
          Re: Well, I finally ran into a Python Unicode problem, sort of Steven D'Aprano <steve@pearwood.info> - 2016-07-04 12:33 +1000
            Re: Well, I finally ran into a Python Unicode problem, sort of Rustom Mody <rustompmody@gmail.com> - 2016-07-03 22:14 -0700
              Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-04 01:11 -0700
                Re: Well, I finally ran into a Python Unicode problem, sort of Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-04 13:10 +0300
                Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-04 12:04 +0300
              Re: Well, I finally ran into a Python Unicode problem, sort of Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-04 09:08 +0300
    Re: Well, I finally ran into a Python Unicode problem, sort of Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2016-07-03 11:53 +0200
      Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-03 14:01 +0300
        Re: Well, I finally ran into a Python Unicode problem, sort of Christian Gollwitzer <auriocus@gmx.de> - 2016-07-03 13:16 +0200
          Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-03 14:22 +0300
            Re: Well, I finally ran into a Python Unicode problem, sort of Christian Gollwitzer <auriocus@gmx.de> - 2016-07-03 16:05 +0200
              Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-03 17:39 +0300
            Re: Well, I finally ran into a Python Unicode problem, sort of Random832 <random832@fastmail.com> - 2016-07-03 16:49 -0400
              Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-04 00:25 +0300
        Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-03 12:50 +0100
          Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 14:26 -0700
    Re: Well, I finally ran into a Python Unicode problem, sort of eryk sun <eryksun@gmail.com> - 2016-07-03 23:46 +0000
      Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 17:00 -0700
        Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-04 01:17 +0100
          Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 17:24 -0700
            Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-04 01:39 +0100
              Re: Well, I finally ran into a Python Unicode problem, sort of Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-03 18:15 -0700
                Re: Well, I finally ran into a Python Unicode problem, sort of Random832 <random832@fastmail.com> - 2016-07-03 22:20 -0400
                Re: Well, I finally ran into a Python Unicode problem, sort of Rustom Mody <rustompmody@gmail.com> - 2016-07-04 05:16 -0700
                Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-04 11:26 +0100
          Re: Well, I finally ran into a Python Unicode problem, sort of Steven D'Aprano <steve@pearwood.info> - 2016-07-04 12:30 +1000
            Re: Well, I finally ran into a Python Unicode problem, sort of Ned Batchelder <ned@nedbatchelder.com> - 2016-07-04 05:47 -0700
              Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-04 15:36 +0100
                Re: Well, I finally ran into a Python Unicode problem, sort of Ned Batchelder <ned@nedbatchelder.com> - 2016-07-04 07:46 -0700
                  Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-04 17:16 +0100
                    Re: Well, I finally ran into a Python Unicode problem, sort of Marko Rauhamaa <marko@pacujo.net> - 2016-07-04 19:44 +0300
            Re: Well, I finally ran into a Python Unicode problem, sort of BartC <bc@freeuk.com> - 2016-07-04 11:05 +0100
              Re: Well, I finally ran into a Python Unicode problem, sort of Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-04 13:26 +0300
        Re: Well, I finally ran into a Python Unicode problem, sort of Random832 <random832@fastmail.com> - 2016-07-03 22:16 -0400

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

#110978 — Well, I finally ran into a Python Unicode problem, sort of

A while back, I shared my love for using Greek letters as variable names in my Python (3.4) code -- when, and only when, they are warranted for improved readability.  For example, I like to see the following:


from math import pi as π

c = 2 * π * r


When I am copying mathematical formulas from publications, and Greek letters are used in that publication, I prefer to follow the text exactly as written.

Up until today, every character I've tried has been accepted by the Python interpreter as a legitimate character for inclusion in a variable name.  Now I'm copying a formula which defines a gradient.  The nabla symbol (∇) is used in the naming of gradients.  Python isn't having it.  The interpreter throws a "SyntaxError: invalid character in identifier" when it encounters the ∇.

I am now wondering what constitutes a valid character for an identifier, and how they were chosen.  Obviously, the Western alphabet and standard Greek letters work.  I just tried a few very weird characters from the Latin Extended range, and some Cyrillic characters.  These are also fine.

A philosophical question.  Why should any character be excluded from a variable name, besides the fact that it might also be an operator?

This might be a problem I can solve, I'm not sure.  Is there a file that the Python interpreter refers to which defines the accepted variable name characters?  Perhaps I could just add ∇.

[toc] | [next] | [standalone]

#110979

On Sunday, July 3, 2016 at 6:59:14 PM UTC+12, John Ladasky wrote:
> from math import pi as π
> 
> c = 2 * π * r

    ldo@theon:~> python3
    Python 3.5.1+ (default, Jun 10 2016, 09:03:40) 
    [GCC 5.4.0 20160603] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from math import pi as π
    >>> 
    >>> c = 2 * π * r
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'r' is not defined

It wasn’t the “π” it was complaining about...

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

#110980

Lawrence D’Oliveiro <lawrencedo99@gmail.com>:

> It wasn’t the “π” it was complaining about...

The question is why π is accepted but ∇ is not.

The immediate reason is that π is a letter while ∇ is not. But the
question, then, is why bother excluding nonletters from identifiers.

Personally, I don't think even π should be used in identifiers.
Mathematicians and physicists have a questionable tradition of using
single-character identifiers in their formulas. That shouldn't be
transported to programming.


Marko

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

#110984

On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:

> Personally, I don't think even π should be used in identifiers.

Why not? Python already has all the other single-character constants in what probably the most fundamental identity in all of mathematics:

    $$e^{i \pi} + 1 = 0$$

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

#110985

Lawrence D’Oliveiro <lawrencedo99@gmail.com>:

> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:
>
>> Personally, I don't think even π should be used in identifiers.
>
> Why not?

1. It can't be typed easily.

2. It can look like an n.

3. Single-character identifiers should not be promoted, especially with
   a global scope.

> Python already has all the other single-character constants in what
> probably the most fundamental identity in all of mathematics:
>
>     $$e^{i \pi} + 1 = 0$$

Mathematics and physics have run into trouble with single-character
identifiers already. They have run out of letters and have had to reuse
them. Programmers used to have the same problem until they realized it's
ok to use descriptive names.

Just say,

    >>> import cmath
    >>> cmath.e ** (1j * cmath.pi) + 1
    1.2246467991473532e-16j


Marko

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

#110999

On Sun, Jul 3, 2016 at 7:01 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Lawrence D’Oliveiro <lawrencedo99@gmail.com>:
>
>> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:
>>
>>> Personally, I don't think even π should be used in identifiers.
>>
>> Why not?
>
> 1. It can't be typed easily.
>
> 2. It can look like an n.
>
> 3. Single-character identifiers should not be promoted, especially with
>    a global scope.

None of these is a language-level concern. You can't type it? That's
your problem - and you can choose not to use it. But Python lets you,
if you want to. Remember, some people speak Greek natively, and for
those people, typing Greek text is as natural as typing Latin text is
for us. Similarly, Cyrillic text is the most natural language for
Russian speakers. Why should Python block them?

Your other concerns might be a case for linters, but definitely not
the language.

ChrisA

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

#111011

On Sunday, July 3, 2016 at 9:02:05 PM UTC+12, Marko Rauhamaa wrote:
> Lawrence D’Oliveiro:
> 
>> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote:
>>
>>> Personally, I don't think even π should be used in identifiers.
>>
> > Why not?
> 
> 1. It can't be typed easily.

I have a custom .XCompose, so it’s just “compose-p-i”. Easy to type, easy to remember.

> 2. It can look like an n.

Only to someone accustomed to using just one alphabet. :)

> 3. Single-character identifiers should not be promoted, especially with
>    a global scope.

It’s no more “global” than “math.e”. And what about “1j”? (That completes the triumvirate of single-letter names from the Euler identity.)

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

#111005

Lawrence, I trust you understand that I didn't post a complete working program, just a few lines showing the intended usage?

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

#110981

On Sunday, July 3, 2016 at 12:29:14 PM UTC+5:30, John Ladasky wrote:
> A while back, I shared my love for using Greek letters as variable names in my Python (3.4) code -- when, and only when, they are warranted for improved readability.  For example, I like to see the following:
> 
> 
> from math import pi as π
> 
> c = 2 * π * r
> 
> 
> When I am copying mathematical formulas from publications, and Greek letters are used in that publication, I prefer to follow the text exactly as written.
> 
> Up until today, every character I've tried has been accepted by the Python interpreter as a legitimate character for inclusion in a variable name.  Now I'm copying a formula which defines a gradient.  The nabla symbol (∇) is used in the naming of gradients.  Python isn't having it.  The interpreter throws a "SyntaxError: invalid character in identifier" when it encounters the ∇.
> 
> I am now wondering what constitutes a valid character for an identifier, and how they were chosen.  Obviously, the Western alphabet and standard Greek letters work.  I just tried a few very weird characters from the Latin Extended range, and some Cyrillic characters.  These are also fine.

https://docs.python.org/3.5/reference/lexical_analysis.html
points to
https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html

Quite hardwired

> 
> A philosophical question.  Why should any character be excluded from a variable name, besides the fact that it might also be an operator?
> 
> This might be a problem I can solve, I'm not sure.  Is there a file that the Python interpreter refers to which defines the accepted variable name characters?  Perhaps I could just add ∇.

You need to try something like

>>> import unicodedata as ud
>>> ud.category("∇")
'Sm'
>>> ud.category("A")
'Lu'
>>> ud.category("π")
'Ll'
>>> ud.category("a")
'Ll'

followed by figuring out why/what etc from (say)
https://en.wikipedia.org/wiki/Unicode_character_property

This is the way it IS
Not saying it SHOULD BE…

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

#110982

John Ladasky writes:

[- -]

> The nabla symbol (∇) is used in the naming of gradients.  Python isn't
> having it.  The interpreter throws a "SyntaxError: invalid character
> in identifier" when it encounters the ∇.
>
> I am now wondering what constitutes a valid character for an
> identifier, and how they were chosen.  Obviously, the Western alphabet
> and standard Greek letters work.  I just tried a few very weird
> characters from the Latin Extended range, and some Cyrillic
> characters.  These are also fine.

I think they merely extended the identifier syntax to Unicode: one or
more letters, underscores and digits, not starting with a digit. The
nabla symbol is not classified as a letter in Unicode, so it's not
allowed under this rule, and there is no other rule to allow it.

(Hm. Python seems to understand that the character occurs in what is
intended to be an identifier. Perhaps that's a default error message.)

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

#110986

On 2016-07-03 08:29, Jussi Piitulainen wrote:
> (Hm. Python seems to understand that the character occurs in what is
> intended to be an identifier. Perhaps that's a default error message.)

I suspect that "identifier" is the final catch-all token in the lexer. Comments 
and strings are clearly delimited. Keywords, operators, and [{(braces)}] are all 
explicitly whitelisted from finite lists. Well, I guess it could have been 
intended by the user to be a numerical literal, but I suspect that's attempted 
before identifier.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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

#110983

On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky <john_ladasky@sbcglobal.net> wrote:
> Up until today, every character I've tried has been accepted by the Python interpreter as a legitimate character for inclusion in a variable name.  Now I'm copying a formula which defines a gradient.  The nabla symbol (∇) is used in the naming of gradients.  Python isn't having it.  The interpreter throws a "SyntaxError: invalid character in identifier" when it encounters the ∇.
>
> I am now wondering what constitutes a valid character for an identifier, and how they were chosen.  Obviously, the Western alphabet and standard Greek letters work.  I just tried a few very weird characters from the Latin Extended range, and some Cyrillic characters.  These are also fine.
>

Very good question! The detaily answer is here:

https://docs.python.org/3/reference/lexical_analysis.html#identifiers

> A philosophical question.  Why should any character be excluded from a variable name, besides the fact that it might also be an operator?
>

In a way, that's exactly what's happening here. Python permits certain
categories of character as identifiers, leaving other categories
available for operators. Even though there aren't any non-ASCII
operators in a vanilla CPython, it's plausible that someone could
create a Python-based language with more operators (eg ≠ NOT EQUAL TO
as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
is nonsensical.

> This might be a problem I can solve, I'm not sure.  Is there a file that the Python interpreter refers to which defines the accepted variable name characters?  Perhaps I could just add ∇.
>

The key here is its Unicode category:

>>> unicodedata.category("∇")
'Sm'

You could probably hack CPython to include Sm, and maybe Sc, Sk, and
So, as valid identifier characters. I'm not sure where, though, and
I've just spent a good bit of time delving (it's based on the
XID_Start and XID_Continue derived properties, but I have no idea
where they're defined - Tools/unicode/makeunicodedata.py looks
promising, but even there, I can't find it). And - or maybe instead -
you could appeal to the core devs to have the category/ies in question
added to the official Python spec. Symbols like that are a bit of a
grey area, so you may find that you're starting a huge debate :)

Have fun.

ChrisA

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

#111007

On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote:
> On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote:

> Very good question! The detaily answer is here:
> 
> https://docs.python.org/3/reference/lexical_analysis.html#identifiers
> 
> > A philosophical question.  Why should any character be excluded from a variable name, besides the fact that it might also be an operator?
> 
> In a way, that's exactly what's happening here. Python permits certain
> categories of character as identifiers, leaving other categories
> available for operators. Even though there aren't any non-ASCII
> operators in a vanilla CPython, it's plausible that someone could
> create a Python-based language with more operators (eg ≠ NOT EQUAL TO
> as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
> is nonsensical.

I agree that there are some characters in the Unicode definition that could (should?) be operators and, as such, disallowed in identifiers.  "≠", "≥" and "√" come to mind.  I don't know whether the Unicode "character properties" are assigned to the characters in a way that would be satisfying to the needs of programmers.  I'll do some reading.

> Symbols like that are a bit of a
> grey area, so you may find that you're starting a huge debate :)

Oh, I can see that debate coming.  I know that not all of these characters are easily TYPED, and so I have to reach for a Unicode table to cut and paste them.  But once but and pasted, they are easily READ, and that's a big plus.

Here's another worm for the can.  Would you rather read this...

d = sqrt(x**2 + y**2)

...or this?

d = √(x² + y²)

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

#111008

On 2016-07-03 19:39, John Ladasky wrote:
> On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote:
>> On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote:
>
>> Very good question! The detaily answer is here:
>>
>> https://docs.python.org/3/reference/lexical_analysis.html#identifiers
>>
>> > A philosophical question.  Why should any character be excluded from a variable name, besides the fact that it might also be an operator?
>>
>> In a way, that's exactly what's happening here. Python permits certain
>> categories of character as identifiers, leaving other categories
>> available for operators. Even though there aren't any non-ASCII
>> operators in a vanilla CPython, it's plausible that someone could
>> create a Python-based language with more operators (eg ≠ NOT EQUAL TO
>> as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
>> is nonsensical.
>
> I agree that there are some characters in the Unicode definition that could (should?) be operators and, as such, disallowed in identifiers.  "≠", "≥" and "√" come to mind.  I don't know whether the Unicode "character properties" are assigned to the characters in a way that would be satisfying to the needs of programmers.  I'll do some reading.
>
>> Symbols like that are a bit of a
>> grey area, so you may find that you're starting a huge debate :)
>
> Oh, I can see that debate coming.  I know that not all of these characters are easily TYPED, and so I have to reach for a Unicode table to cut and paste them.  But once but and pasted, they are easily READ, and that's a big plus.
>
> Here's another worm for the can.  Would you rather read this...
>
> d = sqrt(x**2 + y**2)
>
> ...or this?
>
> d = √(x² + y²)
>
It's easy to read something as simple like that, but it's harder when 
the exponent is more than a number or a variable. And what about a**b**c?

Not to mention the limited number of superscript codepoints available...

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

#111014

On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote:
> Here's another worm for the can.  Would you rather read this...
> 
> d = sqrt(x**2 + y**2)
> 
> ...or this?
> 
> d = √(x² + y²)

Neither. I would rather see

    d = math.hypot(x, y)

Much simpler, don’t you think?

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

#111039

On Mon, 4 Jul 2016 07:28 am, Lawrence D’Oliveiro wrote:

> On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote:
>> Here's another worm for the can.  Would you rather read this...
>> 
>> d = sqrt(x**2 + y**2)
>> 
>> ...or this?
>> 
>> d = √(x² + y²)
> 
> Neither. I would rather see
> 
>     d = math.hypot(x, y)
> 
> Much simpler, don’t you think?

Only if you think of x and y as the sides of a triangle, and remember
that "hypot" is a Unix-like abbreviation for hypotenuse (rather than,
say, "hypothesis". And it doesn't help you one bit when it comes to:

a = √(4x²y - 3xy² + 2xy - 1)


Personally, I'm not convinced about using the very limited number of
superscript code points to represent exponentiation. Using √ as an unary
operator looks cute, but I don't know that it adds enough to the language
to justify the addition.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#111044

On Monday, July 4, 2016 at 8:03:47 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 4 Jul 2016 07:28 am, Lawrence D’Oliveiro wrote:
> 
> > On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote:
> >> Here's another worm for the can.  Would you rather read this...
> >> 
> >> d = sqrt(x**2 + y**2)
> >> 
> >> ...or this?
> >> 
> >> d = √(x² + y²)
> > 
> > Neither. I would rather see
> > 
> >     d = math.hypot(x, y)
> > 
> > Much simpler, don’t you think?
> 
> Only if you think of x and y as the sides of a triangle, and remember
> that "hypot" is a Unix-like abbreviation for hypotenuse (rather than,
> say, "hypothesis". And it doesn't help you one bit when it comes to:
> 
> a = √(4x²y - 3xy² + 2xy - 1)

In math typically one would write

a = √4x²y - 3xy² + 2xy - 1

with the radical sign running along upto and slightly beyond the 1

My unicode prowess is not upto doing that
Though experts may be able to use macrons/overlines 

> 
> 
> Personally, I'm not convinced about using the very limited number of
> superscript code points to represent exponentiation. Using √ as an unary
> operator looks cute, but I don't know that it adds enough to the language
> to justify the addition.

I guess I am more or less in agreement (on THIS/THESE)
ie √ and superscripts is probably not worth the headache

Subscripts OTOH as part of identifier-lexemes doesn't seem to have any issues

Python3

 >>> a₁ = 1
  File "<stdin>", line 1
    a₁ = 1
     ^
SyntaxError: invalid character in identifier

Haskell already has it

Prelude>  let a₁ = 1
Prelude>  a₁
1
Prelude> 

Haskell allows the same for superscripts:

Prelude> let a¹ = 1
Prelude> a¹
1

which is probably not such a great idea!
Prelude>  a¹ +   a₁
2
Prelude> 

My main point being unicode gives a wide repertory -- thats good
It also gives char-classification -- thats a start
But its not enough for designing a (modern) programming

Of course one can stay with ASCII
Like "There are many ways to skin a cat"
the modern version would be "There are many ways to be a Luddite"

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

#111057

On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote:
> Something could be done, but if the intention is to allow
> mathematical notation, it needs to be done with care.

Mathematics uses single-character variable names so that multiplication can be implicit.

An old, stillborn language design from the 1960s called CPL* had two syntaxes for variable names:
* a single lowercase letter, optionally followed by any number of primes “'”;
* an uppercase letter followed by letters or digits.

It also allowed implicit multiplication; single-letter identifiers could be run together without spaces, but multi-character ones needed to be delimited by spaces or non-identifier characters. E.g.

  Sqrt(bb - 4ac)
  Area ≡ Length Width

*It was never fully implemented, but a cut-down derivative named BCPL did get some use. Some researchers at Bell Labs took it as their starting point, first creating a language called “B”, then another one called “C” ... well, the rest is history.

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

#111060

Lawrence D’Oliveiro writes:

> On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote:
>> Something could be done, but if the intention is to allow
>> mathematical notation, it needs to be done with care.
>
> Mathematics uses single-character variable names so that
> multiplication can be implicit.

Certainly on topic, though independent of Unicode. I was thinking of
different classes of operator symbols.

> An old, stillborn language design from the 1960s called CPL* had two
> syntaxes for variable names:
> * a single lowercase letter, optionally followed by any number of primes “'”;
> * an uppercase letter followed by letters or digits.
>
> It also allowed implicit multiplication; single-letter identifiers
> could be run together without spaces, but multi-character ones needed
> to be delimited by spaces or non-identifier characters. E.g.
>
>   Sqrt(bb - 4ac)
>   Area ≡ Length Width
>
> *It was never fully implemented, but a cut-down derivative named BCPL
> did get some use. Some researchers at Bell Labs took it as their
> starting point, first creating a language called “B”, then another one
> called “C” ... well, the rest is history. 

There's been at least D, F, J, K (APL family), R, S (_before_ R), T (a
Lisp), X (the window system), Z (some specification language).

Any single-letter non-ASCII names yet? Spelled-out like Lambda and Omega
don't count.

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

#111080

Lawrence D’Oliveiro <lawrencedo99@gmail.com>:

> Mathematics uses single-character variable names so that
> multiplication can be implicit.

I don't think anybody developed mathematical notation systematically.
Rather, over the centuries, various masters came up with personal
abbreviations and shorthand, which spread among admirers and students
through emulation. The resulting two-dimensional hodgepodge needs to be
supplemented by much natural-language handwaving. Rigorous treatment
needs to use a formal language, eg: <URL:
http://us.metamath.org/mpeuni/evlslem2.html>.

Anyway, most programming has little use for mathematics. Thus, a
general-purpose programming language shouldn't bend over backwards to
placate that particular application domain.


Marko

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

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

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

csiph-web