On 6/6/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Are you suggesting that this should be done on the fly
> when comparing strings? Or that all strings should be
> stored in canonicalised form?
Preferably the second; store them canonicalized.
> I can see some big cans of worms being opened up by
On 6/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> > Unicode does say pretty clearly that (at least) canonical
> >> > equivalents must be treated the same.
On reflection, what it actually says is that you may not assume they
are different. They can be different in the same way that two
Jim Jewett wrote:
> Since we don't want the results of (str1 == str2) to change based on
> context, I think string equality also needs to look at canonicalized
> (though probably not compatibility) forms.
Are you suggesting that this should be done on the fly
when comparing strings? Or that all st
"Martin v. Löwis" writes:
> > TR 15, section 19, numbered paragraph 3
> > """
> > Higher-level processes that transform or compare strings, or that
> > perform other higher-level functions, must respect canonical
> > equivalence or problems will result.
> > """
>
> That's not a mandatory
>> > Unicode does say pretty clearly that (at least) canonical equivalents
>> > must be treated the same.
>
>> Chapter and verse, please?
>
> I am pretty sure this list is not exhaustive, but it may be helpful:
>
> The Identifiers Annex http://www.unicode.org/reports/tr31/
Ah, that's in the con
On 6/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jim Jewett schrieb:
> > On 6/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> > Always normalizing would have the advantage of simplicity (no
> >> > matter what the encoding, the result is the same), and I think
> >> > that is the rea
Jim Jewett schrieb:
> On 6/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> > Always normalizing would have the advantage of simplicity (no
>> > matter what the encoding, the result is the same), and I think
>> > that is the real path of least surprise if you sum over all
>> > surprises.
>
>>
On 6/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Always normalizing would have the advantage of simplicity (no
> > matter what the encoding, the result is the same), and I think
> > that is the real path of least surprise if you sum over all
> > surprises.
> I'd like to repeat that this
> The path of least surprise for legacy encodings might be for
> the codecs to produce whatever is closest to the original encoding
> if possible. I.e. what was one code point would remain one code
> point, and if that's not possible then normalize. I don't know if
> this is any different from alwa
On 6/4/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > However, what would that mean wrt. non-Unicode source encodings.
>
> > Say you have a Latin-1-encoded source code. Is that in NFC or not?
The path of least surprise for legacy encodings m
>> Say you have a Latin-1-encoded source code. Is that in NFC or not?
>
> Doesn't that depend on whether they happened to ever write some of the
> combined characters (such as ö) using a two-character form like o¨?
No. Latin-1 does not support that form; the concept does not exist
in that encodin
On 6/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It seems to me the simplest thing to do is to require that Python
> > source files be normalized. Then the ambiguity just goes away.
> > Everyone knows what form their files should be in, and if you really
> > need to construct a non-norm
> It seems to me the simplest thing to do is to require that Python
> source files be normalized. Then the ambiguity just goes away.
> Everyone knows what form their files should be in, and if you really
> need to construct a non-normalized string, you can do that explicitly
> using "\u" notation.
On Sun, 3 Jun 2007, [UTF-8] "Martin v. L??wis" 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? If you have decomposable characters in strings and
> > your editor decide
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
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
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
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
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
>> 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
(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?
Martin v. Löwis a écrit :
>> If this is to ever happen, it should be only accessible through a
>> command-line
>> option to python. That way we make sure people are aware that they are making
>> their code incompatible with the larger world.
>
> In what way will the source code be incompatible wi
On May 4, 2007, at 4:47 PM, Baptiste Carvello wrote:
> If this is to ever happen, it should be only accessible through a
> command-line
> option to python. That way we make sure people are aware that they
> are making
> their code incompatible with the larger world.
That's ridiculous. Without
> If this is to ever happen, it should be only accessible through a command-line
> option to python. That way we make sure people are aware that they are making
> their code incompatible with the larger world.
In what way will the source code be incompatible with the larger world?
Martin
Martin v. Löwis a écrit :
> PEP: 31xx
> Title: Supporting Non-ASCII Identifiers
> Version: $Revision$
> Last-Modified: $Date$
> Author: Martin v. Löwis <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-May-2007
> Python-Version: 3.0
> Post-History:
Hi,
One item that I haven't seen mentioned in support of this is that
there is code that uses getattr for accessing things that might be
access other ways.
For example the Attribute access Dictionaries
(http://mail.python.org/pipermail/python-list/2007-March/429137.html),
if one of the keys has a
On 5/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>
> > http://mail.python.org/pipermail/python-3000/2006-April/001526.html
> >
> > where Guido states that he trusts me that it can be made to work,
> > and that "eventually" it needs to be supported.
+0
> He says "the tools
On 5/2/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > So, Martin, I suggest that you expand your proposal to include a
> > transliteration mechanism and limit the allowed characters to those which
> > can be translitered. I presume that this would be an expanding set. Once
> > a mechanism i
Martin v. Löwis wrote:
...
> Specification of Language Changes
> =
>
> The syntax of identifiers in Python will be based on the Unicode
> standard annex UAX-31 [1]_, with elaboration and changes as defined
> below.
>
> Within the ASCII range (U+0001..U+007F), the v
> So, Martin, I suggest that you expand your proposal to include a
> transliteration mechanism and limit the allowed characters to those which
> can be translitered. I presume that this would be an expanding set. Once
> a mechanism is in place, people who want 'their' character set included ca
> He says "the tools aren't ready yet", which I take to
> mean that Python won't need to support it until all
> widely-used editors, email and news software, etc, etc,
> reliably support displaying and editing of all
> unicode characters. We're clearly a long way from
> that situation.
I don't und
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On 01/05/2007 12.52, Martin v. Löwis wrote:
| Isn't this already blacklisted in PEP 3099?
In today's Pep Parade post, he implies no.
"PEP: Supporting Non-ASCII identifiers (Martin von Loewis)
I'm on record as not liki
Leonardo Santagada wrote:
> but all of the literals on the sintax of python would be better if
> they can be on the programmers language, as what the guys from OLPC
> want.
It's not clear to me that that's what we want, actually. I think Alan
Kay mentioned that they can do this level of i18n
I don't know if I can speak on the py3k list, but I would give this a
-1.
Supporting non-ascii identifiers don't fix the bigger problem. People
want to write programs in their own language. Not only identifiers,
but all of the literals on the sintax of python would be better if
they can b
Martin v. Löwis wrote:
> I still don't understand why the "no operation" statement is called
> "pass" - it's not the opposite of "fail", and seems to have no
> relationship to "can you pass me the butter, please?".
It's "pass" as in "pass through", i.e. move on to the next
statement without stopp
Martin v. Löwis wrote:
> http://mail.python.org/pipermail/python-3000/2006-April/001526.html
>
> where Guido states that he trusts me that it can be made to work,
> and that "eventually" it needs to be supported.
He says "the tools aren't ready yet", which I take to
mean that Python won't need t
Martin v. Löwis schrieb:
>> Reading from
>> http://mail.python.org/pipermail/python-3000/2006-April/001474.html,
>> the message that prompted this particular addition to PEP 3099, "I
>> want good Unicode support for string literals and comments. Everything
>> else in the language ought to be ASCII.
Robert Brewer schrieb:
> Martin v. Löwis wrote:
>> Subject: [Python-3000] PEP: Supporting Non-ASCII Identifiers
>>
>> Common Objections =
>>
>> People claim that they will not be able to use a library if to do
>> so they have to use charact
On May 1, 2007, at 12:19 PM, Jim Jewett wrote:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> The identifier syntax is \*.
>
>> ID_Start is defined as all characters having one of the general
>> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
>> letters (Lt),
Martin v. Löwis wrote:
> Subject: [Python-3000] PEP: Supporting Non-ASCII Identifiers
>
> Common Objections
> =
>
> People claim that they will not be able to use a library if to do so
> they have to use characters they cannot type on their
> keyboards. H
2007/5/1, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> The point is that even though many people get some passive knowledge
> of English over time, they have a hard time with active usage of the
> language. So when they need to come up with identifiers and put comments
> into the code, they use their f
Jim Jewett schrieb:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> The identifier syntax is \*.
>
>> ID_Start is defined as all characters having one of the general
>> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
>> letters (Lt), modifier letters (Lm), oth
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The identifier syntax is \*.
> ID_Start is defined as all characters having one of the general
> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
> letters (Lt), modifier letters (Lm), other letters (Lo), letter
> numb
> Reading from
> http://mail.python.org/pipermail/python-3000/2006-April/001474.html,
> the message that prompted this particular addition to PEP 3099, "I
> want good Unicode support for string literals and comments. Everything
> else in the language ought to be ASCII."
>
> Identifiers aren't stri
>> Python code is written by many people in the world who are not
>> familiar with the English language, or even well-acquainted with the
>> Latin writing system.
> [snip]
>
> That makes absolutely no sense. You mean to tell me that people write
> Python without being able to understand any of the
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Title: Supporting Non-ASCII Identifiers
> >
> > Isn't this already blacklisted in PEP 3099?
>
> It's not clear to me. That was in response to a suggestion
> that non-ASCII symbols will be used in the syntax of Python,
> i.e. in a way maki
>> Title: Supporting Non-ASCII Identifiers
>
> Isn't this already blacklisted in PEP 3099?
It's not clear to me. That was in response to a suggestion
that non-ASCII symbols will be used in the syntax of Python,
i.e. in a way making it mandatory to be able to type these
symbols.
This is not the i
On 5/1/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Rationale
> > =
> That makes absolutely no sense. You mean to tell me that people write
> Python without being able to understand any of the language's
> keywords, builtin func
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Rationale
> =
>
> Python code is written by many people in the world who are not
> familiar with the English language, or even well-acquainted with the
> Latin writing system.
[snip]
That makes absolutely no sense. You mean to tell
On 01/05/2007 12.52, Martin v. Löwis wrote:
> PEP: 31xx
> Title: Supporting Non-ASCII Identifiers
Isn't this already blacklisted in PEP 3099?
--
Giovanni Bajo
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo
PEP: 31xx
Title: Supporting Non-ASCII Identifiers
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 3.0
Post-History:
Abstract
This PEP suggests to support
51 matches
Mail list logo
