Jim Jewett writes:
> On 6/11/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > But this is something that only a small subset of developers-of-Python
> > seem to be concerned about.
This is a statement about the politics of changing an accepted PEP.
Without massive outcry, ain' agonna ha
Rauli Ruohonen writes:
> In my mind everything in a Python program is within a single
> Unicode process,
Which is a *serious* mistake. It is *precisely* the mistake that
leads to mixing UTF-16 and UCS-2 interpretations in the standard
library. What you are saying is that if you write a 10-lin
>> 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 more useful code
>
--- Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Steve Howell <[EMAIL PROTECTED]>
> wrote:
>
> > In my best franglais: je pense que les avocats de
> PEP
> > 3131 pourrait surmonter la doute, l'incertitude,
> le
> > crainte, etc., de PEP 3131 en montrant les
> exemples.
>
> Not really; I t
On 6/12/07, Steve Howell <[EMAIL PROTECTED]> wrote:
> In my best franglais: je pense que les avocats de PEP
> 3131 pourrait surmonter la doute, l'incertitude, le
> crainte, etc., de PEP 3131 en montrant les exemples.
Not really; I think everyone agrees that you *can* produce
well-written code wi
On 6/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ok, but why need you then *Python* to tell you that the file has
> non-ASCII identifiers? Just look inside the file, and see whether
> you like its source code.
That is just what many users (including, in some environments, me)
cannot do
--- Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>
> si tu me prends par les sentiments :-) Really, you
> make it sound so nice I would
> almost change my mind. Still wondering how much of
> an effort it will be, though.
>
I would again make a call out for actual examples of
what Python code w
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]>
wrote:
> Ka-Ping Yee writes:
> > Both of these come down to the wastefulness of
> redoing something
> > that the Python interpreter itself already knows
> how to do very
> > well, and is, in some sense by definition, the
> authority on how
> > to d
On 6/11/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > Of course, I wouldn't type them if I knew they were wrong. With an
> > ASCII-only install, I would get that error-check because the
> > (remaining original uses) were in Cyrillic. With an "any unicode
> > cha
On 6/11/07, Michael Urman <[EMAIL PROTECTED]> wrote:
> I can't agree with this. The predictability of needing only to
> duplicate dependencies (version of python, modules) to ensure a
> program that ran over there will run over here (and vice versa) is too
> important to me.
This provides almost
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 without going
>> through the complex task of tra
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 policy would extend to libraries
>>> that you
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
[crossposting to python-3000]
Martin v. Löwis schrieb:
[removing string->string codecs]
>>> You're not losing functionality -- these conversions will remain
>>> available by importing the appropriate module. You're losing a very
>>> minor amount of convenience.
>>
>> Of the mentioned encodings
On 6/12/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 6/12/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> > > Practically speaking, there's little need to interpret
> > > surrogate pairs as two code points instead of as one
> > > non-BMP c
On 6/11/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Michael Urman a écrit :
> > ... you already cannot visually inspect ...
> > There is the risk of visually aliased identifiers, but how is that
> > qualitatively worse than the truly conflicting identifiers you can
> > import with a *, or h
At 07:18 PM 6/11/2007 -0400, Phillip J. Eby wrote:
>The subclass might look something like this:
>
> import imp, os, sys
> from pkgutil import ImpImporter
>
> suffixes = set(ext for ext,mode,typ in imp.get_suffixes())
>
> class CachedImporter(ImpImporter):
> def __init_
Ka-Ping Yee wrote:
>
> Hang on a second. No one is *imposing* new restrictions. Python
> uses ASCII-only identifiers today and has always been that way.
That restriction clearly wasn't imposed on the standard www.python.org windows
distributions of Python - for quite a few versions already. Se
On 6/12/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> Another example would be unichr(), which gives you TypeError if you
> pass it a surrogate pair (oddly enough, as strings of different length
> are of the same type).
Sorry, I meant ord(), not unichr. Anyway, ord(unichr(i)) == i doesn't
work f
On 6/12/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> > Practically speaking, there's little need to interpret surrogate pairs
> > as two code points instead of as one non-BMP code point.
>
> Depends on your definition of "practically".
>
> Pyth
On 6/12/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote:
> Practically
> speaking, there's little need to interpret surrogate pairs as two
> code points instead of as one non-BMP code point.
Depends on your definition of "practically".
Python does interpret them that way to maintain O(1) positional
Ka-Ping Yee writes:
> On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:
> > It seems to me that rather than *impose* restrictions on third
> > parties, the sensible thing to do is to provide those restrictions to
> > those who want them.
>
> Hang on a second. No one is *imposing* new restric
Rauli Ruohonen writes:
> I don't know any Chinese, but real Chinese is much more legible to me
> than transliterated one. Transliterations are complete gibberish to me,
And will be to most Chinese, too, unless Mandarin is used, since
pronunciation varies infinitely from dialect to dialect, alth
On 6/10/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> I think you misunderstand. Anything in Unicode that is normative is
> about interchange. Strings are also a means of interchange---between
> modules (separate Unicode processes) in a program (single OS process).
Like Martin said, "what
On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:
> It seems to me that rather than *impose* restrictions on third
> parties, the sensible thing to do is to provide those restrictions to
> those who want them.
Hang on a second. No one is *imposing* new restrictions. Python
uses ASCII-only identifi
On Tue, 12 Jun 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> Also, that all identifiers are ASCII is not sufficient
> for you to be able to debug the program in case of need: it also
> needs to be commented well, and the comments also should be in
> a language you understand. Furthermore, it has be
Guido van Rossum wrote:
> On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >> The os.environ.get() method probably should return a unicode
>> string. (?)
>> >
>> > Indeed -- care to contribute a patch?
>>
>> Ideally, such a patch would make use of the Win32 Unicode API for
>> environment
27 matches
Mail list logo
