Guido van Rossum writes:
> We should probably be conservative; I'm not too hopeful about
> support for right-to-left alphabets for example.
I don't see what's for *Python* to *support*.
My reasoning: bidi is entirely an issue of presentation; all Python
should do is prohibit[1] direction mark
I can see that I don't stand a very high chance of convincing you.
But I'd like to make sure you understand what I'm getting at, anyway.
(And I will get to some specific suggestions at the end of this
message.)
The key thing is that the language definition is about to transition
from something whi
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> I can see that I don't stand a very high chance of convincing you.
> But I'd like to make sure you understand what I'm getting at, anyway.
> (And I will get to some specific suggestions at the end of this
> message.)
>
> The key thing is that the language
Ka-Ping Yee wrote:
> 2. Python will become vulnerable to a new class of security
> exploits via the writing of misleading or malicious code
> that is visually indistinguishable from correct code.
> Consequently it will be more difficult for humans to
> inspect c
Josiah Carlson writes:
> From identical character glyph issues (which have been discussed
> off and on for at least a year),
In my experience, this is not a show-stopping problem. Emacs/MULE has
had it for 20 years because of the (horrible) design decision to
attach charset information to each
On Wed, 23 May 2007, Ian D. Bollinger wrote:
> Ka-Ping Yee wrote:
> > 2. Python will become vulnerable to a new class of security
> > exploits via the writing of misleading or malicious code
> > that is visually indistinguishable from correct code.
> > Consequently it w
On 5/23/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 5/22/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> >
> > As you see, cStringIO's code also needs a good cleanup to make it,
> > at least, conforms to PEP-7.
>
> Alexandre,
>
> It would be great if you could break up unrelated changes
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson writes:
>
> > From identical character glyph issues (which have been discussed
> > off and on for at least a year),
>
> In my experience, this is not a show-stopping problem.
I never claimed that this, by itself, was a showstop
On 5/23/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > It simplifies checking for identifiers that *don't* stick to ASCII,
> Only if you assume that people will actually perceive the 10-character
> string "L\u00F6wis" as an identifier, regardless of the fact that any
On 5/23/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> First: the "Common Objections" section of the PEP is too thin. I'd
> like the following arguments to be mentioned there for the record:
> 4. Python programs that reuse other Python modules may come
> to contain a mix of character s
On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Certain cut-and-paste errors (such as cutting from a word document
> that uses "smart quotes") will change from syntax errors to silently
> creating new identifiers.
Really? Are those quote characters considered letters by the Unicode standard?
On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > First: the "Common Objections" section of the PEP is too thin. I'd
> > like the following arguments to be mentioned there for the record:
>
> > 4. Python programs that reuse other Python
Ka-Ping Yee wrote:
> But with Unicode identifiers you have no way to know even whether you
> should be suspicious. You would feel confident that you know what
> a simple piece of code does, and yet be wrong.
Also, Jim Jewett wrote:
> Strings aren't a problem unless I evaluate them.
a = """Th
Removing those words that some found offensive, perhaps I will get a
reponse to the point of my post: "your tools aren't very good" and
"Emacs does it right" are not valid responses to the concerns brought up
regarding unicode.
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wri
Josiah Carlson wrote:
> Thank you for hitting home that unless people use Emacs, their tools
> arent sufficient for Python development. I still don't believe that my
> concerns have been addressed. And I certainly don't believe that those
> Ka-Ping brought up (which are better than mine) have been
On Wed, 23 May 2007, Guido van Rossum wrote:
> On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Certain cut-and-paste errors (such as cutting from a word document
> > that uses "smart quotes") will change from syntax errors to silently
> > creating new identifiers.
>
> Really? Are those quote
On 5/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Certain cut-and-paste errors (such as cutting from a word document
> > that uses "smart quotes") will change from syntax errors to silently
> > creating new identifiers.
> Really? Are th
This discussion is off the rails again.
I'm at least sympathetic to the spoofing argument, because theoretical
security concerns have a way of becoming serious practical concerns
overnight.
But I'm not sure what to make of the rest. Other languages have had
this feature for many years. The "num
On Wed, 23 May 2007, Ka-Ping Yee wrote:
> So there are three sets of characters that look the same:
>
> U+02BB = U+0312 = U+2018
> U+02BC = U+0313 = U+0315 = U+2019
> U+02EE = U+201D
The Greek combining koronis, U+0343, is an allowed identifier
character and also looks identical to a s
On Wed, 23 May 2007, Stephen J. Turnbull wrote:
> > It means users could see the usability benefits of PEP3131, but the
> > python internals could still work with ASCII only.
>
> But this reasoning is not coherent. Python internals will have no
> problems with non-ASCII; in fact, they would have
--- Neil Toronto <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Thank you for hitting home that unless people use
> Emacs, their tools
> > arent sufficient for Python development. I still
> don't believe that my
> > concerns have been addressed. And I certainly
> don't believe that those
--- Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> In summary, my preference ordering of the
> possibilities would be:
>
> [...]
>
> 2. "python" allows only ASCII identifiers.
> "python -U" allows
> Unicode identifiers that are in NFC and use
> a conservative,
> *fixed* subset of
Regarding using looking-alike glyphs (in certain fonts) security
issues, wouldn't it be a good thing for any project anyway to have a
number of pre-conditions for any given contribution to a given project
to be cleared. On of such litmus tests would be like the following.
try:
codecs.open("con
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Regarding using looking-alike glyphs (in certain
> fonts) security
> issues, wouldn't it be a good thing for any project
> anyway to have a
> number of pre-conditions for any given contribution
> to a given project
> to be cleared. On of such litmu
The tokenize module could easily be used to do such tests, as lenient
or as strict as required by any particular style guide.
On 5/23/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Regarding using looking-alike glyphs (in certain fonts) security
> issues, wouldn't it be a good thing for any proj
> This particular excuse pisses me off the most. "If you can't
> differentiate, then your font or editor sucks." Thank you for passing
> judgement on my choice of font or editor, but Ka-Ping already stated
> why this argument is bullshit: there does not currently exist a font
> where one *can* di
> I just realized that this is not the whole story. There's no
> requirement that a combining character has to actually come
> after a character it can be combined with. So there might be
> valid identifiers containing sequences of characters that don't
> have a sensible rendering, or that force
> You've got this backwards, and I suspect that's part of the root of
> the disagreement. It's not that "when humans enter the loop they
> cause problems." The purpose of the language is to *serve humans*.
> Without humans, we would just use machine code instead of Python.
> If it doesn't work fo
28 matches
Mail list logo
