> Ruby is a language that presumably has a lot of
> Japanese users, and it appears to me (I'm not a Ruby
> person, so I admit this is speculation) that Japanese
> users have to explicitly choose to use Japanese
> encoding to run source files encoded in Japanese.
>
> Setting aside all the limitatio
> In almost every programming situation I've been in,
> I've had to deal with environmental issues, even
> though my character set of choice has never been the
> primary issue.
People can certainly adjust to whatever challenges
technology confronts them with (some people can do
that easier, some h
> However you characterize them, keep in mind that those in the former
> group are asking for default behaviour that 100% of Python users
> already use and understand. There's no cost to keeping identifiers
> ASCII-only because that's what Python already does.
How does adding conditionality make
>> People should not have to read long system configuration pages
>> just to run the program that they intuitively wrote correctly
>> right from the start.
>
> You mean that 5% of users who run into code written using non-ascii
> identifiers will find this sufficiently burdensome to force the 95%
From a user's POV, I'm +1 on having overloadable boolean functions. In many
cases I had to resort to overload add or neg instead of and & not, I foresee
a lot of cases where the and overload could be used to join objects which
represent constraints. Overloadable boolean operators could also be us
On 5/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "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.
On Thu, 24 May 2007, Guido van Rossum 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.
This keeps get
On Fri, 25 May 2007, [UTF-8] "Martin v. L??wis" wrote:
> Ka-Ping Yee schrieb:
> > On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L???wis" wrote:
> > People who want to use the feature can turn it on. I don't see what's
> > so unreasonable about that.
>
> People who want to use the feature would have
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > I think there are things that can be done here, even
> > if we make Python's default mode to be ascii-pure.
> > Regional distros can set the environment
> > appropriately. Python error messages about non-ascii
> > characters can sugges
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> I don't think there is precedence in Python for such an informational
> error message.
SyntaxError: Non-ASCII character '\xd1' in file foo.py on line 2, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for
details
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> 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 ident
On Fri, 25 May 2007, Guillaume Proux wrote:
> 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)
If there must be a flag,
Jim Jewett writes:
> Definition; I don't care whether it is a different argument to import
> or a flag or an environment variable or a command-line option, or ...
> I just want the decision to accept non-ASCII characters to be
> explicit.
Ka-Ping's tricky.py shows that reliance on magic direc
James Y Knight writes:
> > - The identifier character set won't spontaneously change when
> > one upgrades to a new version of Python, even for users of
> > non-ASCII identifiers.
>
> FUD. Already won't, unicode explicitly makes that promise. They can
> add characters, but
"Martin v. Löwis" writes:
> > If people can agree on a method for specifying, 'ascii only', 'ascii +
> > character sets X, Y, Z', and it actually becomes an accepted part of the
> > proposal, gets implemented, etc., I will grumble to myself at home, but
> > I will stop trying to raise a stink
Guido van Rossum writes:
> 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.
(1) Because all projects are
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> 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
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > In almost every programming situation I've been
> in,
> > I've had to deal with environmental issues, even
> > though my character set of choice has never been
> the
> > primary issue.
>
> People can certainly adjust to whatever challenges
> t
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
> If you look at the typical use case for programs
> written in python
> (usually also in rough order of experience)
> A) directly in interpreter (i love that)
> B) small-ish one-off scripts
> C) middle size scripts
> D) multi-module programs made by
One issue with the command line argument (and that unfortunately
applies ONLY to the -U case) that i haven't seen properly answered to
is..
On 5/25/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> SyntaxError: 'non-ASCII identifier: invalid unless enabled with the -U option'
Am I the only per
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,
> *plus* you need to understand
On 5/24/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Where else in Python have we made the default
> behavior only desired or useful to 5% of our users?
Where are you getting that statistic? This seems an extremely
backwards, US-centric worldview.
--
--Guido van Rossum (home page: http://www.
On Friday, May 25, 2007, at 03:03PM, "Steve Howell" <[EMAIL PROTECTED]> wrote:
>
>
>Remember, you and I have no disagreement whatsoever
>about what the Python code looks like. I look forward
>to seeing beautiful code written in French, Korean,
>etc. under PEP 3131, and I have not opposed anythin
On 5/24/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> 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 t
On 5/24/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> I have a hard time seeing how you could sniff out the willingness to
> accept in a Japanese environment, a piece of code written in Russian
> because your buddy from Siberia has written this cool matrix class
> that is 30% faster than most b
Steve Howell writes:
> What I was trying to say here is that there might be
> precedent for non-ascii users already tolerating
> command line arguments.
It's an idea, but it turns out not to correspond to reality. It only
shows there's a precedent for Japanese tolerating command line
argumen
On 5/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It doesn't look like any kind of global flag passed to the interpreter
> would scale -- once I am using a known trusted contribution that uses
> a different character set than mine, I would have to change the global
> setting to be more len
At 11:25 AM 5/25/2007 +0200, Neville Grech Neville Grech wrote:
> >From a user's POV, I'm +1 on having overloadable boolean
> functions. In many cases I had to resort to overload add or neg
> instead of and & not, I foresee a lot of cases where the and
> overload could be used to join objects wh
On May 25, 2007, at 11:37 AM, Jim Jewett wrote:
> You're missing "here is this neat code from sourceforge", or "Here is
> something I cut-and-pasted from ASPN". If those use something outside
> of ASCII, that's fine -- so long as they tell you about it.
>
> If you didn't realize it was using non-
(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". If those use something outside
> of ASC
On 5/25/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> If you look at the typical use case for programs written in python
> (usually also in rough order of experience)
> A) directly in interpreter (i love that)
> B) small-ish one-off scripts
> C) middle size scripts
> D) multi-module programs ma
Guillaume Proux writes:
> Am I the only person on Earth to routinely start my python programs by
> double clicking on them??
Surely not. So? If your python programs have non-ASCII identifiers
in them, they'll crash when you double-click them. So I suspect you
have no programs now where there
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 5/24/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Where else in Python have we made the default
> > behavior only desired or useful to 5% of our users?
>
> Where are you getting that statistic? This seems an extremely
> backwards, US-cent
On 5/25/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > ... range of characters and languages allowed ...
> > Fair enough -- but the problem is that this isn't a solved issue
> > yet; the unicode group themselves make several contradictory
> > r
On 5/26/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> For the medium term, there are ways to pass command line arguments to
> programs invoked by GUI. They're more or less ugly, but your daughter
> will never see them, only the pretty icons.
Is there right now in Windows? There is none th
On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > It doesn't look like any kind of global flag passed to the interpreter
> > would scale -- once I am using a known trusted contribution that uses
> > a different character set than mine,
"Guillaume Proux" <[EMAIL PROTECTED]> wrote:
> On 5/26/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > For the medium term, there are ways to pass command line arguments to
> > programs invoked by GUI. They're more or less ugly, but your daughter
> > will never see them, only the pretty ic
On 5/26/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> wanted to keep my codebase ascii-only (a not unlikely case), I can
So you have a clear preference for an ascii-only way. *YOU* *really*
want to know when a non-ascii identifier crosses your path.
> For those who don't care about ascii or non
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> >> People should not have to read long system configuration pages
> >> just to run the program that they intuitively wrote correctly
> >> right from the start.
> >
> > You mean that 5% of users who run into code written using non-ascii
> > identif
Guillaume Proux writes:
> Is there [a way to pass options to GUI programs] right now in
> Windows? There is none that I know today at least.
Can't you click on .BAT files? (I did say "ugly"!)
___
Python-3000 mailing list
[email protected]
http
On 5/25/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> I think you are forgetting who this feature is intended for.
[I think experienced programmers will in fact use it too, but agree that ...]
> Newbies, on the other hand, would maybe appreciate being able to write:
...
> If Python required a
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| 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
On 5/25/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > Ideally, it would even be explicit per extra character allowed, though
> > there should obviously be shortcuts to accept entire scripts.
> How about a regexp character class as starting point?
I'm not sure I un
On 5/25/07, Steve Howell <[EMAIL PROTECTED]> wrote:
> This happens to me about once a month, and I
> forget exactly what Python does when I try to run the
> program where one identifier has the accented e, and a
> later identifier doesn't.
It *should* throw up a syntax error. If both letters we
On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > If we allowed an underscore as a mixed-script separator
> > (allowing "def get_原料(self):"), does this let us get away
> > with otherwise banning mixed-scripts?
>
> I wondered that, until seeing
On 5/25/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> 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". If those use something outside
> > of ASCII, that's fine -- so long as th
On 5/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I agree that saying "Japanese identifiers are OK from now on" still
> > shouldn't turn on Cyrillic identifiers. I think the current
> > alternative boils down to some variant of
> > wh
On 5/25/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 5/25/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > If we allowed an underscore as a mixed-script separator
> > > (allowing "def get_原料(self):"), does this let us get away
> > > with otherw
On Fri, 25 May 2007, Josiah Carlson wrote:
> Apples and oranges to be sure, but there are no other statistics that
> anyone else is able to offer about use of non-ascii identifiers in Java,
> Javascript, C#, etc.
Let's see what we can find. I made several attempts to search for
non-ASCII identifi
On 25-May-07, at 6:03 AM, Steve Howell wrote:
>
> We're just disagreeing about whether the Dutch tax law
> programmer has to uglify his environment with an alias
> of Python to "python3.0 -liberal_unicode," or whether
> the American programmer in an enterprisy environment
> has to uglify his envi
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
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
Bah - this should have gone to Pyton-3000 too, since it's discussing the
PEP.
Tim Delaney
Tim Delaney wrote:
> Guido van Rossum wrote:
>
>> - This seems to be written from the POV of introducing it in 2.6.
>> Perhaps the PEP could be slightly simpler if it could focus just on
>> Py3k? Then it's
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
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".
On Thu, 24 May 2007, Stephen J. Turnbull wrote:
> > You've got this backwards, and I suspect that's part of the root of
> > the disagreement. It's not that "when humans enter the loop they
> > cause problems." The purpose of the language is to *serve humans*.
[...]
> N.B. I take offense at you
"Guillaume Proux" <[EMAIL PROTECTED]> wrote:
>
> On 5/26/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > wanted to keep my codebase ascii-only (a not unlikely case), I can
>
> So you have a clear preference for an ascii-only way. *YOU* *really*
> want to know when a non-ascii identifier crosse
On 5/25/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> Bah - this should have gone to Pyton-3000 too, since it's discussing the
> PEP.
My fault; I started sending you feedback that only went to you, Calvin
and the PEP editors. I've added [email protected] back here.
> Guido van Rossum wrote:
>
NFKC might be a better choice than NFC for normalizing identifiers.
Do we really want "find()" (with the fi-ligature) and "find()"
(without the fi-ligature) to be two different functions?
Martin, is there a reason to prefer NFC over NFKC?
-- ?!ng
___
P
On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > On 5/25/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > If we allowed an underscore as a mixed-script separator
> > > > (allowing "def
Ka-Ping Yee wrote:
> NFKC might be a better choice than NFC for normalizing identifiers.
> Do we really want "find()" (with the fi-ligature) and "find()"
> (without the fi-ligature) to be two different functions?\
Do we really want to allow ligatures at all?
--
Greg
__
On Sat, 26 May 2007, Greg Ewing wrote:
> Ka-Ping Yee wrote:
> > NFKC might be a better choice than NFC for normalizing identifiers.
> > Do we really want "find()" (with the fi-ligature) and "find()"
> > (without the fi-ligature) to be two different functions?\
>
> Do we really want to allow ligatur
--- Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 5/24/07, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >
> > > It doesn't look like any kind of global flag
> passed to the interpreter
> > > would scale -- once I am using a known trusted
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Baptiste Carvello, in addition to Jim, Ka-Ping,
> Stephen, and myself,
> further discusses why ascii is the only sane default
> in his most recent
> 3 posts.
I will add my much less venerated name to the list of
people who think ascii is the san
--- Steve Howell <[EMAIL PROTECTED]> wrote:
> --- Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > On 5/25/07, Jim Jewett <[EMAIL PROTECTED]>
> wrote:
> > > On 5/24/07, Guido van Rossum <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > It doesn't look like any kind of global flag
> > passed to the in
Terry Reedy wrote:
> I have not seen any response to my suggestion to simplify the to-me overly
> baroque semantics. Missed it? Still thinking? Or did I miss something?
Sorry, I've been meaning to reply, but haven't got around
to it.
> Delete special casing of NotImplemented.
This is the st
Jim Jewett wrote:
> It currently says that __not__ can return NotImplemented, which falls
> back to the current semantics.
I'm not sure why I put that there. As you observe, it's not
necessary, since you can always get the default semantics
simply by not defining the method.
An experiment sugges
Phillip J. Eby wrote:
> Actually, I think that most of the use cases for this PEP would be
> better served by being able to "quote" code, i.e. to create AST
> objects directly from Python syntax.
That's been suggested before, but hasn't received
a favourable response.
One problem is that it wo
On 5/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Is that OK, because "not not X" should now be spelled "bool(x)", and
> > you haven't allowed the overriding of __bool__?
>
> Yes, I would say that 'not not x' should indeed be spelled
> bool(x), if that's what you intend it to mean.
>
> Whethe
Ka-Ping Yee wrote:
> On Fri, 25 May 2007, Josiah Carlson wrote:
>> Apples and oranges to be sure, but there are no other statistics that
>> anyone else is able to offer about use of non-ascii identifiers in Java,
>> Javascript, C#, etc.
> Let's see what we can find. I made several attempts to sear
Jim Jewett wrote:
>>> If you didn't realize it was using non-ASCII (or even that it
>>> could), and the author didn't warn you -- then that is an1
>>> appropriate time for the interpreter to warn you that things aren't
>>> as you expect.
>> I fail to see your point. Why should the interpreter
http://mail.python.org/pipermail/python-checkins/2007-May/060507.html
Hello. I'm using Windows2000, I tried some investigation for
test_ftpwrapper.
After I did this change, most errors were gone.
Index: Lib/urllib.py
===
--- Lib/url
Thank you for the apology. I have cooled off, and I hope you won't
hold the "take offense" against me. I was hurt, for sure, but you're
right, that's a legitimate reading in colloquial English.
Ka-Ping Yee writes:
> That just means, if we're going to provide this feature, we shouldn't
> force
Josiah Carlson writes:
> It does, but it also refuses the temptation to guess that *everyone*
> wants to use unicode identifiers by default. Why? As Stephen Turnbull
> has already stated, the majority of users will have *no use* and *no
> exposure* to unicode identifiers.
I'm afraid I confl
Jim Jewett writes:
> On 5/25/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > If Python required a switch for such a program to run, then this
> > feature would be totally wasted on them. They might use an IDE,
> > program in notepad.exe and dragging the file to the python.exe icon or
> > n
75 matches
Mail list logo
