[Python-3000] Support for PEP 3131

[Leonardo Santagada]

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-ASCII
> identifiers to the wider public. Something that we agree is a bad  
> idea, don't we?

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 they  
have taxes in china, but that is not the point). And not even that,  
in a school you would have to have all computers and students  
computers configured for the same "locale" to make a working code on  
one machine work in another

>
>>> We believe that we should try to make it easier, not harder, for
>>> programmers to understand what Python code says.  This has many
>>> benefits (reliability, readability, transparency, reviewability,
>>> debuggability).  I consider these core strengths of Python.
>>
>> 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  
> developper
> himself when he rereads his own code (which I value as a  
> developper), or
> transparent to the user of the program when he tries to fix a bug  
> (which I value
> as a user of open-source software) ? Non-ASCII identifiers are  
> marginally better
> for the first case, but can be dramatically worse for the second  
> one. Clearly,
> there is a tradeoff.

No they are not, people doing open source work are probably going to  
still be coding in english so that is not a problem, but that chinese  
tax system if it is open sourced people in china can easily help  
fixing bugs because identifiers are in their own language, which they  
can identify.

>
>>> That is what makes these strengths so important.  I hope this
>>> helps you understand why these concerns can't and shouldn't be
>>> brushed off as "paranoia" -- this really has to do with the
>>> core values of the language.
>>
>> It just seems that the concerns don't directly follow from
>> the principles. Something else has to be added to make that
>> conclusion. It may not be paranoia (i.e. excessive anxiety),
>> but there surely is some fear, no?
>>
> That argument is not really honest :-) Every risk can be estimated  
> opimistically
> or pessimistically. In both cases, there is some part of  
> irrationallity.

The thing is, people are predicting a future for python code on the  
open source world. One in which devs of open source libraries and  
programs will start coding in different languages if you support  
unicode identifiers, something that is not common today (using some  
form of ASCIIfication of their languages) and didn't happen with the  
Java, C#, Javascript and Common Lisp communities. In light of all  
that I think this prediction is probably wrong. 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.  
What do you have to support your prediction?

--
Leonardo Santagada
"If it looks like a duck, and quacks like a duck, we have at least to  
consider the possibility that we have a small aquatic bird of the  
family anatidae on our hands." - Douglas Adams