> Along the same lines, since all strings are now unicode,
> should "returns_unicode" be dropped from xmlparser objects?
> That is, the handler functions will always be passed unicode
> strings and not utf-8 bytes.
Sure.
Martin
___
Python-3000 mailing l
> Sure, normally XML is serialized to bytes, but it is also
> serializable to unicode, and that's a useful feature to have (if
> implementable).
It's not reasonably implementable; users who have use cases
will have to encode as UTF-8 first.
Regards,
Martin
On Sunday 22 July 2007, Joe Gregorio wrote:
> Along the same lines, since all strings are now unicode,
> should "returns_unicode" be dropped from xmlparser objects?
> That is, the handler functions will always be passed unicode
> strings and not utf-8 bytes.
Yes. This was always a backward-co
On 7/22/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Sure, normally XML is serialized to bytes, but it is also
> > serializable to unicode, and that's a useful feature to have (if
> > implementable).
>
> It's not reasonably implementable; users who have use cases
> will have to encode as UT
On Sunday 22 July 2007, Guido van Rossum wrote:
> Now I'm confused. Are we proposing that all our XML APIs read and
> write encoded bytes, or are we proposing that they read and write
> Unicode strings, leaving the encoding/decoding to the I/O stream? I
> thought the latter was preferred but no
Guido van Rossum schrieb:
> On 7/22/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> > Sure, normally XML is serialized to bytes, but it is also
>> > serializable to unicode, and that's a useful feature to have (if
>> > implementable).
>>
>> It's not reasonably implementable; users who have use
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Joe Smith wrote:
>> If the maintainers of most of the large packages that do imaging are
>> willing
>> to support this,
>> and your code is good, I see absolutely no reason why this PEP would not
>> be
>> accepted.
>
> S
Phillip J. Eby wrote:
> Well, if you're looking at *run-time*, then you can equally well dump
> out the runtime contents of a generic function,
I'm not talking about doing this *at* run time. I'm
talking about reasoning about what the program will
do, based on your knowledge of what the run-time
Phillip J. Eby wrote:
> You seem to be saying that the ability to put things in different places
> encourages disorganization.
No. What I'm saying is that there are conflicting organisational
requirements here.
If the things being put in different places were independent
and able to be reasoned
Guido van Rossum wrote:
> Now I'm confused. Are we proposing that all our XML APIs read and
> write encoded bytes, or are we proposing that they read and write
> Unicode strings, leaving the encoding/decoding to the I/O stream?
The design of XML seems a bit braindamaged here, with the
encoding spe
Greg Ewing wrote:
> Guido van Rossum wrote:
>> Now I'm confused. Are we proposing that all our XML APIs read and
>> write encoded bytes, or are we proposing that they read and write
>> Unicode strings, leaving the encoding/decoding to the I/O stream?
>
> The design of XML seems a bit braindamaged
At 11:47 AM 7/23/2007 +1200, Greg Ewing wrote:
>With a normal method call, you can take an assumed
>run-time type, start at one end and follow things
>through step by step. That's not so easy with
>generic functions, for two reasons: (1) all of the
>arguments can potentially influence where the
>co
At 11:48 AM 7/23/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > You seem to be saying that the ability to put things in different places
> > encourages disorganization.
>
>No. What I'm saying is that there are conflicting organisational
>requirements here.
>
>If the things being put in di
13 matches
Mail list logo
