XML with Unicode: what am I doing wrong?
This is a followup to a blog post I wrote the other day
http://www.blueskyonmars.com/archives/2005/01/31/using_unicode_with_elementtidy.html
I started out working in the context of elementtidy, but now I am
running into trouble in general Python-XML areas, so I thought I'd toss
the question out here. The code below is fairly self-explanatory. I have
a small HTML snippet that is UTF-8 encoded and is not 7-bit ASCII
compatible. I use Tidy to convert it to XHTML, and this particular setup
returns a unicode instance rather than a string.
import _elementtidy as et
from xml.parsers import expat
data = unicode(open("snippetWithUnicode.html").read(), "utf-8")
html = et.fixup(data)[0]
parser = expat.ParserCreate()
parser.Parse(html)
UnicodeEncodeError: 'ascii' codec can't encode character '\ub5' in
position 542: ordinal not in range(128)
If I set my default encoding to utf8 in sitecustomize.py, it works just
fine. I'm thinking that I can't be the only one trying to pass unicode
to expat... Is there something else I need to do here?
Thanks,
Kevin
Blazing Things
--
http://mail.python.org/mailman/listinfo/python-list
Re: XML with Unicode: what am I doing wrong?
In article news.t-online.com>, "Diez B. Roggisch" web.de> wrote: you confuse unicode with utf8. Expat can parse the latter - the former is internal to python. And passing it to something that needs a string will result in a conversion - which fails because of the ascii encoding. Ahh... that makes sense. I kept thinking that if I'm working with unicode strings, I should be passing around unicode objects. What you say makes sense, though, that the PyExpat understands UTF-8 encoded strings. Working with unicode objects in Python is so transparent, it's easy to forget about what a C extension would likely want. Thanks Diez and Just for the quick responses! Kevin -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there something easier than ORM?
On Feb 17, 10:28 pm, alex23 wrote: > On Feb 18, 3:10 am, Robert Kern wrote: > > > Its public image definitely suffers from the impression that it's "an ORM" > > that > > can be compared on equal terms with packages that actually are just ORMs. I > > describe it as a very powerful toolkit for solving a wide variety of > > problems > > involving SQL databases. One of those tools happens to be an ORM. > > I'm going to have to steal that description the next time I try to > sell a co-worker on the value of SQLAlchemy. There's always a strong > reaction against the mention of ORMs, generally along the lines of it > moving the programmer too far away from the real action. But my > experience is identical to both andrew's and your's; there is far far > more of value in SQLA than the ORM alone. I just saw this thread via the weekly Python URL email and wanted to add one bit here. When I've been selling people on using SQLAlchemy, one argument that I make is that if you're using a relational database for storage but your program is using objects (and good Python programs do!), then you're doing ORM. If you're not using SQLAlchemy (or similar), you're likely doing ORM badly. SQLAlchemy's SQL layer definitely makes it a different beast from most ORMs. Kevin -- http://mail.python.org/mailman/listinfo/python-list
