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

#69214

On Thursday, March 27, 2014 9:52:40 PM UTC+5:30, Ian wrote:
> On Thu, Mar 27, 2014 at 9:28 AM, Mark H Harris 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.

Python has other lexical categories than identifier-chars eg operators.
Enriching that set is a somewhat different direction from 
enriching the identifier charset.

Note both these directions are valid bit different
This table http://www.unicode.org/charts/PDF/U2200.pdf
looks unpleasantly overfilled.  However good deal is stylistic differences
≥ vs ≧ and sometimes even indistinguishable ∈ vs ∊.

If we accept that python is more readable than Cobol, having a good
selection from the above makes for a programming language more readable in an
analogous manner.

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

#69207

On Fri, Mar 28, 2014 at 2:28 AM, Mark H Harris <harrismh777@gmail.com> wrote:
>   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, even whitespace??

ChrisA

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

#69420

On 27-03-14 17:22, Ian Kelly wrote:
> 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!
> [  ------ 8< ---------- ]
> 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.

I don't find Steven's example convincing. Sure it can be used in a way
that damages readability considerably however lots of things in python
can be abused in a way that damages readability considerably.

That you are not interested in having to maintain someone's code who
would use such symbols is irrelevant. IIRC people have used the exact
same kind of argument against decorators and the if-else operator.

It seems we are all consenting adults until someone doesn't like the
idea how it might influence his job. In that case it shouldn't be
allowed.

-- 
Antoon Pardon

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

#69438

On Mon, Mar 31, 2014 at 3:55 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> On 27-03-14 17:22, Ian Kelly wrote:
>> 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!
>> [  ------ 8< ---------- ]
>> 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.
>
> I don't find Steven's example convincing. Sure it can be used in a way
> that damages readability considerably however lots of things in python
> can be abused in a way that damages readability considerably.
>
> That you are not interested in having to maintain someone's code who
> would use such symbols is irrelevant. IIRC people have used the exact
> same kind of argument against decorators and the if-else operator.
>
> It seems we are all consenting adults until someone doesn't like the
> idea how it might influence his job. In that case it shouldn't be
> allowed.

That was an exaggeration on my part.  It wouldn't affect my job, as I
wouldn't expect to ever actually have to maintain anything like the
above.  My greater point though is that it damages Python's
readability for no actual gain in my view.  There is nothing useful
you can do with a name that is the U+1F4A9 character that you can't do
just as easily with alphanumeric identifiers like pile_of_poo (or
куча_фекалий if one prefers; that's auto-translated, so don't blame me
if it's a poor translation). The kinds of symbols that we're talking
about here aren't part of any writing systems, and so to incorporate
them in *names* as if they were is an abuse of Unicode.

I don't think the comparisons to decorators and the if-else operator
are apt. First, because while those may degrade readability, they do
so in a constrained way.  A decorator application is just the @ symbol
and an identifier.  The if-else is just three expressions separated by
keywords.  In the case of arbitrary Unicode identifiers, we're talking
about approximately doubling the number of different characters (out
of a continuously growing set) that could be used, many of which are
easily confused with other characters. Of course the potential for
confusion already exists, but that's no justification for aggravating
it.

Second, at least in the case of decorators, while I don't dispute that
they can harm readability, I think that in the majority of cases they
actually help it.  That's because the @ syntax placed before a
function or class clearly denotes that the construct is being
decorated by something.  The alternative to the syntax is to place an
assignment like "f = decorate(f)" *after* the definition, where it is
much less prominent.  That the reader then potentially has to go
figure out what the decorator does is true regardless of whether the @
syntax is used or not.  I'm unable to imagine any case where an
arbitrary Unicode identifier would actually improve readability.

Finally, in my experience the "consenting adults" line is usually used
in the context of program or library design.  I don't believe it's
appropriate when discussing the design of the language itself, which
should be kept as clean as possible.  The logical conclusion of that
would be Lisp-like macros where every user ends up with their own
unique and incompatible version of the language, because we're all
consenting adults here, right?

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

#69439

On 2014-03-31 11:40, Ian Kelly wrote:
> There is nothing useful
> you can do with a name that is the U+1F4A9 character that you can't
> do just as easily with alphanumeric identifiers like pile_of_poo (or
> куча_фекалий if one prefers; that's auto-translated, so don't blame
> me if it's a poor translation).  The kinds of symbols that we're
> talking about here aren't part of any writing systems, and so to
> incorporate them in *names* as if they were is an abuse of Unicode.

It does get more complex though, when you could have things like

 黄金屎 = "\U0001f4a9"

Like you, I don't expect to ever encounter something like this in the
wild, but they are indeed symbols used in a writing system. :-)

-tkc

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

#69440

On Mon, Mar 31, 2014 at 12:02 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2014-03-31 11:40, Ian Kelly wrote:
>> There is nothing useful
>> you can do with a name that is the U+1F4A9 character that you can't
>> do just as easily with alphanumeric identifiers like pile_of_poo (or
>> куча_фекалий if one prefers; that's auto-translated, so don't blame
>> me if it's a poor translation).  The kinds of symbols that we're
>> talking about here aren't part of any writing systems, and so to
>> incorporate them in *names* as if they were is an abuse of Unicode.
>
> It does get more complex though, when you could have things like
>
>  黄金屎 = "\U0001f4a9"
>
> Like you, I don't expect to ever encounter something like this in the
> wild, but they are indeed symbols used in a writing system. :-)

That's already a legal identifier, though.  The constituent ideographs
are categorized as "Letter, Other", not symbols.

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

#69442

Op 31-03-14 19:40, Ian Kelly schreef:
> On Mon, Mar 31, 2014 at 3:55 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> On 27-03-14 17:22, Ian Kelly wrote:
>>> 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!
>>> [  ------ 8< ---------- ]
>>> 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.
>>
>> I don't find Steven's example convincing. Sure it can be used in a way
>> that damages readability considerably however lots of things in python
>> can be abused in a way that damages readability considerably.
>>
>> That you are not interested in having to maintain someone's code who
>> would use such symbols is irrelevant. IIRC people have used the exact
>> same kind of argument against decorators and the if-else operator.
>>
>> It seems we are all consenting adults until someone doesn't like the
>> idea how it might influence his job. In that case it shouldn't be
>> allowed.
> 
> That was an exaggeration on my part.  It wouldn't affect my job, as I
> wouldn't expect to ever actually have to maintain anything like the
> above.  My greater point though is that it damages Python's
> readability for no actual gain in my view.  There is nothing useful
> you can do with a name that is the U+1F4A9 character that you can't do
> just as easily with alphanumeric identifiers like pile_of_poo (or
> куча_фекалий if one prefers; that's auto-translated, so don't blame me
> if it's a poor translation). The kinds of symbols that we're talking
> about here aren't part of any writing systems, and so to incorporate
> them in *names* as if they were is an abuse of Unicode.

Your argument doesn't has much weight. First of all it can be used
for just restricting names to the ascii range. Second of all I
think a good chosen symbolic name can be more readable than a
name in a character set you are not familiar with. A good chosen
symbol will evoke a meaning with a lot of people. A name in a
character set you are not familiar with is just gibberish to
you.

> I don't think the comparisons to decorators and the if-else operator
> are apt.

I didn't make such a comparison. I just noted the arguments against
were similar.

> First, because while those may degrade readability, they do
> so in a constrained way.  A decorator application is just the @ symbol
> and an identifier.

And if abused, can totally change the working of your function. There
is no guarantee that the function returned, has any relation with the
original function. If that can't be a night mare for readability,
I don't know what is.

> The if-else is just three expressions separated by
> keywords.

Yes but if used unrestrained in arbitrary expressions will make those
expressions hard to understand.

> In the case of arbitrary Unicode identifiers, we're talking
> about approximately doubling the number of different characters (out
> of a continuously growing set) that could be used, many of which are
> easily confused with other characters. Of course the potential for
> confusion already exists, but that's no justification for aggravating
> it.

So what if we double the number of different characters? I don't care
about the number of them, I care about how meaningful they are. And
as you say confusion is already possible. A good programmer knows
how to deal with such a possible confusion, that the number of
cases increases, doesn't need to be a problem for those that care
about this.

> Second, at least in the case of decorators, while I don't dispute that
> they can harm readability, I think that in the majority of cases they
> actually help it.

But that is not a fair comparison now, is it. What you are doing here
is comparing actual use, to a worst case doom scenario.

-- 
Antoon Pardon

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

#69443

On 3/31/2014 1:40 PM, Ian Kelly wrote:

> Second, at least in the case of decorators, while I don't dispute that
> they can harm readability, I think that in the majority of cases they
> actually help it.  That's because the @ syntax placed before a
> function or class clearly denotes that the construct is being
> decorated by something.  The alternative to the syntax is to place an
> assignment like "f = decorate(f)" *after* the definition, where it is
> much less prominent.

Plus, it means writing and reading the name 3 times instead  of 1. This 
is not much of an issue for 'f', but it is for names like 
'modify_x07_with_qz46pt'. Names like this occur when interfacing to 
external systems that dictate the names needed (as when interfacing 
Python to Objective-C  on Macs).

-- 
Terry Jan Reedy

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

#69445

On 3/31/2014 3:31 PM, Antoon Pardon wrote:
> Op 31-03-14 19:40, Ian Kelly schreef:

>> First, because while those may degrade readability, they do
>> so in a constrained way.  A decorator application is just the @ symbol
>> and an identifier.
>
> And if abused, can totally change the working of your function. There
> is no guarantee that the function returned, has any relation with the
> original function. If that can't be a night mare for readability,
> I don't know what is.

This is a matter of the wrapping function, not the decorator syntax 
abbreviation.

@twist_the_function_meaning
def f: return clear_expression

is no worse in this regard than the written out form

def f: return clear_expression
f = twist_the_function_meaning(f)

-- 
Terry Jan Reedy

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

#69447

Terry Reedy <tjreedy@udel.edu>:

> @twist_the_function_meaning
> def f: return clear_expression
>
> is no worse in this regard than the written out form
>
> def f: return clear_expression
> f = twist_the_function_meaning(f)

I don't remember feeling the need for either.

I have written wrappers of all sorts, but somehow that pattern just
feels alien to me so far.


Marko

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

#69456

On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 31-03-14 19:40, Ian Kelly schreef:
>> That was an exaggeration on my part.  It wouldn't affect my job, as I
>> wouldn't expect to ever actually have to maintain anything like the
>> above.  My greater point though is that it damages Python's
>> readability for no actual gain in my view.  There is nothing useful
>> you can do with a name that is the U+1F4A9 character that you can't do
>> just as easily with alphanumeric identifiers like pile_of_poo (or
>> куча_фекалий if one prefers; that's auto-translated, so don't blame me
>> if it's a poor translation). The kinds of symbols that we're talking
>> about here aren't part of any writing systems, and so to incorporate
>> them in *names* as if they were is an abuse of Unicode.
>
> Your argument doesn't has much weight. First of all it can be used
> for just restricting names to the ascii range.

I disagree.  Non-ASCII written names are useful to anybody who prefers
not to do all their programming in English.

> Second of all I
> think a good chosen symbolic name can be more readable than a
> name in a character set you are not familiar with. A good chosen
> symbol will evoke a meaning with a lot of people. A name in a
> character set you are not familiar with is just gibberish to
> you.

Well, this is the path taken by APL.  It has its supporters.  It's not
known for being readable.

>> I don't think the comparisons to decorators and the if-else operator
>> are apt.
>
> I didn't make such a comparison. I just noted the arguments against
> were similar.

That's the comparison to which I was referring.

>> First, because while those may degrade readability, they do
>> so in a constrained way.  A decorator application is just the @ symbol
>> and an identifier.
>
> And if abused, can totally change the working of your function. There
> is no guarantee that the function returned, has any relation with the
> original function. If that can't be a night mare for readability,
> I don't know what is.

As Terry Reedy noted, this has nothing to do with the decorator
syntax, so it isn't much of an argument against having such syntax.

>> The if-else is just three expressions separated by
>> keywords.
>
> Yes but if used unrestrained in arbitrary expressions will make those
> expressions hard to understand.

I don't disagree.  I hardly ever use it myself, certainly only if it
can fit comfortably into one line, which is rare.  But it's still
quite limited in syntactic scope.

>> In the case of arbitrary Unicode identifiers, we're talking
>> about approximately doubling the number of different characters (out
>> of a continuously growing set) that could be used, many of which are
>> easily confused with other characters. Of course the potential for
>> confusion already exists, but that's no justification for aggravating
>> it.
>
> So what if we double the number of different characters? I don't care
> about the number of them, I care about how meaningful they are. And
> as you say confusion is already possible. A good programmer knows
> how to deal with such a possible confusion, that the number of
> cases increases, doesn't need to be a problem for those that care
> about this.

So tell me then, how would you deal with it?  In the case of script
identifiers, it's often not hard to discern from context whether a
particular character is e.g. a Latin h or a Cyrillic һ.  Assuming the
original author wasn't being intentionally obfuscatory, if the rest of
the identifier is Cyrillic then the character is probably also
Cyrillic.  If it's a one-character identifier, then hopefully the rest
of the module is consistent and you can guess from that.  If the
identifier in question is just one symbol though, then you have a lot
less context.

>
>> Second, at least in the case of decorators, while I don't dispute that
>> they can harm readability, I think that in the majority of cases they
>> actually help it.
>
> But that is not a fair comparison now, is it. What you are doing here
> is comparing actual use, to a worst case doom scenario.

I contend that there is no scenario with arbitrary Unicode identifiers
where readability is improved.

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

#69463

[Multipart message — attachments visible in raw view] — view raw

I personally believe that it becomes hard to have even a programming
language overcome cultural learning styles, and programmatic differences,
because of nurture vs nature.

We can all program something which results in a similar return value, but
overcoming the nurturing the internet provides, becomes an imperative.

I'll just offer a reference to avoid personal mistakes in explaining
something that relates to how programmers/computer scientists/electrical
engineers approach their end results, and why those end results may still
differ in the mentality of the individual, or group, outcome of developing
A.I. systems:

http://en.wikipedia.org/wiki/Ethnolinguistics

http://en.wikipedia.org/wiki/Cognitive_anthropology

http://en.wikipedia.org/wiki/Cognitive_science

The latter probably explains what I mean in more depth than the two
formers.


On Mon, Mar 31, 2014 at 8:47 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:

> On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
> > Op 31-03-14 19:40, Ian Kelly schreef:
> >> That was an exaggeration on my part.  It wouldn't affect my job, as I
> >> wouldn't expect to ever actually have to maintain anything like the
> >> above.  My greater point though is that it damages Python's
> >> readability for no actual gain in my view.  There is nothing useful
> >> you can do with a name that is the U+1F4A9 character that you can't do
> >> just as easily with alphanumeric identifiers like pile_of_poo (or
> >> куча_фекалий if one prefers; that's auto-translated, so don't blame me
> >> if it's a poor translation). The kinds of symbols that we're talking
> >> about here aren't part of any writing systems, and so to incorporate
> >> them in *names* as if they were is an abuse of Unicode.
> >
> > Your argument doesn't has much weight. First of all it can be used
> > for just restricting names to the ascii range.
>
> I disagree.  Non-ASCII written names are useful to anybody who prefers
> not to do all their programming in English.
>
> > Second of all I
> > think a good chosen symbolic name can be more readable than a
> > name in a character set you are not familiar with. A good chosen
> > symbol will evoke a meaning with a lot of people. A name in a
> > character set you are not familiar with is just gibberish to
> > you.
>
> Well, this is the path taken by APL.  It has its supporters.  It's not
> known for being readable.
>
> >> I don't think the comparisons to decorators and the if-else operator
> >> are apt.
> >
> > I didn't make such a comparison. I just noted the arguments against
> > were similar.
>
> That's the comparison to which I was referring.
>
> >> First, because while those may degrade readability, they do
> >> so in a constrained way.  A decorator application is just the @ symbol
> >> and an identifier.
> >
> > And if abused, can totally change the working of your function. There
> > is no guarantee that the function returned, has any relation with the
> > original function. If that can't be a night mare for readability,
> > I don't know what is.
>
> As Terry Reedy noted, this has nothing to do with the decorator
> syntax, so it isn't much of an argument against having such syntax.
>
> >> The if-else is just three expressions separated by
> >> keywords.
> >
> > Yes but if used unrestrained in arbitrary expressions will make those
> > expressions hard to understand.
>
> I don't disagree.  I hardly ever use it myself, certainly only if it
> can fit comfortably into one line, which is rare.  But it's still
> quite limited in syntactic scope.
>
> >> In the case of arbitrary Unicode identifiers, we're talking
> >> about approximately doubling the number of different characters (out
> >> of a continuously growing set) that could be used, many of which are
> >> easily confused with other characters. Of course the potential for
> >> confusion already exists, but that's no justification for aggravating
> >> it.
> >
> > So what if we double the number of different characters? I don't care
> > about the number of them, I care about how meaningful they are. And
> > as you say confusion is already possible. A good programmer knows
> > how to deal with such a possible confusion, that the number of
> > cases increases, doesn't need to be a problem for those that care
> > about this.
>
> So tell me then, how would you deal with it?  In the case of script
> identifiers, it's often not hard to discern from context whether a
> particular character is e.g. a Latin h or a Cyrillic һ.  Assuming the
> original author wasn't being intentionally obfuscatory, if the rest of
> the identifier is Cyrillic then the character is probably also
> Cyrillic.  If it's a one-character identifier, then hopefully the rest
> of the module is consistent and you can guess from that.  If the
> identifier in question is just one symbol though, then you have a lot
> less context.
>
> >
> >> Second, at least in the case of decorators, while I don't dispute that
> >> they can harm readability, I think that in the majority of cases they
> >> actually help it.
> >
> > But that is not a fair comparison now, is it. What you are doing here
> > is comparing actual use, to a worst case doom scenario.
>
> I contend that there is no scenario with arbitrary Unicode identifiers
> where readability is improved.
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*

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

#69464

[Multipart message — attachments visible in raw view] — view raw

This brings us into a juxtaposition between how cultures have tried to
hybridize their mentalities, into more of an empathic means of
communication via a formulatic set of coding, and the philosophy thereof,
and, 3D renderings of what we visualize, and how we come to the
conclusions of these philosophies of what we want to accomplish within the
technological age we live within.

Maybe not the best way I could explain it, but it has a bunch of fancy
words in it.

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

#69490

On 01-04-14 02:47, Ian Kelly wrote:
> On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> Op 31-03-14 19:40, Ian Kelly schreef:
>>> That was an exaggeration on my part.  It wouldn't affect my job, as I
>>> wouldn't expect to ever actually have to maintain anything like the
>>> above.  My greater point though is that it damages Python's
>>> readability for no actual gain in my view.  There is nothing useful
>>> you can do with a name that is the U+1F4A9 character that you can't do
>>> just as easily with alphanumeric identifiers like pile_of_poo (or
>>> куча_фекалий if one prefers; that's auto-translated, so don't blame me
>>> if it's a poor translation). The kinds of symbols that we're talking
>>> about here aren't part of any writing systems, and so to incorporate
>>> them in *names* as if they were is an abuse of Unicode.
>> Your argument doesn't has much weight. First of all it can be used
>> for just restricting names to the ascii range.
> I disagree.  Non-ASCII written names are useful to anybody who prefers
> not to do all their programming in English.

Symbols that carry a meaning among different languages are more useful
because they are meaningful to more people and so make the program
readable to more people.
 

>> Second of all I
>> think a good chosen symbolic name can be more readable than a
>> name in a character set you are not familiar with. A good chosen
>> symbol will evoke a meaning with a lot of people. A name in a
>> character set you are not familiar with is just gibberish to
>> you.
> Well, this is the path taken by APL.  It has its supporters.  It's not
> known for being readable.

No that is not the path taken by APL. AFAICS identifiers in APL are just
like identifiers in python. The path taken by APL was that there were
a lot more operators available that used non-alphanumeric characters.

AFICS APL programs tend to be unreadable because they are mostly written
in a very concise style.

I think this is more the path taken by lisp-like languages where '+' is
a name just like 'alpha' or 'r2d2'. In scheme I can just do the following.

(define √ sqrt)
(√ 4)

Which will give me the normal result. Maybe I missed it but I haven't heard
scheme being called an unreadable language.


>>> First, because while those may degrade readability, they do
>>> so in a constrained way.  A decorator application is just the @ symbol
>>> and an identifier.
>> And if abused, can totally change the working of your function. There
>> is no guarantee that the function returned, has any relation with the
>> original function. If that can't be a night mare for readability,
>> I don't know what is.
> As Terry Reedy noted, this has nothing to do with the decorator
> syntax, so it isn't much of an argument against having such syntax.

Point taken.

>>> The if-else is just three expressions separated by
>>> keywords.
>> Yes but if used unrestrained in arbitrary expressions will make those
>> expressions hard to understand.
> I don't disagree.  I hardly ever use it myself, certainly only if it
> can fit comfortably into one line, which is rare.  But it's still
> quite limited in syntactic scope.

Non alphanumeric characters in names is even more limited in syntatic
scope. It doesn't even play at the syntatic level but only at the lexical
level.

 

>> So what if we double the number of different characters? I don't care
>> about the number of them, I care about how meaningful they are. And
>> as you say confusion is already possible. A good programmer knows
>> how to deal with such a possible confusion, that the number of
>> cases increases, doesn't need to be a problem for those that care
>> about this.
> So tell me then, how would you deal with it?  In the case of script
> identifiers, it's often not hard to discern from context whether a
> particular character is e.g. a Latin h or a Cyrillic һ.  Assuming the
> original author wasn't being intentionally obfuscatory, if the rest of
> the identifier is Cyrillic then the character is probably also
> Cyrillic.  If it's a one-character identifier, then hopefully the rest
> of the module is consistent and you can guess from that.  If the
> identifier in question is just one symbol though, then you have a lot
> less context.

I deal with it, just the way I deal with it now. I generally trust the
programmer to know what he is doing and to have done a good faith effort
So that I don't have to worry about him having both a variable 'NO' and 'N0'
I see no reason to be more paranoïd about this just because there are more
possibilities.

> Second, at least in the case of decorators, while I don't dispute that
> they can harm readability, I think that in the majority of cases they
> actually help it.
>> But that is not a fair comparison now, is it. What you are doing here
>> is comparing actual use, to a worst case doom scenario.
> I contend that there is no scenario with arbitrary Unicode identifiers
> where readability is improved.

At this moment I see no reason to just accept this.

-- 
Antoon Pardon

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

#69498

On Tue, Apr 1, 2014 at 2:19 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> On 01-04-14 02:47, Ian Kelly wrote:
>> On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon
>> <antoon.pardon@rece.vub.ac.be> wrote:
>>> Second of all I
>>> think a good chosen symbolic name can be more readable than a
>>> name in a character set you are not familiar with. A good chosen
>>> symbol will evoke a meaning with a lot of people. A name in a
>>> character set you are not familiar with is just gibberish to
>>> you.
>> Well, this is the path taken by APL.  It has its supporters.  It's not
>> known for being readable.
>
> No that is not the path taken by APL. AFAICS identifiers in APL are just
> like identifiers in python. The path taken by APL was that there were
> a lot more operators available that used non-alphanumeric characters.
>
> AFICS APL programs tend to be unreadable because they are mostly written
> in a very concise style.
>
> I think this is more the path taken by lisp-like languages where '+' is
> a name just like 'alpha' or 'r2d2'. In scheme I can just do the following.
>
> (define √ sqrt)
> (√ 4)

You're still using the symbol as the name of an operation, though, so
I see no practical difference from the APL style.  The operation just
happens to be user-defined rather than built-in.  Granted that in
Scheme or in Python-with-arbitrary-Unicode-identifiers you could just
as easily name a variable √, but I don't think that is what you are
proposing in terms of choosing symbols to evoke meaning.

> Which will give me the normal result. Maybe I missed it but I haven't heard
> scheme being called an unreadable language.

Well, I have, but I think that usually has more to do with an excess
of parentheses.

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

#69499

Ian Kelly <ian.g.kelly@gmail.com>:

> On Tue, Apr 1, 2014 at 2:19 AM, Antoon Pardon
>> Which will give me the normal result. Maybe I missed it but I haven't
>> heard scheme being called an unreadable language.
>
> Well, I have, but I think that usually has more to do with an excess
> of parentheses.

If you count braces as parentheses, there are about the same number of
parentheses in scheme and C:

    int main()
    {
        printf("Hello world\n");
        return 0;
    }

    (define (main)
        (format #t "Hello world\n")
        0)

C: 6
Scheme: 6


Marko

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

#69500

On Tue, Apr 1, 2014 at 3:32 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> On Tue, Apr 1, 2014 at 2:19 AM, Antoon Pardon
>>> Which will give me the normal result. Maybe I missed it but I haven't
>>> heard scheme being called an unreadable language.
>>
>> Well, I have, but I think that usually has more to do with an excess
>> of parentheses.
>
> If you count braces as parentheses, there are about the same number of
> parentheses in scheme and C:
>
>     int main()
>     {
>         printf("Hello world\n");
>         return 0;
>     }
>
>     (define (main)
>         (format #t "Hello world\n")
>         0)
>
> C: 6
> Scheme: 6

On the other hand, you recently posted this snippet to the list:

        ((let ((n 3))
           (let ((f (lambda () n)))
             (set! n 7)
             f)))

Setting aside the fact that C doesn't have anonymous functions, I'll
approximate it as best I can:

static int n = 3;

int f()
{
    return n;
}

int main()
{
    n = 7;
    return f();
}

C: 10
Scheme: 20

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

#69505

Ian Kelly <ian.g.kelly@gmail.com>:

> Setting aside the fact that C doesn't have anonymous functions, I'll
> approximate it as best I can:
>
> [...]
>
> C: 10
> Scheme: 20

It is true that scheme needs parentheses for operators and assignments
so the ratio is probably in the order of 2:1. Whether that is excess or
not is a matter of taste.

For example:

========================================================================
#include<stdio.h>
 
int main()
{
   int n, i = 3, count, c;
 
   printf("Enter the number of prime numbers required\n");
   scanf("%d",&n);
 
   if ( n >= 1 )
   {
      printf("First %d prime numbers are :\n",n);
      printf("2\n");
   }
 
   for ( count = 2 ; count <= n ;  )
   {
      for ( c = 2 ; c <= i - 1 ; c++ )
      {
         if ( i%c == 0 )
            break;
      }
      if ( c == i )
      {
         printf("%d\n",i);
         count++;
      }
      i++;
   }
 
   return 0;
}
========================================================================
(<URL: http://www.programmingsimplified.com/c/source-code/
c-program-for-prime-number>)

is rendered in scheme as follows:

========================================================================
(define (main)
  (format #t "Enter the number of prime numbers required\n")
  (let ((n (read)))
    (if (>= n 1)
        (begin
          (format #t "First ~S prime numbers are :\n" n)
          (format #t "2\n")))
    (let display-primes ((count 2) (i 3))
      (if (<= count n)
          (let find-divisor ((c 2))
            (cond
             ((= c i)
              (format #t "~S\n" i)
              (display-primes (1+ count) (1+ i)))
             ((= (remainder i c) 0)
              (display-primes count (1+ i)))
             (else
              (find-divisor (1+ c)))))))))
                      
(main)
========================================================================

The scheme translation has 37 parenthesis pairs, while the C version has
16. Which one is easier on the eye?


Marko

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

#69508

On Tue, Apr 1, 2014 at 11:02 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> ========================================================================
> #include<stdio.h>
>
> int main()
> {
>    int n, i = 3, count, c;
>
>    printf("Enter the number of prime numbers required\n");
>    scanf("%d",&n);
>
>    if ( n >= 1 )
>    {
>       printf("First %d prime numbers are :\n",n);
>       printf("2\n");
>    }
>
>    for ( count = 2 ; count <= n ;  )
>    {
>       for ( c = 2 ; c <= i - 1 ; c++ )
>       {
>          if ( i%c == 0 )
>             break;
>       }
>       if ( c == i )
>       {
>          printf("%d\n",i);
>          count++;
>       }
>       i++;
>    }
>
>    return 0;
> }
> ========================================================================
> (<URL: http://www.programmingsimplified.com/c/source-code/
> c-program-for-prime-number>)

Here's my tweaked version of that:

========================================================================
#include <stdio.h>

int main()
{
   int i = 3, count, factor;

   printf("Enter the number of prime numbers required\n");
   scanf("%d",&count);

   if ( count >= 1 )
   {
      printf("First %d prime numbers are:\n",count);
      printf("2\n");
   }

   while (count > 1)
   {
      /* This is a pretty stupid algorithm */
      for ( factor = 2 ; factor <= i - 1 ; factor++ )
         if ( i%factor == 0 ) break;
      if ( factor == i )
      {
         printf("%d\n",i);
         count--;
      }
      i++;
   }

   return 0;
}
========================================================================

Doesn't change the parenthesis count (other than that I dropped an
unnecessary pair of braces; some people would prefer to keep them, but
I find they're quite superfluous), but improves readability. (Why use
a for loop when you could use a simple while?) As to the question of
whether this is more or less readable than the Scheme version... I
guess that partly depends on the reader's relative familiarity with C
and Scheme, but it's crystal clear to me what the C version is doing -
and that it's doing something stupid. I don't find it more readable to
cast something as recursive; compare these two tight loops:

          (let find-divisor ((c 2))
            (cond
             ((= c i)
              (format #t "~S\n" i)
              (display-primes (1+ count) (1+ i)))
             ((= (remainder i c) 0)
              (display-primes count (1+ i)))
             (else
              (find-divisor (1+ c)))))))))

      for ( factor = 2 ; factor <= i - 1 ; factor++ )
         if ( i%factor == 0 ) break;
      if ( factor == i )
      {
         printf("%d\n",i);
         count--;
      }

In the first one, you start doing something, and if you don't have a
termination point, you recurse - which means you have to name this
loop as a function. In the second, you simply iterate, and then at the
end, decide whether you have the termination condition or not. It's
easy to see what the loop condition is; it's easy to see that it will
always end by one or other termination rule, and then it acts based on
that. Actually, if you switch the conditions, it would look a bit more
like the Scheme version:

      for ( factor = 2 ; i%factor ; factor++ )
      {
        if ( factor == i )
        {
           printf("%d\n",i);
           count--;
           break;
        }
      }

I wouldn't say this makes the code notably more readable, and it
doesn't change the parenthesis count (apart from making more people
want to put the outer braces in - they're still technically optional,
and that was only an optional reduction in the first place), but it's
a closer equivalent and that might make comparison easier.

My view is definitely that the C version is WAY more readable than the
Scheme one.

ChrisA

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

#69511

Chris Angelico <rosuav@gmail.com>:

> I don't find it more readable to cast something as recursive; compare
> these two tight loops:
>
>           (let find-divisor ((c 2))
>             (cond
>              ((= c i)
>               (format #t "~S\n" i)
>               (display-primes (1+ count) (1+ i)))
>              ((= (remainder i c) 0)
>               (display-primes count (1+ i)))
>              (else
>               (find-divisor (1+ c)))))))))
>
>       for ( factor = 2 ; factor <= i - 1 ; factor++ )
>          if ( i%factor == 0 ) break;
>       if ( factor == i )
>       {
>          printf("%d\n",i);
>          count--;
>       }
>
> In the first one, you start doing something, and if you don't have a
> termination point, you recurse - which means you have to name this
> loop as a function. In the second, you simply iterate,

I implemented the loops in the scheme way. Recursion is how iteration is
done by the Believers. Traditional looping structures are available to
scheme, but if you felt the need for them, you might as well program in
Python.

On the other hand, I didn't look for the most elegant implementation
idiom but tried to translate the original rather mechanically--in good
and bad.

> My view is definitely that the C version is WAY more readable than the
> Scheme one.

Yes, scheme is an acquired taste. As is Python. My experienced bash/C
colleague was baffled by some Python idioms (not in my code, I might
add) that looked pretty clear to me.


Marko

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

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

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

csiph-web