[Python-Dev] PEP 263 considered faulty (for some Japanese

[Fredrik Lundh]

Stephen J. Turnbull wrote:

>     Fredrik> PEP 263 implements the same model, minus UTF-16, and with
>     Fredrik> a two-phase implementation plan.
>=20
> It does not.

That wasn't an opinion, that was a statement of fact.

If you don't understand this, you're either not understanding the PEP,
the Python language specification (and how Python's parser and unicode
system works in real life), the XML specification (and how XML parsers
work in real life), or you're just trying to keep the argument going.

Try resetting your brain, study my statement and Martin's reply =
carefully,
and then read everything in the PEP *except* for the implementation
section.

If necessary, check the Python language reference as well.

When you do get it, please tell us what we need to clarify.  Arguing
that if you don't get it, it has to be *conceptually* wrong, won't get
us anywhere.

(as googling for "mule is evil" or "naggum on mule" shows, you should
know this from your work on emacs).

> True.  But the historical antecedent for PEP 263 is much closer to
> Emacs/Mule

That's a strange statement, given that most about everyone involved
in what led up to the PEP qualify as XML experts, and I don't think any =
of
them has been involved in Mule.

> which comes down on the PEP 263 side of both the issues
> identified above, than to XML.

I know XML's encoding model well (and the same goes for everyone =
involved
in what led up to the PEP), and I see nothing in the PEP that doesn't =
match
how things are done in XML, in real life.  You know Mule well, and argue =
that
the PEP has to be changed.  And then you argue that the PEP, as it =
stands,
is closer to Mule than to XML !?

Sorry the five minutes is up.

If you want me to go on arguing, you'll have to pay for another five =
minutes.

</F>