Python was designed (was Re: Multi-threading in Python vs Java)

[wxjmfauth at gmail.com]

Le mardi 15 octobre 2013 23:00:29 UTC+2, Mark Lawrence a écrit :
> On 15/10/2013 21:11, wxjmfauth at gmail.com wrote:
> 
> > Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :
> 
> >
> 
> > ----
> 
> >
> 
> > [...]
> 
> >>
> 
> >>      No, Python went through the usual design screwups.  Look at how
> 
> >>
> 
> >> painful the slow transition to Unicode was, from just "str" to
> 
> >>
> 
> >> Unicode strings, ASCII strings, byte strings, byte arrays,
> 
> >>
> 
> >> 16 and 31 bit character builds, and finally automatic switching
> 
> >>
> 
> >> between rune widths. [...]
> 
> >
> 
> >
> 
> > Yes, a real disaster.
> 
> >
> 
> > This "poor" Python is spending its time in reencoding
> 
> > when necessary, without counting the fact it's necessary to
> 
> > check if reencoding is needed.
> 
> >
> 
> > Where is Unicode? Away.
> 
> >

Use one of the coding schemes endorsed by Unicode.

If a dev is not able to see a non ascii char may use 10
bytes more than an ascii char or a dev is not able to
see there may be a regression of a factor 1, 2, 3, 5 or
more simply by using non ascii char, I really do not see
now I can help.

Neither I can force people to understand unicode.

I recieved a ton a private emails, even from core
devs, and as one wrote, this has not been seriously
tested. Even today on the misc. lists some people
are suggesting to write to add more tests.

All the tools I'm aware of, are using unicode very
smoothly (even "utf-8 tools"), Python not.

That's the status. This FSR fails. Period.

jmf