[issue4340] xmlrpc.client - default 'SlowParser' not defined
New submission from Mike Watkins <[EMAIL PROTECTED]>:
Running example code from docs:
http://docs.python.org/dev/3.0/library/xmlrpc.client.html#example-of-
client-usage
z% python
Python 3.0rc2+ (py3k:67152, Nov 7 2008, 16:48:55)
[GCC 4.2.1 20070719 [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> str(None)
'None'
>>> from xmlrpc.client import ServerProxy, Error
>>> server = ServerProxy("http://betty.userland.com";)
>>> print(server)
>>> print(server)
>>> print(server.examples.getStateName(41))
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1095, in
__call__
return self.__send(self.__name, args)
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1353, in
__request
verbose=self.__verbose
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1136, in
request
return self._parse_response(resp, None)
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1235, in
_parse_response
p, u = self.getparser()
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1145, in
getparser
return getparser(use_datetime=self._use_datetime)
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 975, in
getparser
parser = SlowParser(target)
NameError: global name 'SlowParser' is not defined
No definition of SlowParser in client.py:
/src/py3k/Lib/xmlrpc% grep -n SlowParser client.py
116: SlowParser Slow but safe standard parser (based on xmllib)
975:parser = SlowParser(target)
--
components: Library (Lib)
messages: 75980
nosy: mwatkins
severity: normal
status: open
title: xmlrpc.client - default 'SlowParser' not defined
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4340>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4340] xmlrpc.client - default 'SlowParser' not defined
Mike Watkins <[EMAIL PROTECTED]> added the comment: Running the same code today passes, despite the fact I'm still running the same svn version. Bizarre. However the core reported issue - SlowParser being undefined in the module, remains. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4556] cmp() function erroneously noted as gone in "What's New"
New submission from Mike Watkins <[EMAIL PROTECTED]>: What's new in 3.0 documentation says cmp() function is gone, yet it isn't: >>> sys.version_info; cmp(1,1); cmp(1,2); cmp(2,1) (3, 0, 0, 'final', 0) 0 -1 1 -- assignee: georg.brandl components: Documentation messages: 77093 nosy: georg.brandl, mwatkins severity: normal status: open title: cmp() function erroneously noted as gone in "What's New" versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders()
New submission from Mike Watkins : HTTPMessage.getallmatchingheaders() stopped working sometime after Python 3.0 release. In a recent (1 day ago) svn update the implementation says the method was copied from rfc822.message; the Python 3.x implementation is broken (iterates through self.keys instead of header values). I've not looked back to see where the change was introduced but I do know that it broke post 3.0 release. But more importantly than the flaw in this method, the functionality is duplicated elsewhere in Python 3.x. I propose either deprecating getallmatchingheaders() or if it is to be kept for compatibility, the fix can be simply replacing the method body with: self.get_all(name) The docstring for get_all (defined in email.message) affirms that its output is indeed compatible with that which was intended for getallmatchingheaders(). get_all(self, name, failobj=None) method of client.HTTPMessage instance Return a list of all the values for the named field. These will be sorted in the order they appeared in the original message, and may contain duplicates. Any fields deleted and re-inserted are always appended to the header list. If no such fields exist, failobj is returned (defaults to None). I've tested the use of get_all against one web server (QP) which runs on both Python 2.x and 3.x. As a result of the broken getallmatchingheaders() the QP web server now uses for the same purpose as getallmatchingheaders() instead: get_all(name) (defined in email.message.Message in Py3k and getheaders(name) (defined in rfc822.Message). See also issues on documentation and changed API in #4773, #3428 -- components: Library (Lib) messages: 80509 nosy: mwatkins severity: normal status: open title: http.client.HTTPMessage.getallmatchingheaders() type: behavior versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed
New submission from Mike Watkins :
There appears to have been a bug in how HTTP_ACCEPT is parsed living in
run_cgi() for eons, perhaps from the time it was written. Perhaps not
many are using this code (I'm not either) but recent (post 3.0 Release)
Python 3.x appear to have broken something in getallmatchingheaders()
(which originates in Message) and I happened to stumble upon this
condition while searching through the stdlib code.
>From Line 980 of http.server
accept = []
for line in self.headers.getallmatchingheaders('accept'):
if line[:1] in "\t\n\r ":
accept.append(line.strip())
else:
accept = accept + line[7:].split(',')
env['HTTP_ACCEPT'] = ','.join(accept)
line[:1] in '\t\n\r' clearly was meant to to be line[-1].
However that doesn't fix completely this chunk of code as it makes some
assumptions about what getallmatchingheaders() delivers which aren't
accurate. The following behaves as expected and feels safer:
accept = []
for line in self.headers.getallmatchingheaders('accept'):
if line.lower().startswith("accept:"):
line = line[7:]
for part in line.split(','):
part = part.strip()
if part:
accept.append(part)
env['HTTP_ACCEPT'] = ','.join(accept)
Note that post Python 3.0 release,
http.client.HTTPMessage.getallmatchingheaders() was broken. I've
reported this just now and proposed a fix in #5053.
--
components: Library (Lib)
messages: 80510
nosy: mwatkins
severity: normal
status: open
title: CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5054>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders()
Mike Watkins added the comment: Trivial patch for http.client attached. -- keywords: +patch Added file: http://bugs.python.org/file12858/http.client.py.patch ___ Python tracker <http://bugs.python.org/issue5053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns []
Changes by Mike Watkins : -- title: http.client.HTTPMessage.getallmatchingheaders() -> http.client.HTTPMessage.getallmatchingheaders() always returns [] ___ Python tracker <http://bugs.python.org/issue5053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns []
Mike Watkins added the comment: Re diffs, noted for the future. Re tests: # py3k-devel/Lib/test % grep -r getallmatchingheaders * ... Returns nothing, so not only does the email package need a test for this but so does http.client. Incidentally test_mailbox.py has a test for the proposed alternative - get_all(), which I noted above. That's another good reason for ridding the world of getallmatchingheaders() or at least simply calling get_all() from within getallmatchingheaders() if compatibility is a legitimate concern. ___ Python tracker <http://bugs.python.org/issue5053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns []
Mike Watkins added the comment: Further investigation ( grep -r getallmatchingheaders Lib/* ) reveals that in addition to having no tests, and being implemented incorrectly in http.client, getallmatchingheaders() is called only once, in http.server; that code is also broken (I reported this yesterday in #5053). Maybe Python 3 is where getallmatchingheaders can make a graceful goodbye (and a 2to3 conversion added?). ___ Python tracker <http://bugs.python.org/issue5053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
