Re: [Python-3000] Updated and simplified PEP 3141: A Type Hierarchy for Numbers

Jeffrey Yasskin wrote: > I've updated PEP3141 to remove the algebraic classes and bring the > numeric hierarchy much closer to scheme's design. Let me know what you > think. Feel free to send typographical and formatting problems just to > me. My schedule's a little shaky the next couple weeks, but

Re: [Python-3000] PEP 3131 - the details

> Some questions I have: is the defined UID set the same as in the referenced > appendix? Yes; it was copied from there. > Is it the same as in Java (and hence Jython)? No. Not sure whether I can produce a complete list of differences, but some of them are: - Java allows $ in identifiers, the

Re: [Python-3000] PEP 3131 - the details

> One issue I see is that the PEP defines ID_Start and ID_Continue > itself. It should not do that, bue instead reference as authoritative > the unicode properties ID_Start and ID_Continue defined in the > unicode property database. ID_Start and ID_Continue are derived non-mandatory properti

Re: [Python-3000] pep 3131 again

> all in all, i'm still -1 on that. i would rather go halfway -- allow unicode > comments. let people write docs in their native language, that's all > fine with me (or is that already imposed by the UTF8 PEP?) As other's have pointed out: you can use non-ASCII comments for a long time. In fact, y

Re: [Python-3000] pep 3131 again

> === help people who can't type english === > since the keywords remain ASCII, along with stdlib and all other major > third party libs -- how does that help the english-illiterate programmer? english-illiterate and "can't type english" are very different things. By "can't type english", I assume

Re: [Python-3000] PEP 3131 - the details

> > The same as in .NET (and hence IronPython)? > > This kind of research is time consuming; it cost me an hour to come > up with above list. Please research it for yourself. FYI: - ECMA-334 C# Language Specification 9 Lexical structure 9.4 Tokens 9.4.2 Identifiers

Re: [Python-3000] PEP 3131 - the details

> > > The same as in .NET (and hence IronPython)? > > > > This kind of research is time consuming; it cost me an hour to come > > up with above list. Please research it for yourself. C# identifiers (cont) About normalization and @ - Paragraph 2 (

Re: [Python-3000] Updated and simplified PEP 3141: A Type Hierarchy for Numbers

Talin wrote: > This really highlights what I think is a problem with dynamic > inheritance, and I think that this inconsistency between traditional and > dynamic inheritance will eventually come back to haunt us. It has always > been the case in the past that for every property of class B, if >

Re: [Python-3000] r55359 - python/branches/py3k-struni/Lib/test/test_strop.py

(relocating thread from python-3000-checkins) Brett Cannon wrote: > On 5/16/07, [EMAIL PROTECTED] * <[EMAIL PROTECTED] > > wrote: > Brett> Strop should go when the string module goes. I don't > remember > Brett> where the la

Re: [Python-3000] PEP 3131 - the details

Here are the rules for identifiers in javascript in case someone wants to know: http://interglacial.com/javascript_spec/a-7.html#a-7.6 -- Leonardo Santagada [EMAIL PROTECTED] ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org

[Python-3000] Whither string? (was Re: python/branches/py3k-struni/Lib/test/test_strop.py)

On Thu, May 17, 2007, Nick Coghlan wrote: > > To be honest, I have never understood the repeated proposals to get > rid of the string module. Get rid of the functions that are just > duplicates of str methods, sure, but the module makes sense to me > as a home for text related constants and other

Re: [Python-3000] PEP 3133: Introducing Roles

Guido van Rossum wrote: > On 5/16/07, Benji York <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >>> On 5/14/07, Benji York <[EMAIL PROTECTED]> wrote: Collin Winter wrote: > PEP: 3133 > Title: Introducing Roles Everything included here is included in zope.interface. See in-

Re: [Python-3000] Unicode strings, identifiers, and import

> Does the tokenizer do this for all string literals, too? Otherwise you > could still get surprises with things like x.foo vs. getattr(x, > "foo"), if the name foo were normalized but the string "foo" were not. No. If you use a string literal, chances are very high that you put NFC into your sour

Re: [Python-3000] r55359 - python/branches/py3k-stru ni/Lib/test/test_strop.py

On Thursday 17 May 2007, Nick Coghlan wrote: > To be honest, I have never understood the repeated proposals to get rid > of the string module. Get rid of the functions that are just duplicates > of str methods, sure, but the module makes sense to me as a home for > text related constants and ot

Re: [Python-3000] pep 3131 again

well, i still don't see what problems having that would solve. it seems like just "a cool feature" people want to have. they will still need to use latin text/english docs most of the time. on the other i don't see a reason to limit them intentionally. if that would keep them content/make the tra

Re: [Python-3000] PEP 3131 - the details

> While there has been a lot of discussion as to whether to accept PEP > 3131 as a whole, there has been little discussion as to the specific > details of the PEP. In particular, is it generally agreed that the > Unicode character classes listed in the PEP are the ones we want to > include in i

Re: [Python-3000] PEP 3131 - the details

Leonardo Santagada schrieb: > Here are the rules for identifiers in javascript in case someone > wants to know: > http://interglacial.com/javascript_spec/a-7.html#a-7.6 In all these reports, part of the analysis is also to determine how those specifications deviate (or not) from PEP 3131. In th

Re: [Python-3000] Whither string? (was Re: python/branches/py3k-struni/Lib/test/test_strop.py)

> The trend in support seems to be toward moving everything left that is > useful from "string" to "text", which would be a package. Sigh. After 15 years of carefully writing python code using "text" instead of "string" as a variable name, I'm sure this will work out just fine. :-) Bill __

Re: [Python-3000] Whither string? (was Re: python/branches/py3k-struni/Lib/test/test_strop.py)

Bill Janssen schrieb: >> The trend in support seems to be toward moving everything left that is >> useful from "string" to "text", which would be a package. > > Sigh. After 15 years of carefully writing python code using "text" > instead of "string" as a variable name, I'm sure this will work out

Re: [Python-3000] Updated and simplified PEP 3141: A Type Hierarchy for Numbers

On 5/17/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Talin wrote: > > This really highlights what I think is a problem with dynamic > > inheritance, and I think that this inconsistency between traditional and > > dynamic inheritance will eventually come back to haunt us. It has always > > been the

[Python-3000] PEP 3131 accepted

I have accepted PEP 3131. Note that it now contains the following policy: """ As an addition to the Python Coding style, the following policy is prescribed: All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases

Re: [Python-3000] Updated and simplified PEP 3141: A Type Hierarchy for Numbers

On 5/17/07, Collin Winter <[EMAIL PROTECTED]> wrote: > ABCs can define concrete methods. These concrete methods provide > functionality that the child classes do not themselves provide. You seem to be misreading my intention here. ABCs serve two purposes: they are interface specifications, and the

Re: [Python-3000] PEP 3131 - the details

On May 17, 2007, at 5:10 AM, Martin v. Löwis wrote: >> This list is available as part of the PropList.txt file in the >> unicode data, which ought to be included automatically in python's >> unicode database so as to get future changes. > > This I'm not so sure about. I changed the PEP to say that

Re: [Python-3000] PEP 3131 - the details

On May 17, 2007, at 11:22 AM, Martin v. Löwis wrote: >> While there has been a lot of discussion as to whether to accept PEP >> 3131 as a whole, there has been little discussion as to the specific >> details of the PEP. In particular, is it generally agreed that the >> Unicode character classes l

Re: [Python-3000] PEP 3131 - the details

> I think this is not something that is appropriate for Python. It looks > fairly specific to implementing a centralized name registry (say: DNS). > Specifically, the backwards compatibility is not appropriate, as it > doesn't guarantee that a name valid now will be valid in the future. > They poi

Re: [Python-3000] Updated and simplified PEP 3141: A Type Hierarchy for Numbers

On 5/17/07, Talin <[EMAIL PROTECTED]> wrote: > Lets therefore assume that the numeric ABCs will use this new > inheritance mechanism, avoiding the problem of taking an immature class > hierarchy and setting it in stone. The PEPs in this class would then no > longer need to have this privileged stat

Re: [Python-3000] pep 3131 again

Martin, this message suggests an addition to PEP 3131. On 5/16/07, tomer filiba <[EMAIL PROTECTED]> wrote: > === RTL/LTR === > the only practical way to use RTL languages in code is to have an RTL > programming language, where "if" is spelled "אם", "for" as "עבור", > "in" as "בתוך", and so on, and

Re: [Python-3000] PEP 3131 - the details

I mentioned this in another thread as an aside in the middle of the email, but I thought I'd put it out here at the top: It should be considered whether formatting characters should be ignored. And if so, which list of properties should be used for that. I notice that the excerpt from the C#

Re: [Python-3000] PEP 3131 - the details

> So, maybe it's better to keep the status quo, and not allow Cf > characters, unless someone comes up with a particular need for doing so. > Hm, I think I've convinced myself of that now. :) That is my reasoning, too. People seem to want to be conservative, so it's safer to reject formatting char

Re: [Python-3000] Updated and simplified PEP 3141: A Type Hierarchy for Numbers

On 5/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 5/17/07, Collin Winter <[EMAIL PROTECTED]> wrote: > > ABCs can define concrete methods. These concrete methods provide > > functionality that the child classes do not themselves provide. > > You seem to be misreading my intention here. AB

Re: [Python-3000] PEP 3133: Introducing Roles

On 5/17/07, Benji York <[EMAIL PROTECTED]> wrote: > > [PEP 3119] > > In classical OOP theory, invocation is the preferred usage pattern, > > and inspection is actively discouraged, being considered a relic of an > > earlier, procedural programming style. However, in practice this view > > is s

Re: [Python-3000] pep 3131 again

> 2. Python forbids these characters. Martin, JavaScript > treats these specially, and I think Python probably > should, too: > > The ECMAScript 3 standard for JavaScript requires the > tokenizer to throw away all Unicode format-control characters > (general category Cf). > > ECMAScript 4 will

Re: [Python-3000] PEP 3131 accepted

On 17/05/2007 18.48, Guido van Rossum wrote: > I have accepted PEP 3131. Do you have a rationale to share with us? Especially given that your previous public mails about the PEP looked mostly against it. This way, the rationale can be embedded in the PEP for future reference. Thanks! -- Giova

Re: [Python-3000] Unicode strings, identifiers, and import

On 13/05/2007 21.31, Guido van Rossum wrote: > The answer to all of this is the filesystem encoding, which is already > supported. Doesn't appear particularly difficult to me. sys.getfilesystemencoding() is None on most Linux computers I have access to. How is the problem solved there? In fact,

Re: [Python-3000] PEP 3131 accepted

You've missed a few of my mails. I liked the reports from the Java world. On 5/17/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 17/05/2007 18.48, Guido van Rossum wrote: > > > I have accepted PEP 3131. > > Do you have a rationale to share with us? Especially given that your previous > public m

Re: [Python-3000] Unicode strings, identifiers, and import

On 5/17/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 13/05/2007 21.31, Guido van Rossum wrote: > > > The answer to all of this is the filesystem encoding, which is already > > supported. Doesn't appear particularly difficult to me. > > sys.getfilesystemencoding() is None on most Linux computer

Re: [Python-3000] Unicode strings, identifiers, and import

On 18/05/2007 1.10, Guido van Rossum wrote: >> In fact, I have a question about this. Can anybody show me a valid >> multi-platform Python code snippet that, given a filename as *unicode* >> string, >> create a file with that name, possibly adjusting the name so to ignore an >> encoding probl

Re: [Python-3000] Unicode strings, identifiers, and import

On 5/17/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 18/05/2007 1.10, Guido van Rossum wrote: > > >> In fact, I have a question about this. Can anybody show me a valid > >> multi-platform Python code snippet that, given a filename as *unicode* > >> string, > >> create a file with that name

Re: [Python-3000] pep 3131 again

On 17/05/2007 11.23, Martin v. Löwis wrote: > Whether or not Japanese or Chinese people with no knowledge of > English still can master the Latin alphabet easily, I don't know, > as all Chinese people I do know speak German or English well. All Chinese people are taught the Latin-character transl

Re: [Python-3000] Unicode strings, identifiers, and import

On May 17, 2007, at 7:04 PM, Giovanni Bajo wrote: > On 13/05/2007 21.31, Guido van Rossum wrote: > >> The answer to all of this is the filesystem encoding, which is >> already >> supported. Doesn't appear particularly difficult to me. > > sys.getfilesystemencoding() is None on most Linux comput

Re: [Python-3000] Unicode strings, identifiers, and import

On 18/05/2007 1.24, James Y Knight wrote: > unicode_filename.encode(sys.getfilesystemencoding() or 'ascii', > 'xmlcharrefreplace') would work. Thanks - using "xmlcharrefreplace" hadn't occurred to me! > The *really* tricky thing is that on unix systems, if you want to be > able to access all

[Python-3000] Radical idea: remove built-in open (require import io)

Do people think it would be too radical if the built-in open() function was removed altogether, requiring all code that opens files to import the io module first? This would make it easier to identify modules that engage in I/O. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___

Re: [Python-3000] Radical idea: remove built-in open (require import io)

On 5/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Do people think it would be too radical if the built-in open() > function was removed altogether, requiring all code that opens files > to import the io module first? This would make it easier to identify > modules that engage in I/O. I thi

Re: [Python-3000] Radical idea: remove built-in open (require import io)

Would other IO builtins also move, like (formerly raw_) input and print? What about the file type? it seems to me that if the rationale is to make use of IO identifiable, then all IO functions would have to move into the io module. What am I missing? - C On 5/17/07, Guido van Rossum <[EMAIL PR

Re: [Python-3000] Radical idea: remove built-in open (require import io)

On 5/17/07, Chris Monson <[EMAIL PROTECTED]> wrote: > Would other IO builtins also move, like (formerly raw_) input and > print? What about the file type? The file type is already gone in py3k. > it seems to me that if the rationale is to make use of IO > identifiable, then all IO functions woul

Re: [Python-3000] Radical idea: remove built-in open (require import io)

On 5/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 5/17/07, Chris Monson <[EMAIL PROTECTED]> wrote: > Would other IO builtins also move, like (formerly raw_) input and > print? What about the file type? The file type is already gone in py3k. > it seems to me that if the rationale is t

Re: [Python-3000] PEP 3131 - the details

Martin v. Löwis wrote: > (there might be a need for it in RTL languages, supporting > 200E..200F and 202A..202E, but it seems that speakers of RTL > languages are skeptical about the entire PEP, so it's unclear > whether allowing these would help anything) The ideal kind of programming language f

Re: [Python-3000] Unicode strings, identifiers, and import

James Y Knight wrote: > The *really* tricky thing is that on unix systems, if you want to be > able to access all the files on the disk, you have to use the byte- > string API ... But on windows ... you *CANNOT* use the byte-string api How are we going to cope with this in Py3k with unicode-on

Re: [Python-3000] PEP 3131 - the details

Ignoring for a moment that prefix != reverse(postfix), that is :-) - C On 5/17/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > > (there might be a need for it in RTL languages, supporting > > 200E..200F and 202A..202E, but it seems that speakers of RTL > > languages ar

Re: [Python-3000] Unicode strings, identifiers, and import

On 5/17/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > James Y Knight wrote: > > The *really* tricky thing is that on unix systems, if you want to be > > able to access all the files on the disk, you have to use the byte- > > string API ... But on windows ... you *CANNOT* use the byte-string api > > H

Re: [Python-3000] Radical idea: remove built-in open (require import io)

On Thu, May 17, 2007, Guido van Rossum wrote: > > Do people think it would be too radical if the built-in open() > function was removed altogether, requiring all code that opens files > to import the io module first? This would make it easier to identify > modules that engage in I/O. My initial ta

Re: [Python-3000] Radical idea: remove built-in open (require import io)

On 5/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: Do people think it would be too radical if the built-in open() function was removed altogether, requiring all code that opens files to import the io module first? This would make it easier to identify modules that engage in I/O. I suppo

Re: [Python-3000] Unicode strings, identifiers, and import

>> The answer to all of this is the filesystem encoding, which is already >> supported. Doesn't appear particularly difficult to me. > > sys.getfilesystemencoding() is None on most Linux computers I have access to. That's strange. Is LANG not set? > How is the problem solved there? A default n