Re: [Python-3000] Support for PEP 3131

On 6/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 6/2/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote: > > # identifier_charset: 0-7f > > Why not ASCII? > Why not be more specific, with 0x30-0x39, 0x41-0x5a, 0x5f, 0x61-0x7a > > When adding characters, this isn't such a problem. When restricting >

Re: [Python-3000] Lines breaking

Jim Jewett writes: > Even then, I don't think we *need* to do it. Unicode generally allows > tailoring (so long as you specify), and the entirety of chapter 5 > (Implementation Guidelines) is explicitly non-normative. "Non-normative" in this case means you can claim Unicode conformance withou

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

(sorry about replying to so old mail, but I didn't find a better place to put this) On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > All identifiers are converted into the normal form NFC while parsing; Actually, shouldn't the whole file be converted to NFC, instead of only identifiers?

Re: [Python-3000] Support for PEP 3131

Rauli Ruohonen writes: > He did not say that such files or command-line options would be > scalable either. They are fine tools for auditing, but not for using > finished products. One should provide both auditing tools and ease > of use of already audited code. Ease of use of audited code is

Re: [Python-3000] Support for PEP 3131

Josiah Carlson writes: > And as stated by basically everyone, the only *sane* default is ascii > identifiers. That's a misrepresentation. I prefer the full range of PEP 3131 as the default for use by consenting adults. But you should have the right to unilaterally refuse to grant that consent

Re: [Python-3000] Support for PEP 3131

On 6/3/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Merely to define those is non-trivial, and it is absolutely out > of the question to expect that the average Python user will know > what the character set "strictly-conforms-to-UTR39-restrictions- > allows-confusables" is. This is a bit

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

>> All identifiers are converted into the normal form NFC while parsing; > > Actually, shouldn't the whole file be converted to NFC, instead of > only identifiers? If you have decomposable characters in strings and > your editor decides to normalize them to a different form than in the > original

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

On 6/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Sure - but how can Python tell whether a non-normalized string was > intentionally put into the source, or as a side effect of the editor > modifying it? It can't, but does it really need to? It could always assume the latter. > In most ca

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

Rauli Ruohonen schrieb: > This is only almost true. Consider these two hypothetical files > written by naive newbies: > > data.py: > > favorite_colors = {'Martin Löwis': 'blue'} > > code.py: > > import data > > print data.favorite_colors['Martin Löwis'] That is an unrealistic example. It's mo

[Python-3000] Substantial rewrite of PEP 3101

I've rewritten large portions of PEP 3101, incorporating some material from Patrick Maupin and Eric Smith, as well as rethinking the whole custom formatter design as I discussed earlier. Although it isn't showing up on the web site yet, you can view the copy in subversion (and the diffs) here:

Re: [Python-3000] Support for PEP 3131

--- Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Perhaps, but there is a growing contingent here that > are of the opposite > opinion. And even though this contingent is of > differing opinions on > whether unicode identifiers should even be allowed, > we all agree that if > they are allowed, t

[Python-3000] example Python code under PEP 3131?

There has been a lot of interesting debate about PEP 3131, but I think some perspective could be brought to the table by showing actual code examples. Can somebody post a few examples of what Python code would look like under PEP 3131? Maybe 10-to-15 line programs that illustrate the following us

Re: [Python-3000] Support for PEP 3131

On 6/2/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I'm unsure whether there are cases where > the standard BIDI algorithm would produce incorrect results; Yes, but I'm not sure any of those cases are appropriate for programming language identifers. Quoting from introduction to Unicode Ann

[Python-3000] example Python code under PEP 3131?

Steve Howell writes: > 2) Japanese student using Japanese identifiers and > English reserved words (re, search, match, print, > etc.). I don't have time to cook up something in Python, but I can give an example of working code in Lisp:

[Python-3000] Conservative Defaults (was: Re: Support for PEP 3131)

On 6/2/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote: > and the whole issue of defaults is quite minor. I disagree; the defaults are the most important issue. Those most eager for unicode identifiers are afraid that people (particularly beginning students) won't be able to use local-script identi

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

Rauli Ruohonen writes: > On 6/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Sure - but how can Python tell whether a non-normalized string was > > intentionally put into the source, or as a side effect of the editor > > modifying it? > > It can't, but does it really need to? It cou

Re: [Python-3000] Conservative Defaults (was: Re: Support for PEP 3131)

> Those most eager for unicode identifiers are afraid that people > (particularly beginning students) won't be able to use local-script > identifiers, unless it is the default. My feeling is that the teacher > (or the person who pointed them to python) can change the default on a > per-install bas

Re: [Python-3000] Conservative Defaults (was: Re: Support for PEP 3131)

--- BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > Those most eager for unicode identifiers are > afraid that people > > (particularly beginning students) won't be able to > use local-script > > identifiers, unless it is the default. My feeling > is that the teacher > > (or the person who pointe

[Python-3000] Conservative Defaults (was: Re: Support for PEP 3131)

Jim Jewett writes: > > You're exaggerating the amount of work caused [by adding to the toolchain] > > No, he isn't. It is exaggeration. AFAICS the work of auditing character sets can be done by the same codec APIs that implement PEP 263. The only question is whether the additional work of p

Re: [Python-3000] Conservative Defaults (was: Re: Support for PEP 3131)

BJörn Lindqvist writes: > > On the other hand, if "anything from *any* script" becomes the > > default, even on a single widespread distribution, then the community > > starts to splinter in a new way. It starts to separate between people > > who distribute source code (generally ASCII) and p

Re: [Python-3000] example Python code under PEP 3131?

> Can somebody post a few examples of what Python code > would look like under PEP 3131? Maybe 10-to-15 line > programs that illustrate the following use cases. Anbei eine Klassendefinition, wie sie oft von Studenten in der mündlichen Prüfung vorgeschlagen wird. Mittendrin fragen sie sich dann, o

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

Stephen J. Turnbull schrieb: > > > Sure - but how can Python tell whether a non-normalized string was > > > intentionally put into the source, or as a side effect of the editor > > > modifying it? > > > > It can't, but does it really need to? It could always assume the latter. > > No, it can

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

On 6/4/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > No, it can't. One might want to write Python code that implements > normalization algorithms, for example, and there will be "binary > strings". Only in the context of Unicode text are you allowed to > do those things. But Python files