Jim Jewett writes:
> On 6/11/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > But this is something that only a small subset of developers-of-Python
> > seem to be concerned about.
This is a statement about the politics of changing an accepted PEP.
Without massive outcry, ain' agonna ha
>> As I am not going to be interested in trying to
>> understand code written in Chinese, Russian, etc., I'm not bothered by
>> the idea that someone might write code I will have a strong
>> disincentive to read.
>>
> The question is: is it worth it. Will the new feature allow more useful code
>
--- Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Steve Howell <[EMAIL PROTECTED]>
> wrote:
>
> > In my best franglais: je pense que les avocats de
> PEP
> > 3131 pourrait surmonter la doute, l'incertitude,
> le
> > crainte, etc., de PEP 3131 en montrant les
> exemples.
>
> Not really; I t
On 6/12/07, Steve Howell <[EMAIL PROTECTED]> wrote:
> In my best franglais: je pense que les avocats de PEP
> 3131 pourrait surmonter la doute, l'incertitude, le
> crainte, etc., de PEP 3131 en montrant les exemples.
Not really; I think everyone agrees that you *can* produce
well-written code wi
On 6/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ok, but why need you then *Python* to tell you that the file has
> non-ASCII identifiers? Just look inside the file, and see whether
> you like its source code.
That is just what many users (including, in some environments, me)
cannot do
--- Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>
> si tu me prends par les sentiments :-) Really, you
> make it sound so nice I would
> almost change my mind. Still wondering how much of
> an effort it will be, though.
>
I would again make a call out for actual examples of
what Python code w
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]>
wrote:
> Ka-Ping Yee writes:
> > Both of these come down to the wastefulness of
> redoing something
> > that the Python interpreter itself already knows
> how to do very
> > well, and is, in some sense by definition, the
> authority on how
> > to d
On 6/11/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > Of course, I wouldn't type them if I knew they were wrong. With an
> > ASCII-only install, I would get that error-check because the
> > (remaining original uses) were in Cyrillic. With an "any unicode
> > cha
Guillaume Proux a écrit :
> Hello,
>
> On 6/12/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>> context. By contrast, with chineses identifiers, I will not recognise them
>> from
>> one another. So I won't be able to make any sense from the code without going
>> through the complex task of tra
Martin v. Löwis a écrit :
> Baptiste Carvello schrieb:
>> Martin v. Löwis a écrit :
>>> I cannot imagine this scenario as realistic. It is certain
>>> realistic that you want to keep your own code base ASCII-only -
>>> what I don't understand why such a policy would extend to libraries
>>> that you
Michael Urman a écrit :
> As I am not going to be interested in trying to
> understand code written in Chinese, Russian, etc., I'm not bothered by
> the idea that someone might write code I will have a strong
> disincentive to read.
>
The question is: is it worth it. Will the new feature allow mo
On 6/11/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Michael Urman a écrit :
> > ... you already cannot visually inspect ...
> > There is the risk of visually aliased identifiers, but how is that
> > qualitatively worse than the truly conflicting identifiers you can
> > import with a *, or h
Ka-Ping Yee wrote:
>
> Hang on a second. No one is *imposing* new restrictions. Python
> uses ASCII-only identifiers today and has always been that way.
That restriction clearly wasn't imposed on the standard www.python.org windows
distributions of Python - for quite a few versions already. Se
Ka-Ping Yee writes:
> On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:
> > It seems to me that rather than *impose* restrictions on third
> > parties, the sensible thing to do is to provide those restrictions to
> > those who want them.
>
> Hang on a second. No one is *imposing* new restric
Rauli Ruohonen writes:
> I don't know any Chinese, but real Chinese is much more legible to me
> than transliterated one. Transliterations are complete gibberish to me,
And will be to most Chinese, too, unless Mandarin is used, since
pronunciation varies infinitely from dialect to dialect, alth
On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:
> It seems to me that rather than *impose* restrictions on third
> parties, the sensible thing to do is to provide those restrictions to
> those who want them.
Hang on a second. No one is *imposing* new restrictions. Python
uses ASCII-only identifi
On Tue, 12 Jun 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> Also, that all identifiers are ASCII is not sufficient
> for you to be able to debug the program in case of need: it also
> needs to be commented well, and the comments also should be in
> a language you understand. Furthermore, it has be
On 6/12/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> This is where we strongly disagree. If an identifier is written in
> transliterated chinese, I cannot understand what it means, but I can
> recognise it when it is used in the code. I will then find out the
> meaning from the context. By co
>> > Python currently provides to everyone the restriction of
>> > identifiers to a character set that everyone knows and trusts.
>> > Many of us want Python to continue to provide such restriction
>> > for those who want identifiers to be in a character set they
>> > know and trust. This is not i
>> or if I upgrade to the next Python version, assuming the default is
>> to restrict identifiers.
>>
> That would only happen if the default changes to a more strict rule. If we
> start
> with ASCII only, this is unlikely to ever happen!
It will likely happen. In 3.0, I change the installation d
Baptiste Carvello schrieb:
> Martin v. Löwis a écrit :
>> I cannot imagine this scenario as realistic. It is certain
>> realistic that you want to keep your own code base ASCII-only -
>> what I don't understand why such a policy would extend to libraries
>> that you use. If the interfaces of the li
Baptiste Carvello writes:
> I wouldn't be so sure. In open source, you never know in advance to
> whom your code can be useful. Maybe some part of you chinese tax
> software can be refactored into a more generic library. If you
> write the software with non-ASCII identifiers, this refactored
On 6/11/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Michael Urman a écrit :
> > There is the risk of visually aliased identifiers, but how is that
> > qualitatively worse than the truly conflicting identifiers you can
> > import with a *, or have inserted by modules mucking with
> > __builti
Jim Jewett writes:
> Of course, I wouldn't type them if I knew they were wrong. With an
> ASCII-only install, I would get that error-check because the
> (remaining original uses) were in Cyrillic. With an "any unicode
> character" install, ... well, I might figure out my problem the next
>
--- Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Leonardo Santagada a écrit :
> > I don't. It is a bad idea to distribute non-ASCII
> code for libraries
> > that are supposed to be used by the world as a
> whole. But
> > distributing a chinese code for doing something
> like taxes using
>
Martin v. Löwis a écrit :
> I cannot imagine this scenario as realistic. It is certain realistic
> that you want to keep your own code base ASCII-only - what I don't
> understand why such a policy would extend to libraries that you use.
> If the interfaces of the library are non-ASCII, you will aut
Michael Urman a écrit :
> On 6/11/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>> Because the existence of these library modules does not make it
>> impossible to reliably read source code. We're talking about
>> changing the definition of the language here, which is deeper
>> than adding or removin
Hello,
On 6/12/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> context. By contrast, with chineses identifiers, I will not recognise them
> from
> one another. So I won't be able to make any sense from the code without going
> through the complex task of translating everything.
You would be s
Martin v. Löwis a écrit :
>>> Indeed, PEP 3131 gives a predictable identifier character set.
>>> Adding per-site options to change the set of allowable characters
>>> makes it less predictable.
>>>
>> true. However, this will only matter if you distribute code with non-ASCII
>> identifiers to the w
James Y Knight a écrit :
> If another developer is planning to write code in English, this whole
> debate is moot. So, let's take as a given that he is going to write a
> program in his own non-English language. Now, will he write in a
> asciified form of his language, or using the proper cha
Leonardo Santagada a écrit :
> I don't. It is a bad idea to distribute non-ASCII code for libraries
> that are supposed to be used by the world as a whole. But
> distributing a chinese code for doing something like taxes using
> chinese rules is ok and should be encouraged (now, I don't know
On 6/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > One reason this matters -- even when the original author had good
> > intentions -- is that I edit my code as text, rather than graphics. I
> > will often retype rather than cutting and pasting. Since тор and нтер
> > are not the same a
On 6/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Python currently provides to everyone the restriction of
> > identifiers to a character set that everyone knows and trusts.
> > Many of us want Python to continue to provide such restriction
> > for those who want identifiers to be in a c
> One reason this matters -- even when the original author had good
> intentions -- is that I edit my code as text, rather than graphics. I
> will often retype rather than cutting and pasting. Since тор and нтер
> are not the same as the visually similar Top and HTep, that will
> eventually cause
On 6/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee schrieb:
> > Steve Howell wrote:
> >> I think this whole debate could be put to rest by
> >> agreeing to err on the side of ascii in 3.0 beta, and
> >> if in real world experience, that turns out to be the
> >> wrong decision, s
On 6/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Chinese in particular you would recognize as "not what I expected".
> > Cyrillic you might not recognize, because it looks like ASCII letters.
> Please take a look at http://ru.wikipedia.org/wiki/Python
> In what way does that look like
> Chinese in particular you would recognize as "not what I expected".
> Cyrillic you might not recognize, because it looks like ASCII letters.
Please take a look at
http://ru.wikipedia.org/wiki/Python
In what way does that look like ASCII letters? Cyrillic is
*significantly* different from Latin
> Python currently provides to everyone the restriction of
> identifiers to a character set that everyone knows and trusts.
> Many of us want Python to continue to provide such restriction
> for those who want identifiers to be in a character set they
> know and trust. This is not incompatible wit
Ka-Ping Yee schrieb:
> Steve Howell wrote:
>> I think this whole debate could be put to rest by
>> agreeing to err on the side of ascii in 3.0 beta, and
>> if in real world experience, that turns out to be the
>> wrong decision, simply fix it in 3.0 production, 3.1,
>> or 3.2.
>
> On Sun, 10 Jun 2
On 6/11/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> "In fact, it might even use something downright misleading, and
> you won't have any warning, because we thought that maybe someone,
> somewhere, might have wanted that character in a different context."
>
> And no, I don't think I'm exagerati
On 6/11/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Yes, universally. By allowing "any unicode character", you have
(oops -- apparently this posted with only half the edits)
> reason to believe the next piece of code isn't doing something
> strange, either by accident or by malice.
By allowing
On 6/10/07, Leonardo Santagada <[EMAIL PROTECTED]> wrote:
> We are all consenting
> adults and we know that we should code in english if we want our code
> to be used and to be a first class citizen of the open source world.
I have no objection to Open Source being written in Chinese.
My objecti
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Indeed, PEP 3131 gives a predictable identifier character set.
> >> Adding per-site options to change the set of allowable characters
> >> makes it less predictable.
> > Not in practice.
...
> > By allowing site modifications, the rule
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > * Or I copy and paste code from the Python Cookbook, a blog, etc.
> You copy code from the Python Cookbook and don't notice that it
> contains Chinese characters in identifiers???
Chinese in particular you would recognize as "not what
On 6/11/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Because the existence of these library modules does not make it
> impossible to reliably read source code. We're talking about
> changing the definition of the language here, which is deeper
> than adding or removing things in the library.
This
On 6/11/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Your attempted parallel does not match: it breaks code,
> whereas Steve's does not.
However the same code which would break only if we find we need to
restrict the characters in identifiers further than the restrictions
in the PEP, is broken off
On Sun, 10 Jun 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > That describes me perfectly. I am self-interested to
> > the extent that my employers just pay me to write
> > working Python code, so I want the simplicity of ASCII
> > only.
>
> What I don't understand is why you can't simply continu
Steve Howell wrote:
> I think this whole debate could be put to rest by
> agreeing to err on the side of ascii in 3.0 beta, and
> if in real world experience, that turns out to be the
> wrong decision, simply fix it in 3.0 production, 3.1,
> or 3.2.
On Sun, 10 Jun 2007, [ISO-8859-1] "Martin v. L?w
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Unfortunately, teachers don't participate
> in python-3000, as don't many other Python users.
> So it's unlikely that you find a teacher posting
> *here*, it was pure luck that I found a Chinese
> teacher posting on comp.lang.python. You would
>
> I wish the debate would turn to actual use cases. For
> example, one of the arguments behind PEP 3131 is that
> it will facilitate the use of Python in educational
> environments. It would be interesting to hear from
> actual teachers what their biggest impediments to
> using Python are right n
>> Indeed, PEP 3131 gives a predictable identifier character set.
>> Adding per-site options to change the set of allowable characters
>> makes it less predictable.
>>
> true. However, this will only matter if you distribute code with non-ASCII
> identifiers to the wider public.
No - it will matte
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I think this whole debate could be put to rest by
> > agreeing to err on the side of ascii in 3.0 beta,
> and
> > if in real world experience, that turns out to be
> the
> > wrong decision, simply fix it in 3.0 production,
> 3.1,
> > or 3.2.
>
--- James Y Knight <[EMAIL PROTECTED]> wrote:
>
> I'm pretty sure the answer is still going to
> be the second: I'd
> rather a program written in Chinese use Chinese
> characters, rather
> than a transliteration of Chinese into ASCII.
> because it is actually
> feasible for me to do automat
On Jun 10, 2007, at 4:57 PM, Baptiste Carvello wrote:
>
>> Indeed. That was my primary motivation for the PEP: to make
>> it easier for programmers to understand Python, and to allow
>> people to write more transparent programs.
> The real question is: transparent *to whom*. Transparent to the
>
Em 10/06/2007, às 17:57, Baptiste Carvello escreveu:
>> Indeed, PEP 3131 gives a predictable identifier character set.
>> Adding per-site options to change the set of allowable characters
>> makes it less predictable.
>>
> true. However, this will only matter if you distribute code with
> non-AS
Martin v. Löwis a écrit :
>> Here is what I have to say (to everyone in this discussion, not
>> specifically to you, Stephen) in response to said labelling:
>
> Interestingly enough, we agree on the principles, and just
> judge the PEP differently wrt. these principles
>
>> Many of us value a *pr
>> Indeed, PEP 3131 gives a predictable identifier character set.
>> Adding per-site options to change the set of allowable characters
>> makes it less predictable.
>
> Not in practice.
>
> Today, identifiers are drawn from [A-Za-z0-9], which is a fairly small set.
>
> Under the current PEP 3131
> BTW, I submitted the normalization patch for 2.6, if you want to look
> at it.
Thanks. It might take some time until I get a chance (or somebody else
may respond quicker); the 2.6 release is still ahead, so there is still
plenty of time.
Regards,
Martin
_
>> If it is the latter, I don't understand why the 95% ascii users need
>> to run additional verification and checking tools. If they don't
>> know the full language, they won't use it - why should they run
>> any checking tools?
>
> I drop this
> package into my tree, add the necessary imports an
Nick Coghlan schrieb:
> Martin v. Löwis wrote:
>>> I think that's a pretty strong reason for making the new, more complex
>>> behaviour optional.
>>
>> Thus making it simpler? The more complex behavior still remains,
>> to fully understand the language, you have to understand that behavior,
>>
>> People should not have to read long system configuration pages
>> just to run the program that they intuitively wrote correctly
>> right from the start.
>
> It is not intuitive. One thing I learned from the discussion here
> about Unicode identifiers in other languages is that, though this
> s
> That describes me perfectly. I am self-interested to
> the extent that my employers just pay me to write
> working Python code, so I want the simplicity of ASCII
> only.
What I don't understand is why you can't simply continue
to do so, with PEP 3131 implemented?
If you have no need for acce
> I think this whole debate could be put to rest by
> agreeing to err on the side of ascii in 3.0 beta, and
> if in real world experience, that turns out to be the
> wrong decision, simply fix it in 3.0 production, 3.1,
> or 3.2.
Likewise, this whole debate could also be put to rest
by agreeing to
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Many of us value a *predictable* identifier character set.
> > Whether "predictable" means ASCII only, or user-selectable, or
> > restricted by default, I think we all agree in this sentiment:
> Indeed, PEP 3131 gives a predictable ident
> It does, but it also refuses the temptation to guess that *everyone*
> wants to use unicode identifiers by default.
Please call them non-ASCII identifiers. All identifiers are Unicode,
anyway, since Python 1.0 or so. They will be represented as Unicode
strings in Python 3.
Regards,
Martin
>> "I know what you want, and I could easily do it, but I don't feel
>> like doing it, read these ten pages of text to learn more about the
>> problem".
>>
> in one word: exit
That's indeed close, and has caused grief for this exact property.
However, the case is actually different: exit could *no
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > To truly enable Python in a non-English teaching
> > environment, I think you'd actually want to go a step
> > further and just internationalize the whole program.
>
> I don't know why that theory keeps popping up when people
> have repea
> Here is what I have to say (to everyone in this discussion, not
> specifically to you, Stephen) in response to said labelling:
Interestingly enough, we agree on the principles, and just
judge the PEP differently wrt. these principles
> Many of us value a *predictable* identifier character set.
> To truly enable Python in a non-English teaching
> environment, I think you'd actually want to go a step
> further and just internationalize the whole program.
I don't know why that theory keeps popping up when people
have repeatedly pointed out that it is just false.
People *can* get used to t
> This keeps getting characterized as only a security argument, but
> it's much deeper; it's a basic code comprehension issue.
Despite you repeating this over and over, I still honestly, sincerely
do not understand the concern. You might be technically correct,
but I feel that the cases where thes
Josiah Carlson writes:
> gone ahead and mangled names in a consistant fashion using the tokenize
> module. Can you guess what it does?
OK, here's your straight line:
Throw a lot of "AttributeError: rInCXzn is not defined"?
___
Python-3000 mailing l
On Jun 4, 2007, at 3:43 PM, Josiah Carlson wrote:
> Here is some code borrowed right from the Python standard library.
> I've
> gone ahead and mangled names in a consistant fashion using the
> tokenize
> module. Can you guess what it does?
Nope, it's absolutely inscrutable. And actually, aft
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > I hate to make a decision by majority rule, but I
> > think there is the argument that you need to weigh
> the
> > population of ascii-literate people vs.
> > ascii-illiterate people.
>
> That's a very poor criteria, as not everyone in the
> w
--- Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steve Howell wrote:
> > the one word that I wasn't able to
> > translate, even with the help of Babelfish, was
> the
> > German word for "insert." It turns out the thing
> that
> > threw me off was that I omitted the umlaut.
>
> Although that probably
Steve Howell wrote:
> the one word that I wasn't able to
> translate, even with the help of Babelfish, was the
> German word for "insert." It turns out the thing that
> threw me off was that I omitted the umlaut.
Although that probably wouldn't be such a big problem
for a native German speaker, w
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Here is some code borrowed right from the Python
> standard library. I've
> gone ahead and mangled names in a consistant fashion
> using the tokenize
> module. Can you guess what it does?
>
>
> class RTrCOlOrB :
>
> nBBjIUrB =0
>
> def
Steve Howell <[EMAIL PROTECTED]> wrote:
> --- Michael Urman <[EMAIL PROTECTED]> wrote:
> >
> > The arguments then feel reduced to "Unicode enhances
> > readability" vs.
> > "Unicode impedes readability" and since clearly it
> > does both, how do
> > we make the value judgement about which it does
--- Michael Urman <[EMAIL PROTECTED]> wrote:
>
> The arguments then feel reduced to "Unicode enhances
> readability" vs.
> "Unicode impedes readability" and since clearly it
> does both, how do
> we make the value judgement about which it does
> more? How do we weigh
> the ability to use native l
On 6/4/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Many of us value a *predictable* identifier character set.
> Whether "predictable" means ASCII only, or user-selectable, or
> restricted by default, I think we all agree in this sentiment:
As someone who would rather see non-ASCII characters gain
On Fri, 25 May 2007, Guillaume Proux wrote:
> If you are really paranoid to see evil chars take over your
> python src dir
On Sun, 3 Jun 2007, Stephen J. Turnbull wrote:
> I do not agree with Ka-Ping inter alia that there are bogeymen
> under the bed
Sigh. I have lost count of the number of time
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
--- 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
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
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
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
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
>
On 6/2/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Your suggestion would unnecessarily change the semantics of the encoding
> > declarations. I would call this gratuitous breakage.
> Depending on what the regular expression for the dec
"Rauli Ruohonen" <[EMAIL PROTECTED]> wrote:
>
> On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Whether or not there exists a tool to convert from Python 2.6 to
> > Python 3.0 (2to3), every tool that currently handles Python source
> > code encodings via the method specified in the docum
> Sincere question: if these characters aren't needed, why are they
> provided? From what I can tell by googling, they're needed when, e.g.,
> Arabic is embedded in an otherwise left-to-right script. Do I have
> that right?
I think not. In principle, each character has a directionality
(available
On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Whether or not there exists a tool to convert from Python 2.6 to
> Python 3.0 (2to3), every tool that currently handles Python source
> code encodings via the method specified in the documentation
> (just about every Python-centric editor I kno
"Rauli Ruohonen" <[EMAIL PROTECTED]> wrote:
> On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > """
> > If a comment in the first or second line of the Python script matches
> > the regular expression coding[=:]\s*([-\w.]+), this comment is processed
> > as an encoding declaration; the firs
On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> """
> If a comment in the first or second line of the Python script matches
> the regular expression coding[=:]\s*([-\w.]+), this comment is processed
> as an encoding declaration; the first group of this expression names the
> encoding of the
"Rauli Ruohonen" <[EMAIL PROTECTED]> wrote:
> On 5/27/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> >James Y Knight writes:
> >> a 'pyidchar.txt' file with a list of character ranges, and now that
> >> pyidchar.txt file is going to have separate sections based on module
> >> name? Sorry, bu
On 6/2/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> (1) Add a mandatory ASCII-only special comment at the beginning of
> each module. The comment would continue until the first empty
> line and would contain only valid directives matching some
> regular expression. Only whitespace is
On 5/27/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>James Y Knight writes:
>> a 'pyidchar.txt' file with a list of character ranges, and now that
>> pyidchar.txt file is going to have separate sections based on module
>> name? Sorry, but are you [EMAIL PROTECTED] kidding me?!?
>
>The scalab
On Tue, May 29, 2007, Ivan Krsti?? wrote:
>
> I haven't had time to participate in this discussion though I've been
> following it; FWIW, I'm a loud -1 on Unicode identifiers by default for
> just about the exact reasons that Ping enumerated.
Considering that OLPC is given as an argument in favor
Stephen J. Turnbull wrote:
> Ie, we proponents want to allow programs
> that look familiar to native speakers of various languages, but do not
> look familiar to monolingual speakers of American English.
That characterization is overly narrow. I speak and write at least three
languages including E
Ka-Ping Yee writes:
> Would the display of source code be affected this way as well?
Of course! That's what PEP 3131 proponents *want*. From the draft
you cite: "certain phenomena in this relationship may look strange to
somebody not familiar with bidirectional behavior, but familiar to
users
On Mon, 28 May 2007, Stephen J. Turnbull wrote:
> Now, identifiers are by definition character streams. If an English
> speaker would pronounce the spelling of an English word "A B C", and
> an Arabic speaker an Arabic word as "1 2 3", then *as an identifier*
> the combination English then Arabic
Greg Ewing writes:
> Stephen J. Turnbull wrote:
> > If an English speaker would pronounce the spelling of an English
> > word "A B C", and an Arabic speaker an Arabic word as "1 2 3",
> > then *as an identifier* the combination English then Arabic is
> > spelled "A B C _ 1 2 3".
> But woul
1 - 100 of 295 matches
Mail list logo
