Message101488
| Author |
scoder |
| Recipients |
effbot, flox, georg.brandl, gvanrossum, r.david.murray, scoder |
| Date |
2010年03月22日.09:09:28 |
| SpamBayes Score |
1.0929164e-08 |
| Marked as misclassified |
No |
| Message-id |
<1269248974.38.0.037113908177.issue8047@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> Supporting unicode for lxml.etree compatibility is fine with me, but I
> think it might make sense to support the string "unicode" as well (as
> a pseudo-encoding -- it's pretty clear to me that nobody will ever
> define a real character encoding with that name :-).
The reason I chose the unicode type over a 'unicode' string name at the time was that I wanted to make a clear distinction to show that this is not just selecting a different codec but that it changes the output type.
I don't really care either way, though, given that this reads a lot less well in Py3. If ET supports both, lxml will follow.
Stefan |
|