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

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

A Freudian slip of *EPIC PROPORTIONS*!

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

Contents

  A Freudian slip of *EPIC PROPORTIONS*! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-13 15:11 -0800
    Re: A Freudian slip of *EPIC PROPORTIONS*! Chris Angelico <rosuav@gmail.com> - 2014-11-14 10:35 +1100
    Re: A Freudian slip of *EPIC PROPORTIONS*! Terry Reedy <tjreedy@udel.edu> - 2014-11-13 19:34 -0500
      Re: A Freudian slip of *EPIC PROPORTIONS*! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 23:28 +1100
        Re: A Freudian slip of *EPIC PROPORTIONS*! Terry Reedy <tjreedy@udel.edu> - 2014-11-15 15:12 -0500
    Re: A Freudian slip of *EPIC PROPORTIONS*! KO <KO@example.org> - 2014-11-14 08:25 +0000
      Re: A Freudian slip of *EPIC PROPORTIONS*! wxjmfauth@gmail.com - 2014-11-14 01:57 -0800

#80711 — A Freudian slip of *EPIC PROPORTIONS*!

Some of the folks on this list have attempted to shame me
for not accepting "with open arms", this vile encoding we call
Unicode, but i wonder, are they aware of the deepest held
beliefs of our very own leader?

The other day whilst perusing the idlelib i came across a
small but *very* significant line of code. They say a picture
is worth a thousand words, well folks, this one short line of
code might cause *ANY* picture blush with envy!

The line is as follows:

    uniphooey = str
    
However, without some context, even the more "astute"
readers might miss the connection, so allow me to offer the
comment that precedes this line:

    # The parse functions have no idea what to do with
    # Unicode, so replace all Unicode characters with "x".
    # This is "safe" so long as the only characters germane
    # to parsing the structure of Python are 7-bit ASCII.
    # It's *necessary* because Unicode strings don't have a
    # .translate() method that supports deletechars.
    
We can obviously intuit that "uni" is short for "unicode",
and by attaching "phooey" to unicode the author is making a
public statement that he believes "unicode is phooey". But
what does "phooey" actually mean? The Merriam Webster online
dictionary defines "phooey" as:

    PHOOEY: used to express disbelief, disappointment, or a
    strong dislike for something.

So now it is blatantly obvious that the author of PyParse
does not care for unicode, and from my recollection, it was
the great GvR himself that wrote most, if not all, of the code
for IDLE and Tkinter.

Now that this revelation has seen the light of day, i wonder
just how "far apart" myself and the great one might actually
be on this unicode business?

On the other hand, if the author is not GvR, then he is most
likely someone of great importance within the community. In
any event, i believe it is high time that the author explain
his intentions when using the word "uniphooey", because
using any word should not be a crime, but hiding in the
shadows whilst a fellow member is being lynched, and not
having the balls to stand up and speak of your deeply held
beliefs *IS* the highest of all crimes! It is a betrayal of
not only your peers, but also of yourself. 

[toc] | [next] | [standalone]

#80720

On Fri, Nov 14, 2014 at 10:11 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>     # The parse functions have no idea what to do with
>     # Unicode, so replace all Unicode characters with "x".
>     # This is "safe" so long as the only characters germane
>     # to parsing the structure of Python are 7-bit ASCII.
>     # It's *necessary* because Unicode strings don't have a
>     # .translate() method that supports deletechars.

Sounds to me like the functions that collapse whitespace to single
spaces, or turn all letters into "A" and all digits into "9", or
lowercase/casefold all alphabetics, or strip diacriticals, or anything
else of that nature. It's often simpler to fold equivalencies together
before parsing or comparing strings. It doesn't mean you don't respect
Unicode; in fact, it proves that you *do*.

So if you stop calling Unicode "vile", you might actually learn something.

ChrisA

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

#80733

On 11/13/2014 6:11 PM, Rick Johnson wrote:

>      # The parse functions have no idea what to do with
>      # Unicode, so replace all Unicode characters with "x".
>      # This is "safe" so long as the only characters germane
>      # to parsing the structure of Python are 7-bit ASCII.
>      # It's *necessary* because Unicode strings don't have a
>      # .translate() method that supports deletechars.
>      uniphooey = str

It is customary to attribute quotes to their source.  This is from 2.x 
Lib/idlelib/PyParse.py.  The file was committed (and probably written) 
by David Scherer 2000-08-15.  Edits for unicode, including the above, 
were committed (and perhaps written) by Kurt B. Kaiser on 2001-07-13.

I doubt GvR ever saw this code.  I expect KBK has changed opinions with 
respect to unicode in 13 years, as has most everyone else.

-- 
Terry Jan Reedy

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

#80821

Terry Reedy wrote:

> On 11/13/2014 6:11 PM, Rick Johnson wrote:
> 
>>      # The parse functions have no idea what to do with
>>      # Unicode, so replace all Unicode characters with "x".
>>      # This is "safe" so long as the only characters germane
>>      # to parsing the structure of Python are 7-bit ASCII.
>>      # It's *necessary* because Unicode strings don't have a
>>      # .translate() method that supports deletechars.
>>      uniphooey = str
> 
> It is customary to attribute quotes to their source.  This is from 2.x
> Lib/idlelib/PyParse.py.  The file was committed (and probably written)
> by David Scherer 2000-08-15.  Edits for unicode, including the above,
> were committed (and perhaps written) by Kurt B. Kaiser on 2001-07-13.

Correct.

The line in question was written by Kurt. We can find this out by using 
the hg annotate command. Change into the Lib/idlelib directory of the 
source repository, then use hg annotate command as follows:


[steve@ando idlelib]$ hg annotate PyParse.py | grep phoo
42050:             uniphooey = s
18555:             for raw in map(ord, uniphooey):

The numbers shown on the left are the revision IDs, so look at the 
older of the two:

[steve@ando idlelib]$ hg annotate -r 18555 PyParse.py | grep phoo
18555:             uniphooey = str
18555:             for raw in map(ord, uniphooey):

We can confirm that prior to that revision, the uniphooey lines 
didn't exist:

[steve@ando idlelib]$ hg annotate -r 18554 PyParse.py | grep phoo
<no output>


And then find out who is responsible:

[steve@ando idlelib]$ hg annotate -uvd -r 18555 PyParse.py | grep phoo
  Kurt B. Kaiser <kbk@shore.net> Fri Jul 13 20:33:46 2001 +0000:             uniphooey = str
  Kurt B. Kaiser <kbk@shore.net> Fri Jul 13 20:33:46 2001 +0000:             for raw in map(ord, uniphooey):


> I doubt GvR ever saw this code.  I expect KBK has changed opinions with
> respect to unicode in 13 years, as has most everyone else.

We don't know Kurt's intention with regard to the name, the "phooey" 
could refer to:

- the parse functions failing to understand Unicode;
- it being a nasty hack that assumes that Python will never use 
  Unicode characters for keywords or operators;
- it being necessary because u''.translate fails to support
  a deletechars parameter.


It's unlikely to refer to the Unicode character set itself.



-- 
Steven

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

#80838

On 11/15/2014 7:28 AM, Steven D'Aprano wrote:
> Terry Reedy wrote:
>
>> On 11/13/2014 6:11 PM, Rick Johnson wrote:
>>
>>>       # The parse functions have no idea what to do with
>>>       # Unicode, so replace all Unicode characters with "x".
>>>       # This is "safe" so long as the only characters germane
>>>       # to parsing the structure of Python are 7-bit ASCII.
>>>       # It's *necessary* because Unicode strings don't have a
>>>       # .translate() method that supports deletechars.
>>>       uniphooey = str
>>
>> It is customary to attribute quotes to their source.  This is from 2.x
>> Lib/idlelib/PyParse.py.  The file was committed (and probably written)
>> by David Scherer 2000-08-15.  Edits for unicode, including the above,
>> were committed (and perhaps written) by Kurt B. Kaiser on 2001-07-13.
>
> Correct.
>
> The line in question was written by Kurt. We can find this out by using
> the hg annotate command. Change into the Lib/idlelib directory of the
> source repository, then use hg annotate command as follows:
>
>
> [steve@ando idlelib]$ hg annotate PyParse.py | grep phoo
> 42050:             uniphooey = s
> 18555:             for raw in map(ord, uniphooey):
>
> The numbers shown on the left are the revision IDs, so look at the
> older of the two:
>
> [steve@ando idlelib]$ hg annotate -r 18555 PyParse.py | grep phoo
> 18555:             uniphooey = str
> 18555:             for raw in map(ord, uniphooey):
>
> We can confirm that prior to that revision, the uniphooey lines
> didn't exist:
>
> [steve@ando idlelib]$ hg annotate -r 18554 PyParse.py | grep phoo
> <no output>
>
>
> And then find out who is responsible:
>
> [steve@ando idlelib]$ hg annotate -uvd -r 18555 PyParse.py | grep phoo
>    Kurt B. Kaiser <kbk@shore.net> Fri Jul 13 20:33:46 2001 +0000:             uniphooey = str
>    Kurt B. Kaiser <kbk@shore.net> Fri Jul 13 20:33:46 2001 +0000:             for raw in map(ord, uniphooey):

On windows, with TortoiseHg installed, I right-clicked PyParse in 
Explorer and selected TortoiseHg on the context menu and Annotate on the 
submenu.  This pops up a Window with two linked panels --  a list of 
revisions and an annotated file listing with lines added or changed by 
the current revision marked a different background color.  I found the 
comment block easily enough, looked at the annotation, and looked back 
at the revision list.  Clicking on a revision changes the file listing. 
  On can easily march through the history of the file.

>> I doubt GvR ever saw this code.  I expect KBK has changed opinions with
>> respect to unicode in 13 years, as has most everyone else.

Including mine.

> We don't know Kurt's intention with regard to the name, the "phooey"
> could refer to:
>
> - the parse functions failing to understand Unicode;
> - it being a nasty hack that assumes that Python will never use
>    Unicode characters for keywords or operators;
> - it being necessary because u''.translate fails to support
>    a deletechars parameter.

I expect I would have been annoyed when a new-fangled feature,
elsewhere in Python, broke one of the files I was working on.
Now, of course, I would know to not use a variable name that
could be misinterpreted by someone years in the future.

> It's unlikely to refer to the Unicode character set itself.


-- 
Terry Jan Reedy

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

#80749

On 2014-11-13, Rick Johnson <rantingrickjohnson@gmail.com> wrote:

> On the other hand, if the author is not GvR, then he is most
> likely someone of great importance within the community.


As much as I love Python, I hate the amount of appeal to authority
that is present in the Python community.
Ok, GvR created Python, great.
He is extremely smart and knowledgable, no doubt.
But that doesn't make him right on everything.
That doesn't mean his opinion on something makes it True or False.

Gooosh.


-- 
ko

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

#80751

_________

The Python devs are not understanding Unicode.
(I saw it once more yesterday).

jmf

[toc] | [prev] | [standalone]

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

csiph-web