Rauli Ruohonen writes:
> On 6/9/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > Rauli Ruohonen writes:
> > > The ones it absolutely prohibits in interchange are surrogates.
> >
> > Excuse me? Surrogates are code points with a specific interpretation
> > if it is "purported that the
Guido van Rossum schrieb:
> On 6/9/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> 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 particul
> 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
> 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.
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
>> "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
> 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
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
> 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
> 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
>> 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
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,
>>
>> 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
> 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
_
>> 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
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
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
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 for reviews. I've also removed traces
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
>
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
and hex() to 0x?
--Guido
On 6/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > PEP 3127 (Integer Literal Support and Syntax) introduces new notations
> >
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
> and hex() to 0x?
Would that also require a __bin__() special method?
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no l
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
> > and hex() to 0x?
>
> Would that also require a __bin__() special method?
If the other two
--- 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
--- "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.
>
>> 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
> 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
--- "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
>
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
>>> and hex() to 0x?
>> Would that also require a __bin__() special
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
29 matches
Mail list logo
