Chris Angelico schreef op 17/07/2018 0:48:
On Tue, Jul 17, 2018 at 8:41 AM, Roel Schroeven wrote:
In any case, even though Python 3's byte strings are not quite unlike Python
2's strings, they're not exactly like them either. And I feel there are
cases where that makes things somewhat harder,
On 17/07/18 14:14, Marko Rauhamaa wrote:
Rhodri James :
On 17/07/18 02:17, Steven D'Aprano wrote:
Ah yes, the unfortunate design error that iterating over byte-strings
returns ints rather than single-byte strings.
That decision seemed to make sense at the time it was made, but turned
out to
Marko Rauhamaa wrote:
> The practical issue is how you refer to ASCII bytes. What I've resorted
> to is:
>
> if nxt == b":"[0]:
> ...
You seem to have the compiler's blessing:
>>> def f(c):
... return c == b":"[0]
...
>>> import dis
>>> dis.dis(f)
2 0
Rhodri James :
> On 17/07/18 02:17, Steven D'Aprano wrote:
>> Ah yes, the unfortunate design error that iterating over byte-strings
>> returns ints rather than single-byte strings.
>>
>> That decision seemed to make sense at the time it was made, but turned
>> out to be an annoyance. It's a wart
On 17/07/18 02:17, Steven D'Aprano wrote:
On Mon, 16 Jul 2018 23:50:12 +0200, Roel Schroeven wrote:
There are times (encoding/decoding network protocols and other data
formats) when I have a byte string and I want/need to process it like
Python 2 does, and that is the one area where I feel
On 17/07/18 13:41, Rhodri James wrote:
On 17/07/18 02:52, Python wrote:
On Mon, Jul 16, 2018 at 08:56:11PM +0100, Rhodri James wrote:
The problem everyone is having with you, Marko, is that you are
using the terminology incorrectly. [...] When you call UTF-32 a
variable-width encoding, you are
On 17/07/18 02:52, Python wrote:
On Mon, Jul 16, 2018 at 08:56:11PM +0100, Rhodri James wrote:
The problem everyone is having with you, Marko, is that you are
using the terminology incorrectly. [...] When you call UTF-32 a
variable-width encoding, you are incorrect.
But please don't overlook
On Mon, Jul 16, 2018 at 08:56:11PM +0100, Rhodri James wrote:
> The problem everyone is having with you, Marko, is that you are
> using the terminology incorrectly. [...] When you call UTF-32 a
> variable-width encoding, you are incorrect.
But please don't overlook that the "terminology" is in
On Mon, 16 Jul 2018 23:50:12 +0200, Roel Schroeven wrote:
> There are times (encoding/decoding network protocols and other data
> formats) when I have a byte string and I want/need to process it like
> Python 2 does, and that is the one area where I feel Python 3 make
> things a bit more
On Tue, Jul 17, 2018 at 9:18 AM, Dan Sommers wrote:
> Quick: how long is the byte array that displays as '\xff'? Too easy?
> What about '\0xff' and '0\xff'?
1, 4, 2 bytes respectively. Yep, easy... but then, I'm used to reading
backslash escapes. Nothing to do with text vs bytes.
DNS, of
On Tue, 17 Jul 2018 08:48:55 +1000, Chris Angelico wrote:
> That said, though, the fact that indexing a byte string yields an int
> instead of a one-byte string is basically unable to be changed now ...
Agreed.
> ... and IMO it'd be better to be consistent with text strings than
> with
On Tue, Jul 17, 2018 at 8:41 AM, Roel Schroeven wrote:
> In any case, even though Python 3's byte strings are not quite unlike Python
> 2's strings, they're not exactly like them either. And I feel there are
> cases where that makes things somewhat harder, even though I can't prove it.
You're
Chris Angelico schreef op 16/07/2018 23:57:
On Tue, Jul 17, 2018 at 7:50 AM, Roel Schroeven wrote:
Steven D'Aprano schreef op 16/07/2018 2:18:
On Sun, 15 Jul 2018 16:08:15 -0700, Jim Lee wrote:
Python3 is intrinsically tied to Unicode for string handling. Therefore,
the Python programmer is
On 2018-07-16, Roel Schroeven wrote:
> There are times (encoding/decoding network protocols and other data
> formats) when I have a byte string and I want/need to process it like
> Python 2 does, and that is the one area where I feel Python 3 make
> things a bit more difficult.
I use Python
On Tue, Jul 17, 2018 at 7:50 AM, Roel Schroeven wrote:
> Steven D'Aprano schreef op 16/07/2018 2:18:
>>
>> On Sun, 15 Jul 2018 16:08:15 -0700, Jim Lee wrote:
>>
>>> Python3 is intrinsically tied to Unicode for string handling. Therefore,
>>> the Python programmer is forced to deal with it (in all
Steven D'Aprano schreef op 16/07/2018 2:18:
On Sun, 15 Jul 2018 16:08:15 -0700, Jim Lee wrote:
Python3 is intrinsically tied to Unicode for string handling. Therefore,
the Python programmer is forced to deal with it (in all but trivial
cases), rather than given a choice. So I don't understand
On Tue, Jul 17, 2018 at 6:27 AM, Marko Rauhamaa wrote:
> Rhodri James :
>
>> On 16/07/18 20:40, Marko Rauhamaa wrote:
>>> You mean each code point is one code point wide. But that's rather an
>>> irrelevant thing to state. The main point is that UTF-32 (aka Unicode)
>>> uses one or more code
On Tue, Jul 17, 2018 at 6:36 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Jul 17, 2018 at 5:40 AM, Marko Rauhamaa wrote:
>>> You mean each code point is one code point wide. But that's rather an
>>> irrelevant thing to state. The main point is that UTF-32 (aka
>>> Unicode) uses one
Chris Angelico :
> On Tue, Jul 17, 2018 at 5:40 AM, Marko Rauhamaa wrote:
>> You mean each code point is one code point wide. But that's rather an
>> irrelevant thing to state. The main point is that UTF-32 (aka
>> Unicode) uses one or more code points to represent what people would
>> consider
On 7/16/2018 2:01 PM, Chris Angelico wrote:
【 Stardew Valley Fanart 】*:･ﾟ✧【 800 Subpoints = NEW EMOTE
】#devicat #anime #stardewvalley #fantasy
Just to be clear, 【 】･ﾟ✧【 】,
\U0001f331, \u3010, \u3011, \uff65, \uff9f, \u2727 are the non-ascii
chars in the above.
for c in """【 Stardew
Rhodri James :
> On 16/07/18 20:40, Marko Rauhamaa wrote:
>> You mean each code point is one code point wide. But that's rather an
>> irrelevant thing to state. The main point is that UTF-32 (aka Unicode)
>> uses one or more code points to represent what people would consider an
>> individual
On Tue, Jul 17, 2018 at 5:40 AM, Marko Rauhamaa wrote:
> Terry Reedy :
>
>> On 7/15/2018 5:28 PM, Marko Rauhamaa wrote:
>>> if your new system used Python3's UTF-32 strings as a foundation,
>>
>> Since 3.3, Python's strings are not (always) UFT-32 strings.
>
> You are right. Python's strings are
On 16/07/18 20:40, Marko Rauhamaa wrote:
Terry Reedy:
On 7/15/2018 5:28 PM, Marko Rauhamaa wrote:
if your new system used Python3's UTF-32 strings as a foundation,
Since 3.3, Python's strings are not (always) UFT-32 strings.
You are right. Python's strings are a superset of UTF-32. More
On Tue, Jul 17, 2018 at 5:16 AM, Gene Heskett wrote:
> On Monday 16 July 2018 14:01:54 Chris Angelico wrote:
>
>> On Tue, Jul 17, 2018 at 2:24 AM, Gene Heskett
> wrote:
>> > On Monday 16 July 2018 11:57:25 Chris Angelico wrote:
>> >> On Tue, Jul 17, 2018 at 1:48 AM, Gene Heskett
>> >>
>> >
>> >
Terry Reedy :
> On 7/15/2018 5:28 PM, Marko Rauhamaa wrote:
>> if your new system used Python3's UTF-32 strings as a foundation,
>
> Since 3.3, Python's strings are not (always) UFT-32 strings.
You are right. Python's strings are a superset of UTF-32. More
accurately, Python's strings are UTF-32
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
On Monday 16 July 2018 14:01:54 Chris Angelico wrote:
> On Tue, Jul 17, 2018 at 2:24 AM, Gene Heskett
wrote:
> > On Monday 16 July 2018 11:57:25 Chris Angelico wrote:
> >> On Tue, Jul 17, 2018 at 1:48 AM, Gene Heskett
> >>
> >
> > wrote:
> >> > On Sunday 15 July 2018 16:09:21 Chris Angelico
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
--
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
On 7/15/2018 4:09 PM, Jim Lee wrote:
On 07/15/18 12:37, MRAB wrote:
To me, Unicode and UTF-8 aren't things to be reserved for I18N. I use
them as a matter of course because I find it a lot easier to stick
with just one encoding, one that will work with _any_ text I have.
Which is exactly
On Tue, Jul 17, 2018 at 4:15 AM, Ian Kelly wrote:
> On Mon, Jul 16, 2018 at 12:02 PM Terry Reedy wrote:
>>
>> On 7/15/2018 5:28 PM, Marko Rauhamaa wrote:
>>
>> > if your new system used Python3's UTF-32 strings as a foundation,
>>
>> Since 3.3, Python's strings are not (always) UFT-32 strings.
On Mon, Jul 16, 2018 at 12:02 PM Terry Reedy wrote:
>
> On 7/15/2018 5:28 PM, Marko Rauhamaa wrote:
>
> > if your new system used Python3's UTF-32 strings as a foundation,
>
> Since 3.3, Python's strings are not (always) UFT-32 strings. Nor are
> they always UCS-2 (or partly UTF-16) strings.
On Tue, Jul 17, 2018 at 2:24 AM, Gene Heskett wrote:
> On Monday 16 July 2018 11:57:25 Chris Angelico wrote:
>
>> On Tue, Jul 17, 2018 at 1:48 AM, Gene Heskett
> wrote:
>> > On Sunday 15 July 2018 16:09:21 Chris Angelico wrote:
>> >> On Mon, Jul 16, 2018 at 4:22 AM, James Lee wrote:
>> >> > On
On 7/15/2018 5:28 PM, Marko Rauhamaa wrote:
if your new system used Python3's UTF-32 strings as a foundation,
Since 3.3, Python's strings are not (always) UFT-32 strings. Nor are
they always UCS-2 (or partly UTF-16) strings. Nor are the always
Latin-1 or Ascii strings. Python's Flexible
On 2018-07-16 17:31, Steven D'Aprano wrote:
On Sun, 15 Jul 2018 16:38:41 -0700, Jim Lee wrote:
As I said, there are programming situations where the programmer only
needs to deal with a single language - his own.
This might come as a shock to you, but just because Python's native
string type
On Sun, 15 Jul 2018 16:38:41 -0700, Jim Lee wrote:
> As I said, there are programming situations where the programmer only
> needs to deal with a single language - his own.
This might come as a shock to you, but just because Python's native
string type supports (for example) the Devanagari
On Monday 16 July 2018 11:57:25 Chris Angelico wrote:
> On Tue, Jul 17, 2018 at 1:48 AM, Gene Heskett
wrote:
> > On Sunday 15 July 2018 16:09:21 Chris Angelico wrote:
> >> On Mon, Jul 16, 2018 at 4:22 AM, James Lee wrote:
> >> > On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
> >> >> No. The real
On Tue, Jul 17, 2018 at 1:48 AM, Gene Heskett wrote:
> On Sunday 15 July 2018 16:09:21 Chris Angelico wrote:
>
>> On Mon, Jul 16, 2018 at 4:22 AM, James Lee wrote:
>> > On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
>> >> No. The real ten billion dollar question is how people in 2018 can
>> >>
On Sunday 15 July 2018 16:09:21 Chris Angelico wrote:
> On Mon, Jul 16, 2018 at 4:22 AM, James Lee wrote:
> > On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
> >> No. The real ten billion dollar question is how people in 2018 can
> >> stick their head in the sand and take seriously the position
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
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
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
On 16/07/18 15:20, Ethan Furman wrote:
On 07/16/2018 06:22 AM, Rhodri James wrote:
On 13/07/18 20:46, Ethan Furman wrote:
On 07/13/2018 11:52 AM, Rhodri James wrote:
I should point out that the number of people I have killfiled in all my
> Internet dealings can be counted on the fingers
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
On 07/16/2018 06:22 AM, Rhodri James wrote:
On 13/07/18 20:46, Ethan Furman wrote:
On 07/13/2018 11:52 AM, Rhodri James wrote:
I should point out that the number of people I have killfiled in all my
> Internet dealings can be counted on the fingers of one hand.
Your left one? *
* Bonus
On 13/07/18 20:46, Ethan Furman wrote:
On 07/13/2018 11:52 AM, Rhodri James wrote:
I should point out that the number of people I have killfiled in all my
> Internet dealings can be counted on the fingers of one hand.
Your left one? *
--
~Ethan~
* Bonus points for getting the reference.
On 15-07-18 09:33, Marko Rauhamaa wrote:
> Paul Rubin :
>> Py3's unicode picture is described here and it isn't pretty:
>>
Am 16.07.18 um 03:02 schrieb Jim Lee:
But I don't speak Esperanto, and my programs don't generally care what
characters are used for European currencies. When I create a simple
program that takes a text file (created by me) and munges it into a
different format, I don't care if someone from
On 07/15/18 17:17, MRAB wrote:
On 2018-07-16 00:10, Jim Lee wrote:
On 07/15/18 16:04, Chris Angelico wrote:
You claimed that Unicode was insignificant to many programs. I'm
trying to say that a Unicode text string is a vital part of any
program that works with text, which is pretty much
On 07/15/18 17:18, Steven D'Aprano wrote:
On Sun, 15 Jul 2018 16:08:15 -0700, Jim Lee wrote:
Python3 is intrinsically tied to Unicode for string handling. Therefore,
the Python programmer is forced to deal with it (in all but trivial
cases), rather than given a choice. So I don't understand
On 07/15/18 16:55, Steven D'Aprano wrote:
On Sun, 15 Jul 2018 11:22:11 -0700, James Lee wrote:
On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
No. The real ten billion dollar question is how people in 2018 can
stick their head in the sand and take seriously the position that
Latin-1 (let
On Sun, 15 Jul 2018 16:08:15 -0700, Jim Lee wrote:
> Python3 is intrinsically tied to Unicode for string handling. Therefore,
> the Python programmer is forced to deal with it (in all but trivial
> cases), rather than given a choice. So I don't understand how I can
> illustrate my point with
On Sun, 15 Jul 2018 13:09:59 -0700, Jim Lee wrote:
> On 07/15/18 12:37, MRAB wrote:
>> To me, Unicode and UTF-8 aren't things to be reserved for I18N. I use
>> them as a matter of course because I find it a lot easier to stick with
>> just one encoding, one that will work with _any_ text I have.
On 2018-07-16 00:10, Jim Lee wrote:
On 07/15/18 16:04, Chris Angelico wrote:
You claimed that Unicode was insignificant to many programs. I'm
trying to say that a Unicode text string is a vital part of any
program that works with text, which is pretty much anything that talks
to humans. You
On Sun, 15 Jul 2018 11:22:11 -0700, James Lee wrote:
> On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
>>
>> No. The real ten billion dollar question is how people in 2018 can
>> stick their head in the sand and take seriously the position that
>> Latin-1 (let alone ASCII) is enough for text
On 07/15/18 16:24, Chris Angelico wrote:
That is why this seems obtuse to me. There is no benefit to going to a
pre-Unicode way of working with text.
ChrisA
In a word - simplicity.
As I said, there are programming situations where the programmer only
needs to deal with a single language
On Mon, Jul 16, 2018 at 9:22 AM, Jim Lee wrote:
>
> You've turned my argument upside down by redefine terms mid-stream. Now,
> using Unicode is a "freedom" rather than a restriction. You've also
> introduced a straw-man argument by introducing integers as a parallel
> analogy (which it isn't -
On Mon, Jul 16, 2018 at 9:10 AM, Jim Lee wrote:
>
>
> On 07/15/18 16:04, Chris Angelico wrote:
>>
>>
>> You claimed that Unicode was insignificant to many programs. I'm
>> trying to say that a Unicode text string is a vital part of any
>> program that works with text, which is pretty much
On 07/15/18 16:13, Chris Angelico wrote:
On Mon, Jul 16, 2018 at 9:08 AM, Jim Lee wrote:
On 07/15/18 14:50, Marko Rauhamaa wrote:
Jim Lee :
Yes, and for *that*, language matters; but, for a vast array of
programming tasks that *don't* involve global communications, it's an
added level of
On Mon, Jul 16, 2018 at 9:08 AM, Jim Lee wrote:
>
>
> On 07/15/18 14:50, Marko Rauhamaa wrote:
>>
>> Jim Lee :
>>>
>>> Yes, and for *that*, language matters; but, for a vast array of
>>> programming tasks that *don't* involve global communications, it's an
>>> added level of complexity with zero
On 07/15/18 16:04, Chris Angelico wrote:
You claimed that Unicode was insignificant to many programs. I'm
trying to say that a Unicode text string is a vital part of any
program that works with text, which is pretty much anything that talks
to humans. You keep saying that ... well you keep
On 07/15/18 14:50, Marko Rauhamaa wrote:
Jim Lee :
Yes, and for *that*, language matters; but, for a vast array of
programming tasks that *don't* involve global communications, it's an
added level of complexity with zero benefit. It would be *nice* to be
able to turn support on or off,
On Mon, Jul 16, 2018 at 8:53 AM, Jim Lee wrote:
>
>
> On 07/15/18 15:07, Chris Angelico wrote:
>>
>> On Mon, Jul 16, 2018 at 7:57 AM, Jim Lee wrote:
>>>
>>>
>>> On 07/15/18 14:53, Chris Angelico wrote:
On Mon, Jul 16, 2018 at 7:02 AM, Jim Lee wrote:
>
>
> On 07/15/18
On 07/15/18 15:07, Chris Angelico wrote:
On Mon, Jul 16, 2018 at 7:57 AM, Jim Lee wrote:
On 07/15/18 14:53, Chris Angelico wrote:
On Mon, Jul 16, 2018 at 7:02 AM, Jim Lee wrote:
On 07/15/18 13:30, Chris Angelico wrote:
It doesn't matter what Twitch is, except for the fact that it is
On Mon, Jul 16, 2018 at 7:57 AM, Jim Lee wrote:
>
>
> On 07/15/18 14:53, Chris Angelico wrote:
>>
>> On Mon, Jul 16, 2018 at 7:02 AM, Jim Lee wrote:
>>>
>>>
>>> On 07/15/18 13:30, Chris Angelico wrote:
It doesn't matter what Twitch is, except for the fact that it is a
On 07/15/18 14:53, Chris Angelico wrote:
On Mon, Jul 16, 2018 at 7:02 AM, Jim Lee wrote:
On 07/15/18 13:30, Chris Angelico wrote:
It doesn't matter what Twitch is, except for the fact that it is a
platform for HUMANS to communicate with HUMANS. Ultimately, that is
what matters. Pick any
Jim Lee :
> Yes, and for *that*, language matters; but, for a vast array of
> programming tasks that *don't* involve global communications, it's an
> added level of complexity with zero benefit. It would be *nice* to be
> able to turn support on or off, depending on the requirements of the
>
On Mon, Jul 16, 2018 at 7:02 AM, Jim Lee wrote:
>
>
> On 07/15/18 13:30, Chris Angelico wrote:
>>
>>
>> It doesn't matter what Twitch is, except for the fact that it is a
>> platform for HUMANS to communicate with HUMANS. Ultimately, that is
>> what matters. Pick any other web site or
On 07/15/18 13:30, Chris Angelico wrote:
It doesn't matter what Twitch is, except for the fact that it is a
platform for HUMANS to communicate with HUMANS. Ultimately, that is
what matters. Pick any other web site or communication protocol you
please.
ChrisA
Yes, and for *that*, language
Terry Reedy :
> On 7/15/2018 7:37 AM, Marko Rauhamaa wrote:
>> One of the classic Unix and Internet tenets is that text is bytes is
>> text.
>
> Tenets of a faith may be wrong ;-). An informatic paradigm from more
> than 45 years ago may be outdated and in need of revision.
>
> [...]
>
>> Of
Ed Kellett :
> So, Marko, I don't know what code you work on, but I think it's unfair
> to attack Python 3's unicode handling too hard if you haven't written
> a new project with it.
I don't believe the problem was solely in the difficulty of conversion.
It was primarily in the tricky (and
On Mon, Jul 16, 2018 at 6:09 AM, Jim Lee wrote:
>
>
> On 07/15/18 12:37, MRAB wrote:
>>
>> To me, Unicode and UTF-8 aren't things to be reserved for I18N. I use them
>> as a matter of course because I find it a lot easier to stick with just one
>> encoding, one that will work with _any_ text I
On Mon, Jul 16, 2018 at 6:06 AM, Terry Reedy wrote:
> On 7/15/2018 7:37 AM, Marko Rauhamaa wrote:
>
>> One of the classic Unix and Internet tenets is that text is bytes is
>> text.
>
>
> Tenets of a faith may be wrong ;-). An informatic paradigm from more than
> 45 years ago may be outdated and
On 07/15/18 13:09, Chris Angelico wrote:
On Mon, Jul 16, 2018 at 4:22 AM, James Lee wrote:
On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
No. The real ten billion dollar question is how people in 2018 can stick
their head in the sand and take seriously the position that Latin-1 (let
alone
On 07/15/18 12:37, MRAB wrote:
To me, Unicode and UTF-8 aren't things to be reserved for I18N. I use
them as a matter of course because I find it a lot easier to stick
with just one encoding, one that will work with _any_ text I have.
Which is exactly the same rationale for using any other
On Mon, Jul 16, 2018 at 4:22 AM, James Lee wrote:
>
>
> On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
>>
>>
>> No. The real ten billion dollar question is how people in 2018 can stick
>> their head in the sand and take seriously the position that Latin-1 (let
>> alone ASCII) is enough for text
On 7/15/2018 7:37 AM, Marko Rauhamaa wrote:
One of the classic Unix and Internet tenets is that text is bytes is
text.
Tenets of a faith may be wrong ;-). An informatic paradigm from more
than 45 years ago may be outdated and in need of revision.
On byte storage and on the Internet,
On 2018-07-15 19:22, James Lee wrote:
On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
No. The real ten billion dollar question is how people in 2018 can stick
their head in the sand and take seriously the position that Latin-1 (let
alone ASCII) is enough for text strings.
Easy - for many
On 07/14/2018 07:40 PM, Chris Angelico wrote:
> You'd better avoid most of JavaScript, C++, and most other languages,
> then. Every language feeps a little, and Python is definitely not as
> bad as some.
Point Of Order: C++ is one gigantic feep to be avoided at all costs... :)
--
On 7/15/2018 3:43 AM, Steven D'Aprano wrote:
No. The real ten billion dollar question is how people in 2018 can stick
their head in the sand and take seriously the position that Latin-1 (let
alone ASCII) is enough for text strings.
Easy - for many people, 90% of the Python code they
On 2018-07-15 15:52, Steven D'Aprano wrote:
> On Sun, 15 Jul 2018 14:17:51 +0300, Marko Rauhamaa wrote:
>
>> Steven D'Aprano :
>>
>>> On Sun, 15 Jul 2018 11:43:14 +0300, Marko Rauhamaa wrote:
Paul Rubin :
> I don't think Go is the answer either, but it probably got strings
> right.
@ChrisAngelico
don't know [replying to your message but addressing to all]
i respect you all, i respect your involvement, i doubt not your py skills
but can you please stay on topic and be concise
i value all posts here and try to read them all as they are all serious
stuffs but when you mix in
should have switched treads from here
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
>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
@MarkLawrence
this i fell compelled to reply.
no name issue. fork with features intended meaning python is open source,
you want to add as many feature as you want np, just like a user modifies a
script. you just need to master c and compiler theory and it becomes easy
or add like a "plugin"
On Sun, 15 Jul 2018 14:17:51 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Sun, 15 Jul 2018 11:43:14 +0300, Marko Rauhamaa wrote:
>>> Paul Rubin :
I don't think Go is the answer either, but it probably got strings
right. What is the answer?
>>
>> Go strings aren't text
On 15/07/18 07:35, Abdur-Rahmaan Janhangeer wrote:
@GregoryEwing
maybe another word for pep revocation is fork
All ready been tried and failed with Python as the PSF holds the rights
to the name, so you have to call it something else.
--
My fellow Pythonistas, ask not what our language can
Chris Angelico :
> On Sun, Jul 15, 2018 at 9:17 PM, Marko Rauhamaa wrote:
> Remind me how it's such a mistake to treat that string as text all the
> way through?
Many times you need to make tricky ontological conversion decisions when
all you should need to do is relay the information.
>
On Sun, Jul 15, 2018 at 9:17 PM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>> - to have a language where text strings are a second-class
>> data type, not available in the language itself, only in
>> the libraries;
>
> Unicode code point strings *ought* to be a second--class data type. They
>
Steven D'Aprano :
> On Sun, 15 Jul 2018 11:39:40 +0300, Marko Rauhamaa wrote:
> Armin seems to be implying that Unix is (1) the only OS in the world,
> and (2) beyond criticism.
If Unix is your world, of course you can criticize how badly Python3
performs in that world.
> Neither of these are
Steven D'Aprano :
> On Sun, 15 Jul 2018 11:43:14 +0300, Marko Rauhamaa wrote:
>> Paul Rubin :
>>> I don't think Go is the answer either, but it probably got strings
>>> right. What is the answer?
>
> Go strings aren't text strings. They're byte strings. When you say that
> Go got them right,
On Sun, 15 Jul 2018 11:39:40 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Of course we have no idea what Marko's software is, or what it is
>> doing,
>
> Correct, you don't, but the link Paul Rubin posted gives you an idea:
>
>Python 3 says: everything is Unicode (by default,
On Sun, 15 Jul 2018 11:43:14 +0300, Marko Rauhamaa wrote:
> Paul Rubin :
>
>> Marko Rauhamaa writes:
>>> I have similar feelings, except that I'm not convinced Go is the
>>> answer.
>>
>> I don't think Go is the answer either, but it probably got strings
>> right. What is the answer?
Go
Abdur-Rahmaan Janhangeer wrote:
maybe another word for pep revocation is fork
No, anyone can fork Python whenever they want, no discussion
required, without affecting Python itself.
Revoking a PEP would mean removing its implementation from
the main CPython repository.
--
Greg
--
Paul Rubin :
> Marko Rauhamaa writes:
>> I have similar feelings, except that I'm not convinced Go is the answer.
>
> I don't think Go is the answer either, but it probably got strings
> right. What is the answer?
That's the ten-billion-dollar question, isn't it?!
Marko
--
Steven D'Aprano :
> Of course we have no idea what Marko's software is, or what it is doing,
Correct, you don't, but the link Paul Rubin posted gives you an idea:
Python 3 says: everything is Unicode (by default, except in certain
situations, and except if we send you crazy reencoded
Paul Rubin :
> Py3's unicode picture is described here and it isn't pretty:
> http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
>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
@GregoryEwing
maybe another word for pep revocation is fork
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
--
https://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
If you see the historical absence
of an assignment operator in Python as a mistake, then the introduction
of := is a fix for the mistake that only happened because people kept
complaining.
That's not quite the same thing. There was no a PEP saying
that there would never be
On Sat, 14 Jul 2018 22:54:52 +0300, Marko Rauhamaa wrote:
> Ah, that's called "shunning," isn't it?
No, shunning is when people simply stop responding to those they don't
approve of, turn their back on them in the street, and refuse to
acknowledge their existence in any way.
--
Steven
On Sun, Jul 15, 2018 at 12:55 PM, Steven D'Aprano
wrote:
> On Sun, 15 Jul 2018 09:07:17 +1000, Chris Angelico wrote:
>
>> On Sun, Jul 15, 2018 at 8:15 AM, Marko Rauhamaa
>> wrote:
>>> Chris Angelico :
>>>
On Sun, Jul 15, 2018 at 5:54 AM, Marko Rauhamaa
wrote:
> True enough.
1 - 100 of 144 matches
Mail list logo
