[Martin v. Löwis]
> > 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 sa
On 5/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > That is how I felt when you dismissed my effort to make your proposal more
> > useful and more acceptable to some (by addressing transliteration) with the
> > little molehill problem that Norwegians and Germans disagree about o:
> > (rota
On 5/21/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> i thought of simply treating Cf chars as whitespace -- i.e., they
> are allowed BETWEEN identifiers, but not INSIDE of them.
I think the suggestion from other languages was to strip them out
during canonicalization. This allows abc and cba t
On 5/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> That is my reasoning, too. People seem to want to be conservative,
> so it's safer to reject formatting characters for the moment.
> If people come up with a need, they still can be added.
How about this: *require* the LEFT-TO-RIGHT MARK a
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I'm not aware of an algorithm that
| can do transliteration for all Unicode characters.
Were you proposing to allow all Unicode characters in Python names?-)
| Therefore, I cannot add transliteration into the PEP.
Terry Reedy wrote:
>
> My proposal was that the Unicode characters allowed in Python identifiers
> be limited to those with a transliteration, either current or to be
> developed by those who want to use a particular character set.
Japanese has a transliteration to Roman script, but it suffers
> i thought of simply treating Cf chars as whitespace -- i.e., they
> are allowed BETWEEN identifiers, but not INSIDE of them.
Ok - that would also work. Are you proposing that the PEP is changed
in that way, or are you merely stating that it would "work"? (ie.
would you prefer to see it changed t
> Would it be acceptable to create an encoding such that you could read
> and write
>
>Löwis
>
> in your editor, but upon import, python treated it as though you had
> writtten
>
>LU_246wis
>
> Other modules would see LU_246wis, unless they also used that encoding
> -- in which case the
> How about this: *require* the LEFT-TO-RIGHT MARK after
> every sequence of RTL characters outside a string or
> comment; and *forbid* all other Cf characters.
>
> This is just as conservative, but supports RTL-language
> identifiers better. It prevents all the "stupid bidi tricks"
> I know of (a
On 5/21/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Would it be acceptable to create an encoding such that you could read
> > and write
> >Löwis
> > in your editor, but upon import, python treated it as though you had
> > writtten
> >LU_246wis
> > Other modules would see LU_246
On May 21, 2007, at 6:31 PM, Martin v. Löwis wrote:
> This is indeed more conservative, and I could happily put it
> in the PEP, but again I prefer not to do so without an explicit
> confirmation from a user of such a language that this actually
> helps anything.
>
> tomer's comment (that you need
> If I do arbitrary introspection, such as
>
>import sys
>for k, v in sys.modules:
>if v:
>print dir(v)
>
> then I will get something usable, though perhaps not easily readable.
I think this is unacceptable (at least I cannot accept it):
with reflection, I want to get
> | I'm not aware of an algorithm that
> | can do transliteration for all Unicode characters.
>
> Were you proposing to allow all Unicode characters in Python names?-)
Not sure how to interpret your question: no, I'm not proposing
to allow all Unicode characters, just a selected subset (but then,
13 matches
Mail list logo
