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 withou
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
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
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
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
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
BJörn Lindqvist a écrit :
>> Those most eager for unicode identifiers are afraid that people
>> (particularly beginning students) won't be able to use local-script
>> identifiers, unless it is the default. My feeling is that the teacher
>> (or the person who pointed them to python) can change the
James Y Knight a écrit :
> there will be a "second class" of python modules that won't work on
> some systems without extra pain.
>
modules using unicode identifier *will be* second class anyway, because most
people won't be able to debug them in case of need. However, this does not
matter for
Guillaume Proux a écrit :
> (I mistakenly replied in private. here is a copy for the py3000 mailing list.)
>
>
> Good evening!
>
> On 5/26/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> You're missing "here is this neat code from sourceforge", or "Here is
>> something I cut-and-pasted from ASPN".
Guillaume Proux a écrit :
> I think Martin's and my point is that to get people to level E) there
> is no reason to put any charset restriction on level A ->D. And when
> you are at level E), it is difficult to argue that making a one-time
> test at source code checkin time is a bad practice.
>
yo
Guido van Rossum a écrit :
>
> If there's a security argument to be made for restricting the alphabet
> used by code contributions (even by co-workers at the same company), I
> don't see why ASCII-only projects should have it easier than projects
> in other cultures.
>
there is only one valid re
Martin v. Löwis a écrit :
>
> I don't think there is precedence in Python for such an informational
> error message. It is not pythonic to give an error in the case
> "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
Georg Brandl a écrit :
> Baptiste Carvello schrieb:
>> Guido van Rossum a écrit :
>>> Do people think it would be too radical if the built-in open()
>>> function was removed altogether, requiring all code that opens files
>>> to import the io module first? T
Guido van Rossum a écrit :
> On 5/18/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum a écrit :
>>> Do people think it would be too radical if the built-in open()
>>> function was removed altogether, requiring all code that opens files
>&g
Guido van Rossum a écrit :
> Do people think it would be too radical if the built-in open()
> function was removed altogether, requiring all code that opens files
> to import the io module first? This would make it easier to identify
> modules that engage in I/O.
>
-1
Will someone think of the i
Jason Orendorff a écrit :
>
> Python should allow foreign-language identifiers because (1) it's a
> gesture of good will to people everywhere who don't speak English
> fluently; (2) some students will benefit; (3) some people writing code
> that no one else will ever see will benefit.
>
As I sa
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
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:
Bill Janssen a écrit :
>> Jeffrey, is there any way you can drop the top of the tree and going
>> straight from Number to Complex -> Real -> Rational -> Integer? These
>> are the things that everyone with high school math will know.
>
> I think knowledge of the concepts of group, ring, and field i
Aahz a écrit :
> IIRC, there was some discussion about removing single-line blocks like
> this one in 3.0:
>
> if foo: bar()
>
> However, I can't find any discussion about making it happen, and it's
> not in PEP 3099. Guido, does this need a PEP? Do you want it to happen?
please no.
Singl
Patrick Maupin a écrit :
> A string
> replace on a data file is actually much easier than on a code file,
> and it really is a one-liner, so the potential existence of upper case
> 'X' in the data file does not seem like reason enough to make these
> different.
>
you don't analyse data files for
Guido van Rossum a écrit :
> I'd say the same rule -- lowercase only.
>
> On 3/17/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
>> What about 'e' for exponentiation?
>>
>
I guess it's already implied, but just for the record: capital E is very popular
in data files, so it has to still work with
Brett Cannon a écrit :
> But compile (along wth exec, but I don't think you wanted to move that)
> are just plain different. Dynamic code execution is its own thing that
> I do not directly associate with the specifics of the interpreter.
> Maybe a module named 'dynamic' or 'execution'?
>
bt
Tim Hochberg a écrit :
>
> Here goes: to the extent that the semantics aren't clear from the
> methods it is sufficient, and preferable, to attach the semantic
> information to the methods rather their associated class.
>
which imho is the whole of the question: which level of granularity is
d
Bill Janssen a écrit :
>
> I see nothing wrong with defining "empty" ABCs to indicate abilities
> rather than interfaces.
>
>class WellTested (Ability):
> """Indicates that the type has passed the QA process"""
> pass
>
>class TestedNumber (Number, WellTested):
> ...
>
An
> If 'callable' is to stay, then in order to pull its weight it needs to
> grow to provide a way to check "callable with the following signature"
> -- at the very least in terms of numbers and names of arguments,
> though (if py3k does gain some syntax for specifying argument types)
> it might do m
> > Here's a related but more complicated wish: define a function in such
> > a way that certain parameters *must* be passed as keywords, *without*
> > using *args or **kwds. This may require a new syntactic crutch.
>
> While a number of people have submitted possible use cases for this
> feat
Oleg Broytmann a écrit :
> On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
>
>>i.e., "is the object addable?" == "hasattr(obj, '__add__')".
>
>
>Even this is meaningless: '1'+1. So duck typing is:
>
> try:
>return a+b
> except TypeError:
>return "Oops..."
>
>
Well, w
Ron Adam a écrit :
> Raymond Hettinger wrote:
>>I forsee {} vs {/} as being a prominent entry on everyone's list of Python
>>pitfalls, faqs, and common errors. Maybe PyLint or PyChecker will be able to
>>scan to see how the object is used and determine whether the two were
>>mixed-up.
>>
>
> I
Greg Ewing a écrit :
> Jim Jewett wrote:
>
>
>>It has not yet been specified what would happen to additional
>>positional arguments that get passed in anyway. (Swallow or raise an
>>Exception?)
>
>
> I've always intended that there would be an exception.
>
If so, why not replace the lone star
Raymond Hettinger a écrit :
> [Brian Harring]
>
>>The issue I'm seeing is that the wart you're pointing at is a
>> general issue not limited to strings- everyone sooner or later
>> has flattening code that hits the "recursively iterate over
>> this container, except for instances of these classes
34 matches
Mail list logo
