[Python-Dev] Easy codec access

Michael Hudson mwh@python.net
16 May 2001 12:19:15 +0100


"M.-A. Lemburg" <mal@lemburg.com> writes:

> > This is a bit unfriendly though:
> > 
> > >>> "bobbins".encode("gzip")
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "/usr/local/src/python/dist/build/Lib/encodings/__init__.py", line 59, in search_function
> >     raise SystemError,\
> > SystemError: module "encodings.gzip" failed to register
> > 
> > I thought SystemErrors shouldn't ever happen (isn't it what gets
> > raised for an illegal opcode, for example?).
> 
> This is due to the zlib module not being installed. 

No it's not, actually.  I *thought* I was getting the error message
because the zlib encoding doesn't alias itself to gzip (whether it
should or not is another question).  But in fact if you specify a
bogus encoding you get a nice error message:

>>> "bobbins".encode("nonesuch")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
LookupError: unknown encoding

but:

>>> "bobbins".encode("sys")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/src/python/dist/build/Lib/encodings/__init__.py", line 59, in search_function
    raise SystemError,\
SystemError: module "encodings.sys" failed to register

I have to admit I don't really know what's going on here, but the
error is just confusing.

> The reason for the search function in encodings/__init__.py raising
> a SystemError is that it did find a module named gzip, but this
> module does not export the needed registration API getregentry().

Yep.  

> Perhaps it should just raise a LookupError instead, though...

Might be easiest.

> > urlencode would be nice.  Maybe re.escape, too.  html entities?
> > That's probably a bigger can of worms, but
> > 
> > print "<p>%s</p>"%text.encode("html")
> > 
> > seems delightfully simpleminded.
> 
> Right. That's the idea... volunteers are welcome :-) 

Maybe this evening.

> There are lots of those little "escape this, encode that" tasks 
> which could benefit from the codec machinery. The ones you
> mention would certainly be good candidates. pickle and marshal
> would also be a good to have wrapped as codecs.

Ooh yes, hadn't thought of them.

'YW5vdGhlci1mdW4tdG95\n'.decode("base64")-ly y'rs
M.

-- 
  There's an aura of unholy black magic about CLISP.  It works, but
  I have no idea how it does it.  I suspect there's a goat involved
  somewhere.                     -- Johann Hibschman, comp.lang.scheme