James Y Knight writes:
> iso-2022 or some other abomination. This has upsides (simple, doesn't
> trample on PUA codepoints, only needs one new codec, never throws
> exception in the above example, and really is correct much of the
> time), and downsides (if the system locale is iso-2022,
On 9/16/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Thomas Wouters wrote:
> > If you want to put more meaning in the argv list, use an option
> > parser.
>
> I want to put *less* meaning in it, not more. :-)
Then why are you discriminating against argv[0]? It's just another member of
the argv l
On 9/18/07, James Y Knight <[EMAIL PROTECTED]> wrote:
>
> On Sep 18, 2007, at 11:11 AM, Guido van Rossum wrote:
> > If they contain
> > non-ASCII bytes I am currently in favor os doing a best-effort
> > decoding using the default locale encoding, replacing errors with '?'
> > rather than throwing e
On Sep 18, 2007, at 11:11 AM, Guido van Rossum wrote:
> If they contain
> non-ASCII bytes I am currently in favor os doing a best-effort
> decoding using the default locale encoding, replacing errors with '?'
> rather than throwing exception.
One of the more common things to do with command line
On 9/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > On 9/18/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>
> > > > There's no UTF-8 in Python's internal string encoding.
>
> > >
At 09:25 AM 9/19/2007 +1200, Greg Ewing wrote:
>Talin wrote:
> > the ultimate solution to Python concurrency won't be via patching
> > CPython, but to compile the meta-Python language to a back-end
> > representation that is inherently concurrent.
>
>You can't get something for nothing, though --
On 9/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > > There's no UTF-8 in Python's internal string encoding.
> > (At least as of a few days ago)
> > In Python 3 there is; st
Talin wrote:
> the ultimate solution to Python concurrency won't be via patching
> CPython, but to compile the meta-Python language to a back-end
> representation that is inherently concurrent.
You can't get something for nothing, though -- that
"inherently concurrent" back-end representation w
On 9/18/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Guido has stated that the
> internal representation used by Python strings is a sequence of
> Unicode code units, not characters. I don't think that's reached the
> status of "pronouncement" yet, but you will probably need a PEP to get
>
Talin wrote:
> Data Type AbstractSequence Immutable Mutable
> = = ===
> byteByteSequence bytes buffer
> character CharSequence str strbuf
>
> 'buffer' could be an array.array, although if it's used frequently
> enoug
On 9/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>
> > There's no UTF-8 in Python's internal string encoding. What are you
> > talking about?
>
> (At least as of a few days ago)
>
> In Python 3 there is; strings are unicode. A PyUnicod
On 9/18/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> There's no UTF-8 in Python's internal string encoding. What are you
> talking about?
(At least as of a few days ago)
In Python 3 there is; strings are unicode. A PyUnicodeObject object
has two encodings that you can grab from a point
Steven Bethard wrote:
> On 9/17/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Greg Ewing wrote:
>>> Thomas Wouters wrote:
If you want to put more meaning in the argv list, use an option
parser.
>>> I want to put *less* meaning in it, not more. :-)
>>> And using an argument parser is often
> "Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes:
>> > This is wrong: UTF-8 is specified for PUA. PUA is no special from the
>> > point of view of UTF-8.
>
>> It is from the point of view of the Unicode standard, specifically v5.
>> Please see section 16.5, especially about the
On 9/18/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> I'll take it. I assume it's just a matter of removing the mutating
> methods and making the tests pass?
And adding __hash__. And (but this could be a separate, later change)
switch indexing to return 1-char bytes arrays instead of small ints
On Sep 18, 2007, at 12:50 PM, Guido van Rossum wrote:
> No takers? What about those repeated +42 voters? Does anyone want
> immutable bytes enough to do a teensy bit of work?
Dang, Guido! I don't eat, sleep, or breath any more; how quick do
you expect me to jump?
I'll take a look at it as soon
I'll take it. I assume it's just a matter of removing the mutating
methods and making the tests pass? I saw but didn't read a couple
threads about the buffer API... how much has to change there?
On 9/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> No takers? What about those repeated +42 vote
No takers? What about those repeated +42 voters? Does anyone want
immutable bytes enough to do a teensy bit of work?
--Guido
On 9/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This may have passed in a thread where no-one was listening, so I'm
> repeating it here.
>
> I'm considering the f
On 9/17/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Note that some people are currently arguing that sys.argv should be an
> array of bytes objects, and Guido has not yet said "no".
Then let me say "no" now. I'd be happy to support a lower-level API
for getting at the actual bytes in the
Dnia 18-09-2007, Wt o godzinie 13:08 +0900, Stephen J. Turnbull
napisał(a):
> > This is wrong: UTF-8 is specified for PUA. PUA is no special from the
> > point of view of UTF-8.
>
> It is from the point of view of the Unicode standard, specifically v5.
> Please see section 16.5, especially abou
20 matches
Mail list logo
