Steve Howell writes:
> respect to Kanji, and switches over to Python, and
> changes his little wrapper shell script to say "python
> -U" instead of "ruby -Kkcode"? He could then start to
> use non-Japanese Python modules while still writing
> his own Python code in Japanese.
But that's not
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> People who want to use the feature would have to know that it is only
> >> present if you turn it on. It's like saying "you can use hexadecimal
> >> integer literals, but you have to turn them on". This wouldn't work:
> >> people try to use them, f
>> People who want to use the feature would have to know that it is only
>> present if you turn it on. It's like saying "you can use hexadecimal
>> integer literals, but you have to turn them on". This wouldn't work:
>> people try to use them, find out that it won't work, and assume
>> that it's no
On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > The only issues PEP 3131 should be concerned with *defining*
> > are those that cause problems with canonicalization, and the range of
> > characters and languages allowed in the standard library.
>
> Fair enough -- but the problem is that this
On 5/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> a default character set that is allowed. The only character set that
> makes sense as a default, ignoring previously-existing environment
> variables (which don't necessarily help us), is ascii.
This is ignoring the movement in the last 5-10
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee schrieb:
> > On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L�wis" wrote:
> >> Please *do* consider the needs of the people who want to actively
> >> use the feature as well. Otherwise, you have no chance of understanding
> >> what will ma
> Is your concern just that it should be possible to do once (perhaps at
> install), rather than on each run?
My concern is that people assume that you can't use non-ASCII
identifiers if they try it out and it doesn't work. If they believe
the feature is not there, that's just as if it really wasn
Ka-Ping Yee schrieb:
> On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L�wis" wrote:
>> Please *do* consider the needs of the people who want to actively
>> use the feature as well. Otherwise, you have no chance of understanding
>> what will make everyone happy.
>
> People who want to use the feature
> Perhaps a letter in the encoding declaration is non-ascii, nullifying
> the encoding enforcement and allowing a cyrillic 'a' in allowed = 0?
I see. Of course, if I receive a patch where one of the lines changed
is the coding declaration, and there is no apparent difference between
the old and t
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 5/24/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > To pit this as "ascii lovers vs. non-ascii lovers" is a pretty large
> > oversimplification. You could name them "people who want to be able
> > to know what the code says" and "people who don't
--- Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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.
>
>
On 5/24/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> To pit this as "ascii lovers vs. non-ascii lovers" is a pretty large
> oversimplification. You could name them "people who want to be able
> to know what the code says" and "people who don't mind not being able
> to know what the code says". Or
On 5/24/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Last call for discussion! I'm tempted to reject this -- the ability to
> > generate optimized code based on the shortcut semantics of and/or is
> > pretty important to me.
>
> Please don't be hasty. I've had to think
--- Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Steve Howell wrote:
> > I think now that PEP 3131 has been accepted, you
> can coarsely frame
> > the remaining conflict as between ascii lovers and
> non-ascii lovers
>
> To pit this as "ascii lovers vs. non-ascii lovers"
> is a pretty large
> oversi
Guillaume Proux wrote:
> It is my understanding that the only remaining objection for unicode
> in identifier is for claimed security issues.
You're missing much of the debate. Please read this message:
http://mail.python.org/pipermail/python-3000/2007-May/007855.html
Steve Howell wrote:
>
Hello,
On 5/25/07, Steve Howell <[EMAIL PROTECTED]> wrote:
> willingness to tolerate lack of ASCII purity. Coudn't
> Python sniff those out?
On my Linux machine, my encoding is set to UTF8 (and I am sure that
most monolingual Ubuntu user have the same settings). On my Windows
PC, Unicode is the
Guido van Rossum wrote:
> Last call for discussion! I'm tempted to reject this -- the ability to
> generate optimized code based on the shortcut semantics of and/or is
> pretty important to me.
Please don't be hasty. I've had to think about this issue
a bit.
The conclusion I've come to is that t
Hi Jim,
On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> It isn't strictly security; when I've been burned by cut-and-paste
> that turned out to be an unexpected character, it didn't cause damage,
> but it did take me a long time to debug.
Can you give a longer explanation because I don't under
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
>
> The additional burden that ascii loving people would
> like to impose on
> the rest of the world through the usage of command
> line switches is
> unwanted IMHO.
>
I think now that PEP 3131 has been accepted, you can
coarsely frame the remainin
On 5/24/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> It is my understanding that the only remaining objection for unicode
> in identifier is for claimed security issues.
It isn't strictly security; when I've been burned by cut-and-paste
that turned out to be an unexpected character, it didn't
Hello,
There has been many proposals of flags around.
I don't even understand anymore which -U you are talking about now.
But let me add my own proposal for a flag. (just to confuse everybody
else a little more)
It is my understanding that the only remaining objection for unicode
in identifier i
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> -2. Any solution found must also accommodate users
> which are unaware
> of the security issue, and just want to use their
> native language
> for identifiers. So requiring them to change their
> environment or
> pass additional command line pa
On 5/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
> Operators) by Greg Ewing. I am of two minds of this -- on the one
> hand, it's been a long time without any working code or anything. OTOH
> it might be quite useful to e
I'm accepting PEP 3119 (Abstract Base Classes). The latest round of
feedback has been sufficiently friendly that I am confident that it
will be a welcome addition. There are some loose ends in the PEP which
I will resolve while implementing it.
This means I'm also rejecting the main competing prop
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > FWIW the Ruby interpreter (1.8.5) seems to require
> > this flag to allow you to turn on the Japanese
> code
> > set.
> >
> > -Kkcode specifies KANJI (Japanese) code-set
> >
> > I have no idea whether or not this cripples the
> > feature i
On 5/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee schrieb:
> > On Thu, 24 May 2007, Jim Jewett wrote:
> >> So how about
> >> (1) By default, python allows only ASCII.
> >> (2) Additional characters are permitted if they appear in a table
> >> named on the command line.
> >>
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> Please *do* consider the needs of the people who want to actively
> use the feature as well. Otherwise, you have no chance of understanding
> what will make everyone happy.
People who want to use the feature can turn it on. I don't see
On 24-May-07, at 3:33 PM, Martin v. Löwis wrote:
>> Alas, the coding directive is not good enough. Have a look at this:
>>
>> http://zesty.ca/python/tricky.png
>>
>> That's an image of a text editor containing some Python code. Can
>> you
>> tell whether running it (post-PEP-3131) will del
Ka-Ping Yee schrieb:
> On Thu, 24 May 2007, Jim Jewett wrote:
>> So how about
>>
>> (1) By default, python allows only ASCII.
>> (2) Additional characters are permitted if they appear in a table
>> named on the command line.
>>
>> These additional characters should be restricted to code points la
> Alas, the coding directive is not good enough. Have a look at this:
>
> http://zesty.ca/python/tricky.png
>
> That's an image of a text editor containing some Python code. Can you
> tell whether running it (post-PEP-3131) will delete your .bashrc file?
I would think that it doesn't (i.e.
On May 24, 2007, at 2:14 PM, Jim Jewett wrote:
> The Tech Reports seem to suggest NFKD -- and that makes a certain
> amount of sense. Using compatibility characters reduces the problem
> with equivalent characters that are distinct only for historical
> reasons. Using decomposed characters sim
On May 24, 2007, at 5:04 PM, Ka-Ping Yee wrote:
>> (1) By default, python allows only ASCII.
>> (2) Additional characters are permitted if they appear in a table
>> named on the command line.
>
> +1! This is a fine solution. It is better than the "python -U"
> option I proposed -- it has all th
On Thu, 24 May 2007, Stephen J. Turnbull wrote:
> I'll tell you why Ka-Ping's argument is a strawman. First, one only
> *needs* to be able to distinguish those characters that one can read.
> It's nice to be able to admire the rest, of course, but you don't need
> to see them as a speaker of that
On Thu, 24 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > Much of my concerns could be addressed through the use of commandline,
> > environment variable, or in-source code definitions of what are
> > allowable identifier characters.
[...]
> Not sure (anymore) what problem you are trying to so
On Thu, 24 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > That's not true. In the Unicode BMP fallback font, you can easily
> >> differentiate all Unicode characters (in the BMP):
> >>
> >> http://scripts.sil.org/UnicodeBMPFallbackFont
> >
> > Er... somehow I don't think that's what Martin had
On Thu, 24 May 2007, Jim Jewett wrote:
> So how about
>
> (1) By default, python allows only ASCII.
> (2) Additional characters are permitted if they appear in a table
> named on the command line.
>
> These additional characters should be restricted to code points larger
> than ASCII (so you can'
On 5/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Much of my concerns could be addressed through the use of commandline,
> > environment variable, or in-source code definitions of what are
> > allowable identifier characters. Generally, in-source definitions (like
> > the coding: direct
> FWIW the Ruby interpreter (1.8.5) seems to require
> this flag to allow you to turn on the Japanese code
> set.
>
> -Kkcode specifies KANJI (Japanese) code-set
>
> I have no idea whether or not this cripples the
> feature in Ruby, and perhaps it's an apples/oranges
> comparison.
If you don'
> Much of my concerns could be addressed through the use of commandline,
> environment variable, or in-source code definitions of what are
> allowable identifier characters. Generally, in-source definitions (like
> the coding: directive) are the most flexible, but are the biggest pain
> for editor
> That's not true. In the Unicode BMP fallback font, you can easily
>> differentiate all Unicode characters (in the BMP):
>>
>> http://scripts.sil.org/UnicodeBMPFallbackFont
>
> Er... somehow I don't think that's what Martin had in mind
> when he used the word "font" in that context. :-)
That mig
On 5/24/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > I would like an alert (and possibly an import exception) on any code
> > whose *executable portion* is not entirely in ASCII.
> Are you talking about language definition or implementation? I like
> the idea of
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson writes:
> > Removing those words that some found offensive, perhaps I will get a
> > reponse to the point of my post: "your tools aren't very good" and
> > "Emacs does it right" are not valid responses to the concerns brought up
On 5/24/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> I have actually worked in an environment where you can't visually
> distinguish different characters. Security aside, it's a PITA, and
> you *do* want tools to deal with it. ...
> simply audit the editor buffer for characters outside o
Steve Howell writes:
> Then, for all the other classes of users (Dutch tax
> lawyer who still doesn't want Sanskrit, etc.), do you
> advocate having multiple convenient ways to specify
> their desired character set (command line flag, env
> setting, magic directive at top of file, etc.), or d
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> I'd make it more tedious and more flexible to relax
> the restriction,
> actually. "python" gives you the stdlib, ASCII-only
> restriction.
> "python -U TABLE" takes a mandatory argument, which
> is the table of
> allowed characters.
Now
On 5/24/07, Steve Howell <[EMAIL PROTECTED]> wrote:
> -Kkcode specifies KANJI (Japanese) code-set
>
Isn't it to simply let Ruby know which is the actual codepage
(encoding) in which the file is encoded?
Regards,
Guillaume Proux
Scala
___
Python-3000
Jim Jewett writes:
> I would like an alert (and possibly an import exception) on any code
> whose *executable portion* is not entirely in ASCII.
Are you talking about language definition or implementation? I like
the idea of such checks, as long as they are not mandatory in the
language and ca
Ka-Ping Yee writes:
> On Wed, 23 May 2007, Stephen J. Turnbull wrote:
> > > It means users could see the usability benefits of PEP3131, but the
> > > python internals could still work with ASCII only.
> > But this reasoning is not coherent. Python internals will have no
> > problems with
Neil Toronto writes:
> Though I don't develop an editor in my spare time, I had a similar
> reaction to the "Emacs does Unicode this way, which is correct"
> solutions. My favorite editor is going to have to get awfully smart.
It isn't. It will need to learn about widechars, which is painfu
Josiah Carlson writes:
> Removing those words that some found offensive, perhaps I will get a
> reponse to the point of my post: "your tools aren't very good" and
> "Emacs does it right" are not valid responses to the concerns brought up
> regarding unicode.
You're missing my point still, and
Martin v. Löwis wrote:
> That's not true. In the Unicode BMP fallback font, you can easily
> differentiate all Unicode characters (in the BMP):
>
> http://scripts.sil.org/UnicodeBMPFallbackFont
Er... somehow I don't think that's what Martin had in mind
when he used the word "font" in that contex
>>> This particular excuse pisses me off the most. "If you can't
>>> differentiate, then your font or editor sucks." Thank you for passing
>>> judgement on my choice of font or editor, but Ka-Ping already stated
>>> why this argument is bullshit: there does not currently exist a font
>>> where on
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [...]
> > 2. "python" allows only ASCII identifiers.
> "python -U" allows
> > Unicode identifiers that are in NFC and
> use a conservative,
> > *fixed* subset of the available
> characters. Support for
> > "-U" is a
Josiah Carlson writes:
> Thank you for hitting home that unless people use Emacs, their tools
> suck.
I'm sorry you took it that way. My experience is limited to Emacs;
that's the only experience I can describe.
If you can tell the story of a maintainer of a package that contains
multilingual
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > This particular excuse pisses me off the most. "If you can't
> > differentiate, then your font or editor sucks." Thank you for passing
> > judgement on my choice of font or editor, but Ka-Ping already stated
> > why this argument is bullshit: ther
55 matches
Mail list logo
