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
On 6/10/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> pep 3115 (new metaclasses) seems overly complicated imho.
It does look over-engineered to me, too.
> it fails my understanding of "keeping it simple", among other heuristics.
>
> (1)
> the trivial fix-up would be to extend the type constructor
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 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/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/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, 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
Alex Martelli wrote:
>> (2)
>> the second-best solution i could think of is just passing the dict as a
>> keyword argument to the class, like so:
>>
>> class Spam(metaclass = Bacon, dict = {}):
>> ...
>>
>> so you could explicitly state you need a special dict.
>
> I like this one, with classd
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, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 6/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum schrieb:
> >>> Very cool; thanks!!! No problems so far.
> >>>
> >>> I wonder if we need a bin() built-in that is to 0b like oct() is to 0o
> >>
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Still, what is the risk being estimated? Is it that somebody
> maliciously tries to provide patches that use look-alike
> characters? I honestly don't know what risks you see.
Here are the top three that I see; note that none of these conc
On 6/11/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> So instead of being able to write:
>
>class MyStruct(Struct):
> first = 1
> second = 2
> third = 3
>
[...]
>
> Forgive my confusion, but exactly *how* is that meant to be an improvement?
as your example shows, the most com
Guido van Rossum schrieb:
> On 6/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 6/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> >> Guido van Rossum schrieb:
>> >>> Very cool; thanks!!! No problems so far.
>> >>>
>> >>> I wonder if we need a bin() built-in that
Guido van Rossum schrieb:
On 6/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> On 6/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum schrieb:
>>> Very cool; thanks!!! No problems so far.
>>>
>>> I wonder if we need a bin() built-in that is to 0b like oc
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, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > On 6/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum wrote:
> >> > On 6/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> >> Guido van Rossum schrieb:
> >> >>> Very cool; thanks!!! No problems
On Jun 11, 2007, at 4:10 PM, Nick Coghlan wrote:
Alex Martelli wrote:
(2)
the second-best solution i could think of is just passing the dict as a
keyword argument to the class, like so:
class Spam(metaclass = Bacon, dict = {}):
...
so you could explicitly state you need a special dict.
I lik
I'm very tempted to check in my patch even though the PEP isn't
updated (it's been renamed from PEP 367 though). Any objections?
It is python.org/sf/1727209, use the latest (topmost) super2.diff patch.
This would make the new and improved syntax super().foo(), which gets
the class and object from
Georg Brandl schrieb:
> Guido van Rossum schrieb:
>> PEP 3127 (Integer Literal Support and Syntax) introduces new notations
>> for octal and binary integers. This isn't implemented yet. Are there
>> any takers? It shouldn't be particularly complicated.
>
> Okay, it's done.
>
> I'll be grateful fo
On 6/11/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Georg Brandl schrieb:
> > Guido van Rossum schrieb:
> >> PEP 3127 (Integer Literal Support and Syntax) introduces new notations
> >> for octal and binary integers. This isn't implemented yet. Are there
> >> any takers? It shouldn't be particular
Guido van Rossum wrote:
> I'm very tempted to check in my patch even though the PEP isn't
> updated (it's been renamed from PEP 367 though). Any objections?
Sorry - had to go visit family on the long weekend - only got back late last
night.
My only objection is the special-casing of the 'super'
On 6/11/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I'm very tempted to check in my patch even though the PEP isn't
> > updated (it's been renamed from PEP 367 though). Any objections?
>
> Sorry - had to go visit family on the long weekend - only got back late last
>
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
> 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
> 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
> Here are the top three that I see; note that none of these concerns
> say "Don't use non-ASCII ids". They do all say "Don't use ids from a
> script the user hasn't said to expect".
>
> (1) Malicious user is indeed one risk. A small probability, but a
> big enough loss that I want a warning wh
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
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
> 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:
> > 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
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
At 12:46 AM 6/12/2007 +0200, Giovanni Bajo wrote:
>Hi Philip,
>
>I'm going to submit a PEP for Python 3000 (and possibly backported
>as an option off by default in Python 2). It's related to imports
>and how to make them faster. Given your expertise on the subject,
>I'd appreciate if you could r
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
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
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
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
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
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
--- 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
>
On 6/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 12:46 AM 6/12/2007 +0200, Giovanni Bajo wrote:
>Hi Philip,
>
>I'm going to submit a PEP for Python 3000 (and possibly backported
>as an option off by default in Python 2). It's related to imports
>and how to make them faster. Given your ex
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
>
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
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
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
>> 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
>> > 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
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
47 matches
Mail list logo
