I've been using the minidom to produce little properly-formatted XML
documents, by building a DOM tree, then calling "toxml" to generate
the actual XML. But I tripped over the optional "encoding" argument
to that function.
I figured that the only point of having an encoding argument would be
to a
Hi,
Bill Janssen wrote:
> I figured that the only point of having an encoding argument would be
> to allow the user to control the output character set encoding, but it
> turns out that specifying an encoding of, say, "ASCII", doesn't do
> that. It just raises encoding exceptions when you attempt
Stefan,
> > writer = codecs.lookup(encoding)[3](writer, "xmlcharrefreplace")
>
> Could be done, yes. ElementTree and lxml do it that way. It's not required,
> though. If you say you want to serialise plain ASCII data, nothing keeps an
> XML serialiser from shouting at you when it finds non-AS
> Well, what did you expect? That it magically transmogrifies your non-ASCII
> data into plain ASCII data?
Yep. And there's no reason I can see why it can't do exactly that. I
think the "encoding" argument should either be removed, or made to
work.
Bill
_
Hi,
Bill Janssen wrote:
>> Well, what did you expect? That it magically transmogrifies your non-ASCII
>> data into plain ASCII data?
>
> Yep. And there's no reason I can see why it can't do exactly that. I
> think the "encoding" argument should either be removed, or made to
> work.
That's why
Stefan Behnel wrote:
Hi,
Bill Janssen wrote:
Well, what did you expect? That it magically transmogrifies your non-ASCII
data into plain ASCII data?
Yep. And there's no reason I can see why it can't do exactly that. I
think the "encoding" argument should either be removed, or made t
Hi,
Bob Kline wrote:
> Stefan is (if he even realizes that Bill might be thinking
> this) himself possibly thinking "no way is the method going to do that
> much work for the caller."
No, I'm actually just saying that this is not a bug and maybe not even a
missing feature. It's a design decision.
> I suspect there's a certain amount of unarticulated assumptions on both
> sides of this exchange. I'm guessing that Bill might be thinking
> something like: "it's possible to represent any Unicode character in XML
> as &#"; and was hoping that the method
> would do just that for the non-ASCI
> Hi,
>
> Bob Kline wrote:
> > Stefan is (if he even realizes that Bill might be thinking
> > this) himself possibly thinking "no way is the method going to do that
> > much work for the caller."
>
> No, I'm actually just saying that this is not a bug and maybe not even a
> missing feature. It's
I believe there are reasonable grounds for both Bill's and Stefan's
interpretation of the somewhat ambiguous documentation for the method,
and further, that the documentation would benefit from some
clarification one way or another. I don't think Bill is correct in
thinking that is no other po
Hi,
Bill Janssen wrote:
>> I suspect there's a certain amount of unarticulated assumptions on both
>> sides of this exchange. I'm guessing that Bill might be thinking
>> something like: "it's possible to represent any Unicode character in XML
>> as &#"; and was hoping that the method
>> would
11 matches
Mail list logo
