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 4 of 4 — ← Prev page 1 2 3 [4]

#69109

On 26-03-14 03:56, MRAB wrote:
> On 2014-03-25 22:47, Ethan Furman wrote:
>> 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.
>>
> Or as a root operator, e.g. 3 √ x (the cube root of x).
>
Personally I would think such an operator is too limited to include in a programming language.
This kind of notation is only used with a constant to indicate what kind of root is taken and
only with positive integers. Something like the equivallent of the following I have never seen.

  t = 2.5
  x = 8.2
  y = t √ x

Of course we don't have to follow mathematical convention with python. However allowing any
unicode symbol as an identifier doesn't prohibit from using √ as an operator. We do have
"in" and "is" as operators now, even if they would otherwise be acceptable identifiers.
So I wonder, would you consider to introduce log as an operator. 2 log x seems an interesting
operation for a programmer.

-- 
Antoon Pardon

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

#69137

On Wed, Mar 26, 2014 at 2:52 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> On 26-03-14 03:56, MRAB wrote:
>> Or as a root operator, e.g. 3 √ x (the cube root of x).
>>
> Personally I would think such an operator is too limited to include in a programming language.
> This kind of notation is only used with a constant to indicate what kind of root is taken and
> only with positive integers. Something like the equivallent of the following I have never seen.
>
>   t = 2.5
>   x = 8.2
>   y = t √ x

An example is taking the geometric mean of an arbitrary number of values:

    product = functools.reduce(operator.mul, values, 1)
    n = len(values)
    geometric_mean = n √ product

I might argue though for the inverted syntax (product √ n) to more
closely parallel division.


> Of course we don't have to follow mathematical convention with python. However allowing any
> unicode symbol as an identifier doesn't prohibit from using √ as an operator. We do have
> "in" and "is" as operators now, even if they would otherwise be acceptable identifiers.
> So I wonder, would you consider to introduce log as an operator. 2 log x seems an interesting
> operation for a programmer.

If it's going to become an operator, then it has to be a keyword.
Changing a token that is currently allowed to be an identifier into a
keyword is generally avoided as much as possible, because it breaks
backward compatibility.  "in" and "is" have both been keywords for a
very long time, perhaps since the initial release of Python.

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

#69177

On 26-03-14 17:37, Ian Kelly wrote:
> On Wed, Mar 26, 2014 at 2:52 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> Of course we don't have to follow mathematical convention with python. However allowing any
>> unicode symbol as an identifier doesn't prohibit from using √ as an operator. We do have
>> "in" and "is" as operators now, even if they would otherwise be acceptable identifiers.
>> So I wonder, would you consider to introduce log as an operator. 2 log x seems an interesting
>> operation for a programmer.
> If it's going to become an operator, then it has to be a keyword.
> Changing a token that is currently allowed to be an identifier into a
> keyword is generally avoided as much as possible, because it breaks
> backward compatibility.  "in" and "is" have both been keywords for a
> very long time, perhaps since the initial release of Python.

I know, for such a reason I would love it if keywords would have been
written like this: 𝗱𝗲𝗳 (using mathematical bold) instead of just like
this: def (using plain latin letters). It would mean among other things
we could just write operator.not instead of having to write operator.not_

-- 
Antoon Pardon

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

#69194

On Thursday, March 27, 2014 3:06:02 PM UTC+5:30, Antoon Pardon wrote:
> On 26-03-14 17:37, Ian Kelly wrote:
> > On Wed, Mar 26, 2014 at 2:52 AM, Antoon Pardon
> >> Of course we don't have to follow mathematical convention with python. However allowing any
> >> unicode symbol as an identifier doesn't prohibit from using √ as an operator. We do have
> >> "in" and "is" as operators now, even if they would otherwise be acceptable identifiers.
> >> So I wonder, would you consider to introduce log as an operator. 2 log x seems an interesting
> >> operation for a programmer.
> > If it's going to become an operator, then it has to be a keyword.
> > Changing a token that is currently allowed to be an identifier into a
> > keyword is generally avoided as much as possible, because it breaks
> > backward compatibility.  "in" and "is" have both been keywords for a
> > very long time, perhaps since the initial release of Python.

> I know, for such a reason I would love it if keywords would have been
> written like this: 𝗱𝗲𝗳 (using mathematical bold) instead of just like
> this: def (using plain latin letters). It would mean among other things
> we could just write operator.not instead of having to write operator.not_

Just out of curiosity how do/did you type that?
When I see an exotic denizen from the unicode-universe I paste it into
emacs and ask "Who are you?"

But with your 'def' my emacs is going a bit crazy!

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

#69196

On 2014-03-27 08:10, Rustom Mody wrote:
> > I know, for such a reason I would love it if keywords would have
> > been written like this: 𝗱𝗲𝗳 (using mathematical bold) instead of
> > just like this: def (using plain latin letters). It would mean
> > among other things we could just write operator.not instead of
> > having to write operator.not_
> 
> Just out of curiosity how do/did you type that?
> When I see an exotic denizen from the unicode-universe I paste it
> into emacs and ask "Who are you?"
> 
> But with your 'def' my emacs is going a bit crazy!

I have the following in a file, which I can then open with Vim.  I
just type the text I want above the corresponding row of capital
letters and execute the statement on the first line.  Vim then
populates the system clipboard with the corresponding letters in the
Unicode font.  I'm sure there are font-translator pages that would
make it a little easier, but I'd already done this.  Just adjust for
Emacs ;-)

-tkc


let @+=join(map(split(getline('.'), '\zs'),
'matchstr(getline(line(".")+((v:val >= "A" && v:val <= "Z")?1:2)),
".\\{".(char2nr(tolower(v:val))-char2nr("a"))."}\\zs.")'),'')
ABCDEFGHIJKLMNOPQRSTUVWXYZ ASCII upper
abcdefghijklmnopqrstuvwxyz ASCII lower
𝐀𝐁𝐂𝐃𝐄𝐅𝐆𝐇𝐈𝐉𝐊𝐋𝐌𝐍𝐎𝐏𝐐𝐑𝐒𝐓𝐔𝐕𝐖𝐗𝐘𝐙 bold serif upper
𝐚𝐛𝐜𝐝𝐞𝐟𝐠𝐡𝐢𝐣𝐤𝐥𝐦𝐧𝐨𝐩𝐪𝐫𝐬𝐭𝐮𝐯𝐰𝐱𝐲𝐳 bold serif lower
𝐴𝐵𝐶𝐷𝐸𝐹𝐺𝐻𝐼𝐽𝐾𝐿𝑀𝑁𝑂𝑃𝑄𝑅𝑆𝑇𝑈𝑉𝑊𝑋𝑌𝑍 italic serif upper
𝑎𝑏𝑐𝑑𝑒𝑓𝑔𝑕𝑖𝑗𝑘𝑙𝑚𝑛𝑜𝑝𝑞𝑟𝑠𝑡𝑢𝑣𝑤𝑥𝑦𝑧 italic serif lower
𝑨𝑩𝑪𝑫𝑬𝑭𝑮𝑯𝑰𝑱𝑲𝑳𝑴𝑵𝑶𝑷𝑸𝑹𝑺𝑻𝑼𝑽𝑾𝑿𝒀𝒁 bold italic serif upper
𝒂𝒃𝒄𝒅𝒆𝒇𝒈𝒉𝒊𝒋𝒌𝒍𝒎𝒏𝒐𝒑𝒒𝒓𝒔𝒕𝒖𝒗𝒘𝒙𝒚𝒛 bold italic serif lower
𝓐𝓑𝓒𝓓𝓔𝓕𝓖𝓗𝓘𝓙𝓚𝓛𝓜𝓝𝓞𝓟𝓠𝓡𝓢𝓣𝓤𝓥𝓦𝓧𝓨𝓩 script upper
𝓪𝓫𝓬𝓭𝓮𝓯𝓰𝓱𝓲𝓳𝓴𝓵𝓶𝓷𝓸𝓹𝓺𝓻𝓼𝓽𝓾𝓿𝔀𝔁𝔂𝔃 script lower
𝔄𝔅𝔆𝔇𝔈𝔉𝔊𝔋𝔌𝔍𝔎𝔏𝔐𝔑𝔒𝔓𝔔𝔕𝔖𝔗𝔘𝔙𝔚𝔛𝔜𝔝 fraktur upper
𝔞𝔟𝔠𝔡𝔢𝔣𝔤𝔥𝔦𝔧𝔨𝔩𝔪𝔫𝔬𝔭𝔮𝔯𝔰𝔱𝔲𝔳𝔴𝔵𝔶𝔷 fraktur lower
𝕬𝕭𝕮𝕯𝕰𝕱𝕲𝕳𝕴𝕵𝕶𝕷𝕸𝕹𝕺𝕻𝕼𝕽𝕾𝕿𝖀𝖁𝖂𝖃𝖄𝖅 fraktur bold upper
𝖆𝖇𝖈𝖉𝖊𝖋𝖌𝖍𝖎𝖏𝖐𝖑𝖒𝖓𝖔𝖕𝖖𝖗𝖘𝖙𝖚𝖛𝖜𝖝𝖞𝖟 fraktur bold lower
𝔸𝔹𝔺𝔻𝔼𝔽𝔾𝔿𝕀𝕁𝕂𝕃𝕄𝕅𝕆𝕇𝕈𝕉𝕊𝕋𝕌𝕍𝕎𝕏𝕐𝕑 hollow upper
𝕒𝕓𝕔𝕕𝕖𝕗𝕘𝕙𝕚𝕛𝕜𝕝𝕞𝕟𝕠𝕡𝕢𝕣𝕤𝕥𝕦𝕧𝕨𝕩𝕪𝕫 hollow lower
𝖠𝖡𝖢𝖣𝖤𝖥𝖦𝖧𝖨𝖩𝖪𝖫𝖬𝖭𝖮𝖯𝖰𝖱𝖲𝖳𝖴𝖵𝖶𝖷𝖸𝖹 sans upper
𝖺𝖻𝖼𝖽𝖾𝖿𝗀𝗁𝗂𝗃𝗄𝗅𝗆𝗇𝗈𝗉𝗊𝗋𝗌𝗍𝗎𝗏𝗐𝗑𝗒𝗓 sans lower
𝗔𝗕𝗖𝗗𝗘𝗙𝗚𝗛𝗜𝗝𝗞𝗟𝗠𝗡𝗢𝗣𝗤𝗥𝗦𝗧𝗨𝗩𝗪𝗫𝗬𝗭 bold sans upper
𝗮𝗯𝗰𝗱𝗲𝗳𝗴𝗵𝗶𝗷𝗸𝗹𝗺𝗻𝗼𝗽𝗾𝗿𝘀𝘁𝘂𝘃𝘄𝘅𝘆𝘇 bold sans lower
𝘈𝘉𝘊𝘋𝘌𝘍𝘎𝘏𝘐𝘑𝘒𝘓𝘔𝘕𝘖𝘗𝘘𝘙𝘚𝘛𝘜𝘝𝘞𝘟𝘠𝘡 italic sans upper
𝘢𝘣𝘤𝘥𝘦𝘧𝘨𝘩𝘪𝘫𝘬𝘭𝘮𝘯𝘰𝘱𝘲𝘳𝘴𝘵𝘶𝘷𝘸𝘹𝘺𝘻 italic sans lower
𝘼𝘽𝘾𝘿𝙀𝙁𝙂𝙃𝙄𝙅𝙆𝙇𝙈𝙉𝙊𝙋𝙌𝙍𝙎𝙏𝙐𝙑𝙒𝙓𝙔𝙕 bold italic sans upper
𝙖𝙗𝙘𝙙𝙚𝙛𝙜𝙝𝙞𝙟𝙠𝙡𝙢𝙣𝙤𝙥𝙦𝙧𝙨𝙩𝙪𝙫𝙬𝙭𝙮𝙯 bold italic sans lower
𝙰𝙱𝙲𝙳𝙴𝙵𝙶𝙷𝙸𝙹𝙺𝙻𝙼𝙽𝙾𝙿𝚀𝚁𝚂𝚃𝚄𝚅𝚆𝚇𝚈𝚉 mono upper
𝚊𝚋𝚌𝚍𝚎𝚏𝚐𝚑𝚒𝚓𝚔𝚕𝚖𝚗𝚘𝚙𝚚𝚛𝚜𝚝𝚞𝚟𝚠𝚡𝚢𝚣 mono lower
𝟎𝟏𝟐𝟑𝟒𝟓𝟔𝟕𝟖𝟗 bold serif
𝟘𝟙𝟚𝟛𝟜𝟝𝟞𝟟𝟠𝟡 hollow
𝟢𝟣𝟤𝟥𝟦𝟧𝟨𝟩𝟪𝟫 sans
𝟬𝟭𝟮𝟯𝟰𝟱𝟲𝟳𝟴𝟵 sans bold
𝟶𝟷𝟸𝟹𝟺𝟻𝟼𝟽𝟾𝟿 mono

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

#69283

On Thu, Mar 27, 2014, at 11:10, Rustom Mody wrote:
> Just out of curiosity how do/did you type that?
> When I see an exotic denizen from the unicode-universe I paste it into
> emacs and ask "Who are you?"
> 
> But with your 'def' my emacs is going a bit crazy!

Your emacs probably is using UCS-2 or UTF-16. The former can't handle
characters above 65535 at all, the latter stores them as if they were
two characters [so code that's not expecting them will handle them
incorrectly]

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

#69312

On Saturday, March 29, 2014 12:25:45 AM UTC+5:30, rand...@fastmail.us wrote:
> On Thu, Mar 27, 2014, at 11:10, Rustom Mody wrote:
> > Just out of curiosity how do/did you type that?
> > When I see an exotic denizen from the unicode-universe I paste it into
> > emacs and ask "Who are you?"
> > But with your 'def' my emacs is going a bit crazy!

> Your emacs probably is using UCS-2 or UTF-16. The former can't handle
> characters above 65535 at all, the latter stores them as if they were
> two characters [so code that's not expecting them will handle them
> incorrectly]

My current diagnosis (with the help of more knowledgeable folks than myself)
is that its a font problem.

There simply doesn't exist a font (or more likely I dont know of) that 
- is readable
- is scaleable
- spans the whole 17*65536 unicode space

At least out here:
- gnu-unifont does not cover things outside BMP
- dejavu seems to have some bugs

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

#69314

On Sat, Mar 29, 2014 at 4:00 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> My current diagnosis (with the help of more knowledgeable folks than myself)
> is that its a font problem.
>
> There simply doesn't exist a font (or more likely I dont know of) that
> - is readable
> - is scaleable
> - spans the whole 17*65536 unicode space

For my MUDding, I use a font imaginatively named "Monospace", which
does most of what I want. There are a handful of characters that come
out as the "square with digits inside", but not huge blocks (certainly
not "everything non-BMP" or anything like that). It's fairly readable,
although I don't know about scaling - I run it at 14pt and nowhere
else. Comes with Debian.

ChrisA

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

#69317

Rustom Mody <rustompmody@gmail.com> writes:

> At least out here:
> - gnu-unifont does not cover things outside BMP

That implies the GNU Unifont contains no characters from outside the
BMP, which is untrue.

Rather, the GNU Unifont's claim to fame is that it covers all characters
in the BMP. But it does contain many characters outside the BMP.
<URL:http://www.unifoundry.com/unifont.html>

So, I'd re-phrase the above caution more accurately as: The GNU Unifont
has complete coverage of the BMP, and incomplete coverage outside the BMP.

-- 
 \      “People always ask me, ‘Where were you when Kennedy was shot?’ |
  `\                        Well, I don't have an alibi.” —Emo Philips |
_o__)                                                                  |
Ben Finney

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

#69336

On Fri, 28 Mar 2014 22:00:49 -0700 (PDT), Rustom Mody
<rustompmody@gmail.com> declaimed the following:


>There simply doesn't exist a font (or more likely I dont know of) that 
>- is readable
>- is scaleable
>- spans the whole 17*65536 unicode space
>
	Considering that a 5x8 bitmap font (which is unlikely to even have
enough pixels to produce even 65536 unique glyphs) would take 5.6MB for
your (17*65536), I wouldn't want to see what an algorithmic description
would require.

	Looking at some of my collection of fonts, TTF and some PS, seem to be
running around 100kB per font, and those fonts likely have around 128-192
glyphs.

	For 1114112 glyphs (17*65536) at, say 164 glyphs pre 100kB gives 680MB
per FONT. Assume the standards: normal, bold, italic, bold-italic -- one is
now up to 2.7GB per typeface. 5.4GB to support just one serif and one sans
serif typeface.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#69349

On Sun, Mar 30, 2014 at 5:11 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
>         Considering that a 5x8 bitmap font (which is unlikely to even have
> enough pixels to produce even 65536 unique glyphs) would take 5.6MB for
> your (17*65536), I wouldn't want to see what an algorithmic description
> would require.
>
>         Looking at some of my collection of fonts, TTF and some PS, seem to be
> running around 100kB per font, and those fonts likely have around 128-192
> glyphs.
>
>         For 1114112 glyphs (17*65536) at, say 164 glyphs pre 100kB gives 680MB
> per FONT. Assume the standards: normal, bold, italic, bold-italic -- one is
> now up to 2.7GB per typeface. 5.4GB to support just one serif and one sans
> serif typeface.

Most fonts these days are vector, not bitmap, but a 5x8 bitmap has
forty pixels, any of which can be either on or off - that gives
roughly twice as much data space as the 21-bit Unicode spec. Plenty of
room for 17*65536 unique glyphs. But you're right that it'd then take
~5-6MB to store that, minimum.

ChrisA

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

#69372

Chris Angelico wrote:
> a 5x8 bitmap has
> forty pixels, any of which can be either on or off - that gives
> roughly twice as much data space as the 21-bit Unicode spec.

We don't need a font, then -- just map the pixels
straight onto bits in the character code!

Might require some user re-education, but that's
a small price to pay for saving so much memory
space.

-- 
Greg

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

#69065

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]

#69059

 Mark H Harris <harrismh777@gmail.com> Wrote in message:
> 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?

See the official docs


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

There's also a method on str that'll tell you:  isidentifier (). 
 To see such methods,  use dir ("")

As for why, you can get a pretty good idea from the reference
 above, as it lists 12 unicode categories that can be used. You
 can also look at pep3131 and at Potsdam ' s site. Both links are
 on the above page. Letters, marks, connectors,  and numbers,  but
 not punctuation. 


-- 
DaveA

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

#69095

On 3/25/2014 2:30 PM, Mark H Harris wrote:
> greetings, I would like to create a lamda as follows:

A lambda is a function lacking a proper name.

> √ = lambda n: sqrt(n)

This is discouraged in PEP8. If the following worked,

def √(n): return sqrt(n)

would have √ as its __name__ attribute

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web