Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Gene Heskett]

On Monday 16 July 2018 15:04:53 Terry Reedy wrote:

> On 7/16/2018 10:54 AM, Gene Heskett wrote:
> > On Monday 16 July 2018 10:24:28 Marko Rauhamaa wrote:
> >> Plus the bytes syntax is really ugly. I wish Python3 had reserved
> >> '...' for byte strings and "..." for UTF-32 strings.
>
> Aside from the fact that Python3 strings are not UTF-32 strings,
> this would have broken all the code that used '' and ""
> interchangeably and prohibited such conveniences as "In formal
> English, do not use don't, isn't, and ain't."
>
> >  From a lurker, that does sound usefull. The next PEP maybe?
>
> I hope you are joking or teasing Marko.
>
I wasn't, but obviously didn't consider the ramifications of that on 
existing programs. My bad. I note that it also elicited a strong defense 
of the status quo. Expected though, given the tone of this list over the 
last year or so.  So I'll go back to lurking. :) I am here to learn. If 
I can...

> --
> Terry Jan Reedy



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Terry Reedy]

On 7/16/2018 11:50 AM, Dennis Lee Bieber wrote:


For Python 4000 maybe


Please don't give people the idea that there is any current intention to 
have a 'Python 4000' similar to 'Python 3000'.  Call it 'a mythical 
Python 4000', if you must use such a term.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Terry Reedy]

On 7/16/2018 10:54 AM, Gene Heskett wrote:

On Monday 16 July 2018 10:24:28 Marko Rauhamaa wrote:



Plus the bytes syntax is really ugly. I wish Python3 had reserved
'...' for byte strings and "..." for UTF-32 strings.


Aside from the fact that Python3 strings are not UTF-32 strings,
this would have broken all the code that used '' and "" interchangeably 
and prohibited such conveniences as "In formal English, do not use 
don't, isn't, and ain't."



 From a lurker, that does sound usefull. The next PEP maybe?


I hope you are joking or teasing Marko.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Chris Angelico]

On Tue, Jul 17, 2018 at 12:54 AM, Gene Heskett  wrote:
> On Monday 16 July 2018 10:24:28 Marko Rauhamaa wrote:
>
>> Antoon Pardon :
>> > I really don't understand why the author of that article didn't just
>> > copy his python2 program but used sys.stdin.buffer and
>> > sys.sydout.buffer instead of plain sys.stdin and stdout.
>>
>> Yes, it would be nice if you could simply restrict yourself to bytes
>> everywhere when your application needed it. Unfortunately, quite many
>> facilities demand text, and you will need to ponder carefully at each
>> such place how you deal with encoding/decoding exceptions.
>>
>> Plus the bytes syntax is really ugly. I wish Python3 had reserved
>> '...' for byte strings and "..." for UTF-32 strings.
>
> From a lurker, that does sound usefull. The next PEP maybe?

Definitely not. Mainly, this is a massive break of backward
compatibility; but even aside from that, I am NOT a fan of having
multiple string types with sneakily different meanings. Let's look at
a few other languages where the quote type changes the meaning:

* C and its direct derivatives: "string", 'c' 'h' 'a' 'r'. Completely
different (a character is an integer).

* JavaScript: "string", 'string', `formatted string`. Annoyingly
similar. Hard to do anything else though.

* SQL: 'string', "identifier", `broken MySQL identifier`. Constantly
tripping people up.

* Bourne shell: 'literal string', "interpolated string". Periodically
annoys people who "use quoted strings like this!"

All of them cause confusion, frequently. I think the C example causes
the least confusion, due to it being so completely different (you
can't write 'Hello, world' because that's too long for a string, and
C's static typing system is strong enough to catch most bugs of this
nature fairly quickly); all the others cause frequent problems. In
JavaScript's case, I kinda feel for the ECMAScript people in that they
wanted to add the feature but didn't really have any good options (JS
doesn't have string prefixes the way Python does), but it still causes
confusion; a backtick string in JS can span multiple lines, but the
others can't, so sometimes backticks are used even without
interpolation, and it's confusing. With SQL's different quoting types,
MySQL decided to go and violate the standard by making double quotes
into strings, but that just introduced even MORE confusion, rather
than solving anything. And shell scripting... well, if anyone truly
understands all the quoting and interpolation rules in bash, I would
be terrified of how many marbles that person has lost.

Python 2 had backticks meaning something completely different from
string literals. Starting with 3.0, backticks are explicitly excluded
from syntax, and the only way a quote character changes the string is
that three of them means you can span lines. Let's keep it simple.
Prefixes are there for a reason.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Gene Heskett]

On Monday 16 July 2018 10:24:28 Marko Rauhamaa wrote:

> Antoon Pardon :
> > I really don't understand why the author of that article didn't just
> > copy his python2 program but used sys.stdin.buffer and
> > sys.sydout.buffer instead of plain sys.stdin and stdout.
>
> Yes, it would be nice if you could simply restrict yourself to bytes
> everywhere when your application needed it. Unfortunately, quite many
> facilities demand text, and you will need to ponder carefully at each
> such place how you deal with encoding/decoding exceptions.
>
> Plus the bytes syntax is really ugly. I wish Python3 had reserved
> '...' for byte strings and "..." for UTF-32 strings.

>From a lurker, that does sound usefull. The next PEP maybe?

> And just look at this:
>
>AUTH_REQ = base64.b64encode(
>("\0{}\0{}".format(USERNAME,
> PASSWORD)).encode("latin1")).decode( "latin1")
>
> versus (Python2):
>
>AUTH_REQ = "\0{}\0{}".format(USERNAME, PASSWORD).encode("base64")
>
>
> Marko



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Antoon Pardon]

On 16-07-18 16:24, Marko Rauhamaa wrote:
> Antoon Pardon :
>
>> I really don't understand why the author of that article didn't just
>> copy his python2 program but used sys.stdin.buffer and
>> sys.sydout.buffer instead of plain sys.stdin and stdout.
> Yes, it would be nice if you could simply restrict yourself to bytes
> everywhere when your application needed it. Unfortunately, quite many
> facilities demand text, and you will need to ponder carefully at each
> such place how you deal with encoding/decoding exceptions.

And in what way is the python3 string type part of the problem with that?

I don't really understand your point here. You refered to an article
where someone seemed to be having trouble because he used a text-interface
while he wanted to treat things as bytes and this would somehow show
how python3 unicode was trouble some.

So I remarked that the problem IMO was using the wrong interface and now
you come with a different kind of situation, but I still don't see python3
big string problems being illustrated.

> Plus the bytes syntax is really ugly. I wish Python3 had reserved '...'
> for byte strings and "..." for UTF-32 strings.
>
> And just look at this:
>
>AUTH_REQ = base64.b64encode(
>("\0{}\0{}".format(USERNAME, PASSWORD)).encode("latin1")).decode(
>"latin1")
>
> versus (Python2):
>
>AUTH_REQ = "\0{}\0{}".format(USERNAME, PASSWORD).encode("base64")

Well this may be somewhat annoying but it hardly seems to illustrate a big 
problem.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Marko Rauhamaa]

Antoon Pardon :

> I really don't understand why the author of that article didn't just
> copy his python2 program but used sys.stdin.buffer and
> sys.sydout.buffer instead of plain sys.stdin and stdout.

Yes, it would be nice if you could simply restrict yourself to bytes
everywhere when your application needed it. Unfortunately, quite many
facilities demand text, and you will need to ponder carefully at each
such place how you deal with encoding/decoding exceptions.

Plus the bytes syntax is really ugly. I wish Python3 had reserved '...'
for byte strings and "..." for UTF-32 strings.

And just look at this:

   AUTH_REQ = base64.b64encode(
   ("\0{}\0{}".format(USERNAME, PASSWORD)).encode("latin1")).decode(
   "latin1")

versus (Python2):

   AUTH_REQ = "\0{}\0{}".format(USERNAME, PASSWORD).encode("base64")


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [SUSPICIOUS MESSAGE] Re: Cult-like behaviour [was Re: Kindness]

[Antoon Pardon]

On 15-07-18 09:33, Marko Rauhamaa wrote:
> Paul Rubin :
>> Py3's unicode picture is described here and it isn't pretty:
>> http://secure-web.cisco.com/1IcToGhkZqGKNSVqMv5ljEo0GVPh0uuAPgKzSBMCkoNElVbHgu4uHpyfdyIj8PrqISD2JssJJnw1yWSFp13DBGOiCdp_Mk9wI4ph_RJ63PeRB_HErunPFzgNvsDR5SDgVe66MmpAG7A4O1NO-NKKjf_5KwnmaAxd5FK89NvKf06tU6H_UmjMt8uYj4487Hc4WDmMhewkSSC86Bu6Eh9Ga_yuzYAMuTpiEftZb30M3pMdyhhTCVGK0KGz4kGPFkgGhaN2hGrNfjYZTdo-CUDcWPw/http%3A%2F%2Flucumr.pocoo.org%2F2014%2F5%2F12%2Feverything-about-unicode%2F
> From the link:
>
>The much more likely thing to happen is that people stick to Python 2
>or build broken stuff on Python 3. Or they go with Go. Which uses an
>even simpler model than Python 2: everything is a byte string. The
>assumed encoding is UTF-8. End of the story.
>
> I have similar feelings, except that I'm not convinced Go is the answer.

I really don't understand why the author of that article didn't just copy
his python2 program but used sys.stdin.buffer and sys.sydout.buffer instead
of plain sys.stdin and stdout.

AFAIU that would have worked like he wanted to, since it would have copied
bytes just as he wanted to. I have searched for an explanation for why
that wouldn't have worked and didn't find it.

-- 
Antoon.

-- 
https://mail.python.org/mailman/listinfo/python-list