This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients effbot, flox, georg.brandl, gvanrossum, lemburg, r.david.murray, scoder
Date 2010-03-22.09:36:30
SpamBayes Score 7.94365e-13
Marked as misclassified No
Message-id <4BA73A1C.70100@egenix.com>
In-reply-to <1269248974.38.0.037113908177.issue8047@psf.upfronthosting.co.za>
Content
Stefan Behnel wrote:
> 
> Stefan Behnel <scoder@users.sourceforge.net> added the comment:
> 
>> 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.

There's always the possibility of adding a new official codec
called 'unicode' which converts Unicode to Unicode as no-op.

This may also be useful to have in other situations where you
want to signal a special case for Unicode input or output.
History
Date User Action Args
2010-03-22 09:36:32lemburgsetrecipients: + lemburg, gvanrossum, effbot, georg.brandl, scoder, r.david.murray, flox
2010-03-22 09:36:30lemburglinkissue8047 messages
2010-03-22 09:36:30lemburgcreate