Python, Unicode, utf-16, utf-32.

For those of you who share my extremely dry sense of humour you might like to take a look at this https://groups.google.com/forum/#!topic/comp.lang.python/-58lTkBBZU4. I've not shared directly as it's the latest from the RUE. Apparantly Python 3 is the buggiest ever, despite the huge build in

Re: Well, I finally ran into a Python Unicode problem, sort of

BartC : > Usually anything that is defined can be changed at run-time so that the > compiler can never assume anything. The compiler can't assume anything permanent, but it could heuristically make excellent guesses at runtime. It needs to verify its guesses at the boundaries of compiled code and

Re: Well, I finally ran into a Python Unicode problem, sort of

On 04/07/2016 15:46, Ned Batchelder wrote: On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote: On 04/07/2016 13:47, Ned Batchelder wrote: This is a huge change. I've used a kind of 'weak' import scheme elsewhere, corresponding to C's '#include'. I think that could work in Python p

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote: > On 04/07/2016 13:47, Ned Batchelder wrote: > > On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote: > >> On 04/07/2016 03:30, Steven D'Aprano wrote: > > >>> You're still having problems with the whole Python-as-a-dynamic-language >

Re: Well, I finally ran into a Python Unicode problem, sort of

On 04/07/2016 13:47, Ned Batchelder wrote: On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote: On 04/07/2016 03:30, Steven D'Aprano wrote: You're still having problems with the whole Python-as-a-dynamic-language thing, aren't you? :-) Most Pythons seem to pre-compile code before exec

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote: > On 04/07/2016 03:30, Steven D'Aprano wrote: > > On Mon, 4 Jul 2016 10:17 am, BartC wrote: > > > >> On 04/07/2016 01:00, Lawrence D’Oliveiro wrote: > >>> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: > Python lacks a m

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 3:56:43 PM UTC+5:30, BartC wrote: > On 04/07/2016 02:15, Lawrence D’Oliveiro wrote: > > On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote: > >> The structure of such a parser doesn't need to exactly match the grammar > >> with a dedicated block of code for each o

Re: Well, I finally ran into a Python Unicode problem, sort of

BartC writes: > A simpler approach is to treat user-defined operators as aliases for > functions: > > def myadd(a,b): > return a+b > > operator ∇: >(myadd,2,+3) # map to myadd, 2 operands, prio 3, LTR > > x = y ∇ z > > is then equivalent to: > > x = myadd(y,z) > > However you will usua

Re: Well, I finally ran into a Python Unicode problem, sort of

On 04/07/2016 02:15, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote: The structure of such a parser doesn't need to exactly match the grammar with a dedicated block of code for each operator precedence. It can be table-driven so that an operator precedence

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence D’Oliveiro writes: > On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote: >> Something could be done, but if the intention is to allow >> mathematical notation, it needs to be done with care. > > Mathematics uses single-character variable names so that > multiplication c

Re: Well, I finally ran into a Python Unicode problem, sort of

On 04/07/2016 03:30, Steven D'Aprano wrote: On Mon, 4 Jul 2016 10:17 am, BartC wrote: On 04/07/2016 01:00, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: Python lacks a mechanism to add user-defined operators. (R has this capability.) Maybe this feat

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence D’Oliveiro : > Mathematics uses single-character variable names so that > multiplication can be implicit. I don't think anybody developed mathematical notation systematically. Rather, over the centuries, various masters came up with personal abbreviations and shorthand, which spread amon

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote: > Something could be done, but if the intention is to allow > mathematical notation, it needs to be done with care. Mathematics uses single-character variable names so that multiplication can be implicit. An old, stillborn la

Re: Well, I finally ran into a Python Unicode problem, sort of

Rustom Mody writes: > Subscripts OTOH as part of identifier-lexemes doesn't seem to have any > issues They have the general issue that one might *want* them interpreted as indexes, so that a₁ would mean the same as a[1]. Mathematical symbols face similar issues. One would not *want* them all be

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 8:03:47 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 4 Jul 2016 07:28 am, Lawrence D’Oliveiro wrote: > > > On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote: > >> Here's another worm for the can. Would you rather read this... > >> > >> d = sqrt(x**2 + y

Re: Well, I finally ran into a Python Unicode problem, sort of

On Mon, 4 Jul 2016 07:28 am, Lawrence D’Oliveiro wrote: > On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote: >> Here's another worm for the can. Would you rather read this... >> >> d = sqrt(x**2 + y**2) >> >> ...or this? >> >> d = √(x² + y²) > > Neither. I would rather see > >

Re: Well, I finally ran into a Python Unicode problem, sort of

On Mon, 4 Jul 2016 10:17 am, BartC wrote: > On 04/07/2016 01:00, Lawrence D’Oliveiro wrote: >> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: >>> Python lacks a mechanism to add user-defined operators. (R has this >>> capability.) Maybe this feature could be added. >> >> That would

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016, at 21:15, Lawrence D’Oliveiro wrote: > On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote: > > The structure of such a parser doesn't need to exactly match the grammar > > with a dedicated block of code for each operator precedence. It can be > > table-driven so that

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016, at 20:00, Lawrence D’Oliveiro wrote: > That would be neat. But remember, you would have to define the operator > precedence as well. So you could no longer use a recursive-descent > parser. You could use a recursive-descent parser if you monkey-patch the parser when adding a n

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote: > The structure of such a parser doesn't need to exactly match the grammar > with a dedicated block of code for each operator precedence. It can be > table-driven so that an operator precedence value is just an attribute. Of course. But

Re: Well, I finally ran into a Python Unicode problem, sort of

On 04/07/2016 01:24, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 12:17:47 PM UTC+12, BartC wrote: On 04/07/2016 01:00, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: Python lacks a mechanism to add user-defined operators. (R has this capa

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 12:17:47 PM UTC+12, BartC wrote: > > On 04/07/2016 01:00, Lawrence D’Oliveiro wrote: >> >> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: >>> >>> Python lacks a mechanism to add user-defined operators. (R has this >>> capability.) Maybe this feature could

Re: Well, I finally ran into a Python Unicode problem, sort of

On 04/07/2016 01:00, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: Python lacks a mechanism to add user-defined operators. (R has this capability.) Maybe this feature could be added. That would be neat. But remember, you would have to define the oper

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote: > Python lacks a mechanism to add user-defined operators. (R has this > capability.) Maybe this feature could be added. That would be neat. But remember, you would have to define the operator precedence as well. So you could no longer

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016 at 6:58 AM, John Ladasky wrote: > The nabla symbol (∇) is used in the naming of gradients. Python isn't having > it. > The interpreter throws a "SyntaxError: invalid character in identifier" when > it > encounters the ∇. Del is a mathematical operator to take the gradient. I

Re: Well, I finally ran into a Python Unicode problem, sort of

On Monday, July 4, 2016 at 6:39:45 AM UTC+12, John Ladasky wrote: > Here's another worm for the can. Would you rather read this... > > d = sqrt(x**2 + y**2) > > ...or this? > > d = √(x² + y²) Neither. I would rather see d = math.hypot(x, y) Much simpler, don’t you think? -- https://mail

Re: Well, I finally ran into a Python Unicode problem, sort of

Random832 : > Being able to put any character in a symbol doesn't make those strings > identifiers, any more than passing them to getattr/setattr (or > __import__, something's __name__, etc) does in Python. From R7RS, the newest Scheme standard (p. 61-62): 7.1.1. Lexical structure [...

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 11:50:52 PM UTC+12, BartC wrote: > Otherwise you can be looking at: > >a b c d e f g h > > (not Scheme) and wondering which are names and which are operators. I did a language design for my MSc thesis where all “functions” were operators. So a construct like “f(a,

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 9:02:05 PM UTC+12, Marko Rauhamaa wrote: > Lawrence D’Oliveiro: > >> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote: >> >>> Personally, I don't think even π should be used in identifiers. >> > > Why not? > > 1. It can't be typed easily. I have a cus

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016, at 07:22, Marko Rauhamaa wrote: > Christian Gollwitzer : > > Am 03.07.16 um 13:01 schrieb Marko Rauhamaa: > >> Scheme allows *any* characters whatsoever in identifiers. > > > > Parentheses? > > Yes. > > Hint: Python allows *any* characters whatsoever in strings. Being able t

Re: Well, I finally ran into a Python Unicode problem, sort of

On 2016-07-03 19:39, John Ladasky wrote: On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote: On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote: Very good question! The detaily answer is here: https://docs.python.org/3/reference/lexical_analysis.html#identifiers > A philosop

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote: > On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote: > Very good question! The detaily answer is here: > > https://docs.python.org/3/reference/lexical_analysis.html#identifiers > > > A philosophical question. Why should any ch

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence, I trust you understand that I didn't post a complete working program, just a few lines showing the intended usage? -- https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016 at 7:01 PM, Marko Rauhamaa wrote: > Lawrence D’Oliveiro : > >> On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote: >> >>> Personally, I don't think even π should be used in identifiers. >> >> Why not? > > 1. It can't be typed easily. > > 2. It can look like an n

Re: Well, I finally ran into a Python Unicode problem, sort of

Christian Gollwitzer : > Am 03.07.16 um 13:22 schrieb Marko Rauhamaa: >> Christian Gollwitzer : >>> Am 03.07.16 um 13:01 schrieb Marko Rauhamaa: Scheme allows *any* characters whatsoever in identifiers. >>> Parentheses? >> Yes. > > My knowledge of Scheme is rusty. How do you do that? More

Re: Well, I finally ran into a Python Unicode problem, sort of

Am 03.07.16 um 13:22 schrieb Marko Rauhamaa: Christian Gollwitzer : Am 03.07.16 um 13:01 schrieb Marko Rauhamaa: Alain Ketterlin : It would be very confusing to have a variable named ∇f, as confusing as naming a variable a+b or √x. Scheme allows *any* characters whatsoever in identifiers.

Re: Well, I finally ran into a Python Unicode problem, sort of

On 03/07/2016 12:01, Marko Rauhamaa wrote: Alain Ketterlin : It would be very confusing to have a variable named ∇f, as confusing as naming a variable a+b or √x. Scheme allows *any* characters whatsoever in identifiers. I think it's one of those languages that has already dispensed with mos

Re: Well, I finally ran into a Python Unicode problem, sort of

Christian Gollwitzer : > Am 03.07.16 um 13:01 schrieb Marko Rauhamaa: >> Alain Ketterlin : >> >>> It would be very confusing to have a variable named ∇f, as confusing >>> as naming a variable a+b or √x. >> >> Scheme allows *any* characters whatsoever in identifiers. > > Parentheses? Yes. Hint: P

Re: Well, I finally ran into a Python Unicode problem, sort of

Am 03.07.16 um 13:01 schrieb Marko Rauhamaa: Alain Ketterlin : It would be very confusing to have a variable named ∇f, as confusing as naming a variable a+b or √x. Scheme allows *any* characters whatsoever in identifiers. Parentheses? Christian -- https://mail.python.org/mailman/l

Re: Well, I finally ran into a Python Unicode problem, sort of

Alain Ketterlin : > It would be very confusing to have a variable named ∇f, as confusing > as naming a variable a+b or √x. Scheme allows *any* characters whatsoever in identifiers. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

John Ladasky writes: > from math import pi as π > [...] > c = 2 * π * r > Up until today, every character I've tried has been accepted by the > Python interpreter as a legitimate character for inclusion in a > variable name. Now I'm copying a formula which defines a gradient. The > nabla symbol

Re: Well, I finally ran into a Python Unicode problem, sort of

On 2016-07-03 08:29, Jussi Piitulainen wrote: (Hm. Python seems to understand that the character occurs in what is intended to be an identifier. Perhaps that's a default error message.) I suspect that "identifier" is the final catch-all token in the lexer. Comments and strings are clearly deli

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence D’Oliveiro : > On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote: > >> Personally, I don't think even π should be used in identifiers. > > Why not? 1. It can't be typed easily. 2. It can look like an n. 3. Single-character identifiers should not be promoted, especially

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 7:27:04 PM UTC+12, Marko Rauhamaa wrote: > Personally, I don't think even π should be used in identifiers. Why not? Python already has all the other single-character constants in what probably the most fundamental identity in all of mathematics: $$e^{i \pi} + 1 =

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote: > Up until today, every character I've tried has been accepted by the Python > interpreter as a legitimate character for inclusion in a variable name. Now > I'm copying a formula which defines a gradient. The nabla symbol (∇) is used > in th

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 12:29:14 PM UTC+5:30, John Ladasky wrote: > A while back, I shared my love for using Greek letters as variable names in > my Python (3.4) code -- when, and only when, they are warranted for improved > readability. For example, I like to see the following: > > > from

Re: Well, I finally ran into a Python Unicode problem, sort of

Lawrence D’Oliveiro : > It wasn’t the “π” it was complaining about... The question is why π is accepted but ∇ is not. The immediate reason is that π is a letter while ∇ is not. But the question, then, is why bother excluding nonletters from identifiers. Personally, I don't think even π should b

Re: Well, I finally ran into a Python Unicode problem, sort of

John Ladasky writes: [- -] > The nabla symbol (∇) is used in the naming of gradients. Python isn't > having it. The interpreter throws a "SyntaxError: invalid character > in identifier" when it encounters the ∇. > > I am now wondering what constitutes a valid character for an > identifier, and

Re: Well, I finally ran into a Python Unicode problem, sort of

On Sunday, July 3, 2016 at 6:59:14 PM UTC+12, John Ladasky wrote: > from math import pi as π > > c = 2 * π * r ldo@theon:~> python3 Python 3.5.1+ (default, Jun 10 2016, 09:03:40) [GCC 5.4.0 20160603] on linux Type "help", "copyright", "credits" or "license" for more information.

Well, I finally ran into a Python Unicode problem, sort of

A while back, I shared my love for using Greek letters as variable names in my Python (3.4) code -- when, and only when, they are warranted for improved readability. For example, I like to see the following: from math import pi as π c = 2 * π * r When I am copying mathematical formulas from

Re: Python Unicode handling wins again -- mostly

On 2013-12-04, wxjmfa...@gmail.com wrote: > Yon intuitively pointed a very important feature of "unicode". > However, it is not necessary, this is exactly what unicode does > (when used properly). Unicode only provides character sets. It's not a natural language parsing facility. -- Neil Cerutt

Re: Python Unicode handling wins again -- mostly

On 04/12/2013 13:52, wxjmfa...@gmail.com wrote: [snip all the double spaced stuff] Yon intuitively pointed a very important feature of "unicode". However, it is not necessary, this is exactly what unicode does (when used properly). jmf Presumably using unicode correctly prevents messages b

Re: Python Unicode handling wins again -- mostly

Le mardi 3 décembre 2013 15:26:45 UTC+1, Ethan Furman a écrit : > On 12/02/2013 12:38 PM, Ethan Furman wrote: > > > On 11/29/2013 04:44 PM, Steven D'Aprano wrote: > > >> > > >> Out of the nine tests, Python 3.3 passes six, with three tests being > > >> failures or dubious. If you believe that t

Re: Python Unicode handling wins again -- mostly

Le mardi 3 décembre 2013 06:06:26 UTC+1, Steven D'Aprano a écrit : > On Mon, 02 Dec 2013 16:14:13 -0500, Ned Batchelder wrote: > > > > > On 12/2/13 3:38 PM, Ethan Furman wrote: > > >> On 11/29/2013 04:44 PM, Steven D'Aprano wrote: > > >>> > > >>> Out of the nine tests, Python 3.3 passes six,

Re: Python Unicode handling wins again -- mostly

On 12/02/2013 12:38 PM, Ethan Furman wrote: On 11/29/2013 04:44 PM, Steven D'Aprano wrote: Out of the nine tests, Python 3.3 passes six, with three tests being failures or dubious. If you believe that the native string type should operate on code-points, then you'll think that Python does the r

Re: Python Unicode handling wins again -- mostly

On 2013-12-02, Ethan Furman wrote: > On 11/29/2013 04:44 PM, Steven D'Aprano wrote: >> Out of the nine tests, Python 3.3 passes six, with three tests >> being failures or dubious. If you believe that the native >> string type should operate on code-points, then you'll think >> that Python does the

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 03/12/2013 01:38, Roy Smith wrote: In article , Mark Lawrence wrote: My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. "I believe that Pythonistas should commit themselves to achieving the goal, before this decade is out, of making Py

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 03/12/2013 04:32, Grant Edwards wrote: On 2013-12-03, Roy Smith wrote: "I believe that Pythonistas should commit themselves to achieving the goal, before this decade is out, of making Python 3 the default version and having everybody be cool with unicode." I'm cool with Unicode as long as

Re: Python Unicode handling wins again -- mostly

How would a grapheme library work? Basic cluster combination, or would implementing other algorithms (line break, normalizing to a "canonical" form) be necessary? How do people use grapheme clusters in non-rendering situations? Or here's perhaps here's a better question: does anyone know any non-l

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On Tue, 03 Dec 2013 04:32:13 +, Grant Edwards wrote: > On 2013-12-03, Roy Smith wrote: > >> "I believe that Pythonistas should commit themselves to achieving the >> goal, before this decade is out, of making Python 3 the default version >> and having everybody be cool with unicode." > > I'm

Re: Python Unicode handling wins again -- mostly

On Mon, 02 Dec 2013 16:14:13 -0500, Ned Batchelder wrote: > On 12/2/13 3:38 PM, Ethan Furman wrote: >> On 11/29/2013 04:44 PM, Steven D'Aprano wrote: >>> >>> Out of the nine tests, Python 3.3 passes six, with three tests being >>> failures or dubious. If you believe that the native string type sho

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 12/02/2013 07:22 PM, Terry Reedy wrote: On 12/2/2013 4:25 PM, Ethan Furman wrote: jmf is certainly a troll No, he is a person who discovered a minor performance regression in the FSR, which we fixed. Unfortunately, he then continued for a year with a strange troll-like anti-FSR crusade. Bu

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 2013-12-03, Roy Smith wrote: > "I believe that Pythonistas should commit themselves to achieving the > goal, before this decade is out, of making Python 3 the default version > and having everybody be cool with unicode." I'm cool with Unicode as long as it "just works" without me ever havin

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 12/2/2013 4:25 PM, Ethan Furman wrote: jmf is certainly a troll No, he is a person who discovered a minor performance regression in the FSR, which we fixed. Unfortunately, he then continued for a year with a strange troll-like anti-FSR crusade. But his posts in the Unicode handling thread

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

In article , Mark Lawrence wrote: > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. "I believe that Pythonistas should commit themselves to achieving the goal, before this decade is out, of making Python 3 the default version and havin

Re: Python Unicode handling wins again -- mostly

On 12/02/2013 02:32 PM, Mark Lawrence wrote: ... the other being a pot smoking hippy who ... Please trim your posts. You comment a lot on people sending double-spaced google posts -- not trimming is nearly as bad. The above is a good example of unnecessary name calling. I value your good p

Re: Python Unicode handling wins again -- mostly

Ned Batchelder writes: > This is where my knowledge about Unicode gets fuzzy. Isn't it the > case that some grapheme clusters (or whatever the right word is) can't > be normalized down to a single code point? Characters can accept many > accents, for example. That's true, but doesn't affect th

Re: Python Unicode handling wins again -- mostly

On 12/2/13 5:32 PM, Mark Lawrence wrote: On 02/12/2013 22:24, Ned Batchelder wrote: On 12/2/13 4:44 PM, Ned Batchelder wrote: On 12/2/13 3:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I c

Re: Python Unicode handling wins again -- mostly

On 02/12/2013 22:24, Ned Batchelder wrote: On 12/2/13 4:44 PM, Ned Batchelder wrote: On 12/2/13 3:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal att

Re: Python Unicode handling wins again -- mostly

On 12/2/13 4:44 PM, Ned Batchelder wrote: On 12/2/13 3:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation of t

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 12/2/13 4:25 PM, Ethan Furman wrote: On 12/02/2013 12:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation of

Re: Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 02/12/2013 21:25, Ethan Furman wrote: On 12/02/2013 12:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation o

Re: Python Unicode handling wins again -- mostly

On 12/02/2013 01:23 PM, Chris Angelico wrote: On Tue, Dec 3, 2013 at 8:14 AM, Ned Batchelder wrote: This is where my knowledge about Unicode gets fuzzy. Isn't it the case that some grapheme clusters (or whatever the right word is) can't be normalized down to a single code point? Characters ca

Code of Conduct, Trolls, and Thankless Jobs [was Re: Python Unicode handling wins again -- mostly]

On 12/02/2013 12:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation of the PSF Code of Conduct, which *does* ap

Re: Python Unicode handling wins again -- mostly

On 12/2/13 3:45 PM, Mark Lawrence wrote: On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation of the PSF Code of Conduct, which *does* apply

Re: Python Unicode handling wins again -- mostly

On 02/12/2013 21:14, Ned Batchelder wrote: On 12/2/13 3:38 PM, Ethan Furman wrote: On 11/29/2013 04:44 PM, Steven D'Aprano wrote: Out of the nine tests, Python 3.3 passes six, with three tests being failures or dubious. If you believe that the native string type should operate on code-points,

Re: Python Unicode handling wins again -- mostly

On Tue, Dec 3, 2013 at 8:14 AM, Ned Batchelder wrote: > This is where my knowledge about Unicode gets fuzzy. Isn't it the case that > some grapheme clusters (or whatever the right word is) can't be normalized > down to a single code point? Characters can accept many accents, for > example. You

Re: Python Unicode handling wins again -- mostly

On 12/2/13 3:38 PM, Ethan Furman wrote: On 11/29/2013 04:44 PM, Steven D'Aprano wrote: Out of the nine tests, Python 3.3 passes six, with three tests being failures or dubious. If you believe that the native string type should operate on code-points, then you'll think that Python does the right

Re: Python Unicode handling wins again -- mostly

On 11/29/2013 04:44 PM, Steven D'Aprano wrote: Out of the nine tests, Python 3.3 passes six, with three tests being failures or dubious. If you believe that the native string type should operate on code-points, then you'll think that Python does the right thing. I think Python is doing it corr

Re: Python Unicode handling wins again -- mostly

On 02/12/2013 20:26, Terry Reedy wrote: On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation of the PSF Code of Conduct, which *does* apply to python-list. Please stop. The attack

Re: Python Unicode handling wins again -- mostly

On 12/2/2013 10:45 AM, Mark Lawrence wrote: the worst loser in the world Mark, I consider your continual direct personal attacks on other posters to be a violation of the PSF Code of Conduct, which *does* apply to python-list. Please stop. -- Terry Jan Reedy, one of multiple list moderator

Re: Python Unicode handling wins again -- mostly

On 12/2/13 10:45 AM, Mark Lawrence wrote: On 02/12/2013 15:22, Ned Batchelder wrote: On 12/2/13 9:46 AM, Mark Lawrence wrote: On 02/12/2013 12:39, wxjmfa...@gmail.com wrote: My English is far too be perfect, I think I understood it correctly. PS I did not even speak about the FSR. 1) Your

Re: Python Unicode handling wins again -- mostly

On Tue, Dec 3, 2013 at 2:45 AM, Mark Lawrence wrote: > He's quite deliberately dragged it up by using p.s. Without doubt he's the > worst loser in the world and I'm *NOT* stopping getting at him. I find his > behaviour, continuously and groundlessly insulting the Python core > developers, quite

Re: Python Unicode handling wins again -- mostly

On 02/12/2013 15:22, Ned Batchelder wrote: On 12/2/13 9:46 AM, Mark Lawrence wrote: On 02/12/2013 12:39, wxjmfa...@gmail.com wrote: My English is far too be perfect, I think I understood it correctly. PS I did not even speak about the FSR. 1) Your English is far from perfect as you clearly

Re: Python Unicode handling wins again -- mostly

On 12/2/13 9:46 AM, Mark Lawrence wrote: On 02/12/2013 12:39, wxjmfa...@gmail.com wrote: My English is far too be perfect, I think I understood it correctly. PS I did not even speak about the FSR. 1) Your English is far from perfect as you clearly do not understand the repeated requests *NO

Re: Python Unicode handling wins again -- mostly

On 02/12/2013 12:39, wxjmfa...@gmail.com wrote: My English is far too be perfect, I think I understood it correctly. PS I did not even speak about the FSR. 1) Your English is far from perfect as you clearly do not understand the repeated requests *NOT* to send us double spaced crap via goog

Re: Python Unicode handling wins again -- mostly

Le dimanche 1 décembre 2013 21:54:48 UTC+1, Tim Delaney a écrit : > On 2 December 2013 07:15, wrote: > > > 0.11.13 02:44, Steven D'Aprano написав(ла): > > > > (2) If you reverse that string, does it give "lëon"? The implication of > > > this question is that strings should operate on graphem

Re: Python Unicode handling wins again -- mostly

On 01/12/2013 22:50, Ethan Furman wrote: On 12/01/2013 02:06 PM, Mark Lawrence wrote: I don't remember him [jmf] ever having a valid point, so FTR can we have a reference please. I do remember Steven D'Aprano showing that there was a regression which I flagged up here http://bugs.python.org/is

Re: Python Unicode handling wins again -- mostly

On 12/01/2013 02:06 PM, Mark Lawrence wrote: I don't remember him [jmf] ever having a valid point, so FTR can we have a reference please. I do remember Steven D'Aprano showing that there was a regression which I flagged up here http://bugs.python.org/issue16061. It was fixed by Serhiy Storch

Re: Python Unicode handling wins again -- mostly

On 01/12/2013 22:29, Tim Delaney wrote: On 2 December 2013 09:06, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote: I don't remember him ever having a valid point, so FTR can we have a reference please. I do remember Steven D'Aprano showing that there was a regression which I fl

Re: Python Unicode handling wins again -- mostly

On 2 December 2013 09:06, Mark Lawrence wrote: > I don't remember him ever having a valid point, so FTR can we have a > reference please. I do remember Steven D'Aprano showing that there was a > regression which I flagged up here http://bugs.python.org/issue16061. It > was fixed by Serhiy Storc

Re: Python Unicode handling wins again -- mostly

On 01/12/2013 20:54, Tim Delaney wrote: On 2 December 2013 07:15, mailto:wxjmfa...@gmail.com>> wrote: 0.11.13 02:44, Steven D'Aprano написав(ла): > (2) If you reverse that string, does it give "lëon"? The implication of > this question is that strings should operate on grapheme

Re: Python Unicode handling wins again -- mostly

On 2 December 2013 07:15, wrote: > 0.11.13 02:44, Steven D'Aprano написав(ла): > > (2) If you reverse that string, does it give "lëon"? The implication of > > this question is that strings should operate on grapheme clusters rather > > than code points. ... > > > > BTW, a grapheme cluster *is* a

Re: Python Unicode handling wins again -- mostly

0.11.13 02:44, Steven D'Aprano написав(ла): > (2) If you reverse that string, does it give "lëon"? The implication of > this question is that strings should operate on grapheme clusters rather > than code points. ... > BTW, a grapheme cluster *is* a code points cluster. jmf -- https://mail.pyth

Re: Python Unicode handling wins again -- mostly

30.11.13 02:44, Steven D'Aprano написав(ла): (2) If you reverse that string, does it give "lëon"? The implication of this question is that strings should operate on grapheme clusters rather than code points. Python fails this test: py> print("noe\u0308l"[::-1]) leon >>> print(unicodedata.norma

Re: Python Unicode handling wins again -- mostly

Le dimanche 1 décembre 2013 00:07:36 UTC+1, Ned Batchelder a écrit : > On 11/30/13 5:37 PM, Gregory Ewing wrote: > > > wxjmfa...@gmail.com wrote: > > >> And do you know the origin of this typographical feature? > > >> Because, mechanically, the dot of the "i" broke too often. > > >> > > >> In

Re: Python Unicode handling wins again -- mostly

On Sun, Dec 1, 2013 at 12:27 PM, Roy Smith wrote: >> http://www.theregister.co.uk/2010/11/26/bofh_2010_episode_18/ >> >> ChrisA > > What means "PFY"? The only thing I can think of is "Poor F---ing > Yankee" :-) In the context of the BOFH, it stands for Pimply-Faced Youth and means BOFH's assista

Re: Python Unicode handling wins again -- mostly

In article , Chris Angelico wrote: > On Sun, Dec 1, 2013 at 11:54 AM, Steven D'Aprano > wrote: > > On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > > > >> On 2013-12-01 00:22, Steven D'Aprano wrote: > >>> * KELVIN SIGN versus LATIN CAPITAL LETTER A > >> > >> I should hope so ;-) > > > > >

Re: Python Unicode handling wins again -- mostly

On Sun, Dec 1, 2013 at 11:54 AM, Steven D'Aprano wrote: > On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > >> On 2013-12-01 00:22, Steven D'Aprano wrote: >>> * KELVIN SIGN versus LATIN CAPITAL LETTER A >> >> I should hope so ;-) > > > I blame my keyboard, where letters A and K are practicall

Re: Python Unicode handling wins again -- mostly

On 2013-12-01 00:54, Steven D'Aprano wrote: > On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > > > On 2013-12-01 00:22, Steven D'Aprano wrote: > >> * KELVIN SIGN versus LATIN CAPITAL LETTER A > > > > I should hope so ;-) > > > I blame my keyboard, where letters A and K are practical

  1   2   3   >