A couple of Python 'Features'

Michael Foord fuzzyman at gmail.com
Mon Sep 6 06:10:41 EDT 2004


"Paul McGuire" <ptmcg at austin.rr._bogus_.com> wrote in message news:<Gpl_c.14407$Dl4.9083 at fe2.texas.rr.com>...
> "Michael Foord" <fuzzyman at gmail.com> wrote in message
> news:6f402501.0409040202.26cd7a30 at posting.google.com...
> > I've come across a couple of 'features' in Python standard libraries -
> > and I'm not sure if they're meant to be there... or if they're bugs...
> >
> > One in urllib2 and one in cgi.
> >
> > >>> from urllib2 import urlopen
> > >>> a = urlopen('http://www.voidspace.org.uk')
> > >>> i = a.info()
> > >>> for entry in i: print entry
> > Traceback (most recent call last):
> >   File "<pyshell#11>", line 1, in -toplevel-
> >     for entry in i: print entry
> >   File "D:\PYTHON23\lib\rfc822.py", line 390, in __getitem__
> >     return self.dict[name.lower()]
> > AttributeError: 'int' object has no attribute 'lower'
> >
> > and in cgi (a result that happens in live CGI as well as interactive
> > sessions....) :
> >
> > >>> import cgi
> > >>> a = cgi.FieldStorage()
> > >>> for entry in a: print entry
> >
> > Traceback (most recent call last):
> >   File "<pyshell#3>", line 1, in ?
> >     for entry in a: print entry
> >   File "C:\PYTHON22\lib\cgi.py", line 550, in __getitem_
> >     raise KeyError,
> >  keyKeyError: 0
> > >>>
> >
> > You can get round the cgi bug because :
> > for entry in a.keys(): print entry
> > works fine - but it's a bit annoying.
> >
> > (Admittedly my server has python 2.2, but the urllib2 bug occurs in
> > Python 2.3.4 as well I think).
> >
> > Regards,
> >
> >
> > Fuzzy
> >
> > http://www.voidspace.org.uk/atlantibots/pythonutils.html
> 
> The urllib2 problem looks like a clone of one mentioned earlier in the email
> module, which I looked into and reported as bug 1017329.  You could add your
> example to that, or open a new bug report.  But the two should be linked
> somehow, as they have the same failure mode, and very likely the same
> resolution.
> 
> Looking briefly at the cgi module also shows a similar implementation gap,
> but I see that FieldStorage implements __iter__, which I thought would be
> used in "for entry in a" type iteration, and that failing the existence of
> __iter__, then __len__ would be tried with successive calls to __getitem__
> from 0 to len-1.  What *is* the order of resolution for iterating over a
> sequence?
> 
> (1015249 was also recently submitted, to address problems with
> FieldStorage's __len__ function, should also be linked.)
> 
> -- Paul

Yep... I think the example failure I showed for FieldStorage was
actually under Python 2.3.4 - so I'm not convinced it's fixed.

I'll raise two new bug reports but include references to the ones you
mention....

Regards,


Fuzzy

http://www.voidspace.org.uk/atlantibots/pythonutils.html



More information about the Python-list mailing list