There is only one week left for PyCon tutorial & scheduled talk proposals. If
you've been thinking about making a proposal, now's the time!
Tutorial details and instructions here:
http://us.pycon.org/2008/tutorials/proposals/
Scheduled talk details and instructions here:
http://us.pycon.org/2008
D'oh. I forgot to point to the patch. It's here:
http://bugs.python.org/issue1416
On Nov 9, 2007 10:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> To follow up, I now have a patch. It's pretty straightforward.
>
> This implements the kind of syntax that I believe won over most folks
> in the
To follow up, I now have a patch. It's pretty straightforward.
This implements the kind of syntax that I believe won over most folks
in the end:
@property
def foo(self): ...
@foo.setter
def foo(self, value=None): ...
There are also .getter and .deleter descriptors. This includes the ha
Martin v. Löwis wrote:
>> Not really, but the codec has more control over what happens to
>> the stream, ie. it's easier to implement look-ahead in the codec
>> than to do the detection and then try to push the bytes back onto
>> the stream (which may or may not be possible depending on the
>> natu
"Martin v. Löwis" writes:
> > It's clear to me that detecting an encoding is actually the simplest
> > part of all this (so long as there's an API to do it!) Putting it
> > inside a codec seems like the wrong subdivision of responsibility.
>
> In case it isn't clear - this is exactly my vie
> Not really, but the codec has more control over what happens to
> the stream, ie. it's easier to implement look-ahead in the codec
> than to do the detection and then try to push the bytes back onto
> the stream (which may or may not be possible depending on the
> nature of the stream).
YAGNI.
On Nov 9, 2007 3:59 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> >> It makes working with XML data a lot easier: you simply don't have to
> >> bother with the encoding of the XML data anymore and can just let the
> >> codec figure out the details. The XML parser can then
Martin v. Löwis wrote:
>> It makes working with XML data a lot easier: you simply don't have to
>> bother with the encoding of the XML data anymore and can just let the
>> codec figure out the details. The XML parser can then work directly
>> on the Unicode data.
>
> Having the functionality indee
> It's clear to me that detecting an encoding is actually the simplest
> part of all this (so long as there's an API to do it!) Putting it
> inside a codec seems like the wrong subdivision of responsibility.
In case it isn't clear - this is exactly my view also.
Regards,
Martin
_
> In fact, we already have such a codec. The utf-16 decoder looks at the
> first two bytes and then decides to forward the rest to either a
> utf-16-be or a utf-16-le decoder.
That's different. UTF-16 is a proper encoding that is just specified
to use the BOM. "xml-auto-detection" is not an encodi
> It makes working with XML data a lot easier: you simply don't have to
> bother with the encoding of the XML data anymore and can just let the
> codec figure out the details. The XML parser can then work directly
> on the Unicode data.
Having the functionality indeed makes things easier. However,
On Nov 9, 2007 6:10 AM, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
> Martin v. Löwis wrote:
> >>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
> >>> codecs to do the encoding. There's no need to create a magical
> >>> mystery codec to pick out which though.
> >> So the code
> And what do you do once you've detected the encoding? You decode the
> input, so why not combine both into an XML decoder?
Because it is the XML parser that does the decoding, not the
application. Also, it is better to provide functionality in
a modular manner (i.e. encoding detection separately
>> So what if the unicode string doesn't start with an XML declaration?
>> Will it add one?
>
> No.
Ok. So the XML document would be ill-formed then unless the encoding is
UTF-8, right?
> The point of this code is not just to return whether the string starts
> with " * The string does start wi
ACTIVITY SUMMARY (11/02/07 - 11/09/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1322 open (+23) / 11575 closed (+18) / 12897 total (+41)
Open issues with patches: 418
Average durati
Christian Heimes wrote:
> (*) It's missing from the list of resolutions but I like to have it
> added. http://psf.upfronthosting.co.za/roundup/meta/issue167
Update:
Georg Brandl pointed out that it makes more sense to add confirmed to
status.
Christian
Hello!
Guido has granted me committer privileges to svn.python.org and
bugs.python.org about a week ago. So I'm new and new people tend to make
mistakes until they've learned the specific rules of a project.
Today I've learned that the resolution keyword "accepted" doesn't mean
the bug report is
On Nov 9, 2007, at 8:22 AM, M.-A. Lemburg wrote:
> FWIW: I'm +1 on adding such a codec.
I'm undecided, and really don't feel strongly either way.
> It makes working with XML data a lot easier: you simply don't have to
> bother with the encoding of the XML data anymore and can just let the
> codec
M.-A. Lemburg wrote:
> On 2007-11-09 14:10, Walter Dörwald wrote:
>> Martin v. Löwis wrote:
> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
> codecs to do the encoding. There's no need to create a magical
> mystery codec to pick out which though.
So the code
Walter Dörwald wrote:
> Martin v. Löwis wrote:
Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
codecs to do the encoding. There's no need to create a magical
mystery codec to pick out which though.
>>> So the code is good, if it is inside an XML parser, and it's
On 2007-11-09 14:10, Walter Dörwald wrote:
> Martin v. Löwis wrote:
Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
codecs to do the encoding. There's no need to create a magical
mystery codec to pick out which though.
>>> So the code is good, if it is inside an
Martin v. Löwis wrote:
>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
>>> codecs to do the encoding. There's no need to create a magical
>>> mystery codec to pick out which though.
>> So the code is good, if it is inside an XML parser, and it's bad if it
>> is inside a cod
Martin v. Löwis wrote:
>> Because you can force the encoder to use a specified encoding. If you do
>> this and the unicode string starts with an XML declaration
>
> So what if the unicode string doesn't start with an XML declaration?
> Will it add one?
No.
> If so, what version number will it u
> Because you can force the encoder to use a specified encoding. If you do
> this and the unicode string starts with an XML declaration
So what if the unicode string doesn't start with an XML declaration?
Will it add one? If so, what version number will it use?
>>> OK, so should I put the C code
>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
>> codecs to do the encoding. There's no need to create a magical
>> mystery codec to pick out which though.
>
> So the code is good, if it is inside an XML parser, and it's bad if it
> is inside a codec?
Exactly so. This fun
Martin v. Löwis wrote:
>> ci = codecs.lookup("xml-auto-detect")
>> p = expat.ParserCreate()
>> e = "utf-32"
>> s = (u"" % e).encode(e)
>> s = ci.encode(ci.decode(s)[0], encoding="utf-8")[0]
>> p.Parse(s, True)
>
> So how come the document being parsed is recognized as UTF-8?
Because you can forc
Adam Olsen wrote:
> On 11/8/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> [...]
Furthermore encoding-detection might be part of the responsibility of
the XML parser, but this decoding phase is totally distinct from the
parsing phase, so why not put the decoding into a common libr
27 matches
Mail list logo
