[issue12921] http.server.BaseHTTPRequestHandler.send_error and trailing newline
New submission from Paul Upchurch :
Calling http.server.BaseHTTPRequestHandler.send_error(code,message) with a
message that contains a trailing newline does not display properly in Firefox,
Chrome.
Listing 1
#!/usr/bin/env python3.2
import http.server
import traceback
class httphandler(http.server.BaseHTTPRequestHandler):
def do_GET(self):
try:
assert(False)
except:
self.send_error(500,traceback.format_exc())
if __name__=='__main__':
addr=('',9000)
http.server.HTTPServer(addr,httphandler).serve_forever()
Consider Listing 1. A typical programming idiom would be to wrap do_GET with a
try/except block that reports an HTTP error with an HTML formatted stack trace.
However, when I view this with Firefox and Chrome the error message is
unformatted, i.e. raw HTML is displayed.
A simple workaround is to call strip() on the message. This could be suggested
to the user in the docs, or added as an automatic preprocessing feature to the
library. With strip(), the message is formatted.
Adding or documenting strip() resolves the bug. The remainder of this report is
a feature request.
The default error_message_format is probably not what people want for a stack
trace. It leaves formatting of whitespace to the HTML which removes the
newlines. This is desirable for short, unformatted messages but undesirable for
a preformatted traceback. In Listing 2 I give a working solution and suggest
including it in the library if the community feels that preformatted messages
are common enough to warrant extra attention. I feel it is since "try/except:
print traceback" is almost mandatory for error prone internet operations.
Listing 2
#!/usr/bin/env python3.2
import http.server
import traceback
class httphandler(http.server.BaseHTTPRequestHandler):
def content_aware_error_message_format(self,m):
oldfmt='Message: %(message)s.\n'
if oldfmt in self.error_message_format:
# use if the message contains a newline internally
# otherwise let the html control line breaks
self.error_message_format=self.error_message_format.replace(oldfmt,'%(message)s\n')
if '\n' in m else self.error_message_format.replace(oldfmt,'%(message)s\n')
def do_GET(self):
try:
assert(False)
except:
m=traceback.format_exc().strip()
self.content_aware_error_message_format(m)
self.send_error(500,m)
if __name__=='__main__':
addr=('',9000)
http.server.HTTPServer(addr,httphandler).serve_forever()
--
components: Library (Lib)
messages: 143646
nosy: Paul.Upchurch
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler.send_error and trailing newline
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue12921>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
New submission from Paul Upchurch : To reproduce the error: Python 3.2.2 (default, Sep 5 2011, 22:09:30) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,9,None).indices(126) Traceback (most recent call last): File "", line 1, in OverflowError: cannot fit 'int' into an index-sized integer >>> The correct behaviour is to return (0, 9, 1). >>> slice(0,9,None).indices(6) (0, 9, 1) This is related to http://bugs.python.org/issue1456470. -- components: Interpreter Core messages: 160500 nosy: Paul.Upchurch priority: normal severity: normal status: open title: slice.indices raises OverflowError type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14794> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Paul Upchurch added the comment: Sorry. I didn't realize there was a 3.2.3 out. I'll close it as fixed. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue14794> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Paul Upchurch added the comment: That's true; it doesn't work with today's downloads from python.org. The version I tested was win32 but I don't think that should matter. Python has always supported large numbers on 32-bit OSs. My observations: [1] Debian Wheezy, python3.2, 3.2.3~rc2-1: Fail [2] Debian Wheezy, python2.7, 2.7.3~rc2-2.1: Fail [3] python.org, python3.3, 3.3.0a3: Fail [4] python.org, python3.2, 3.2.3: Fail I'll compile 64-bit linux from source and try that. [1] Python 3.2.3rc2 (default, Mar 21 2012, 06:59:51) [GCC 4.6.3] on linux2 [2] Python 2.7.3rc2 (default, Apr 22 2012, 22:35:38) [GCC 4.6.3] on linux2 [3] Python 3.3.0a3 (default, May 1 2012, 16:25:20) [MSC v.1500 32 bit (Intel)] on win32 [4] Python 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] on win32 -- ___ Python tracker <http://bugs.python.org/issue14794> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Paul Upchurch added the comment: The pre-built 64-bit Windows binaries from python.org works. Python 3.3.0a3 (default, May 1 2012, 16:46:00) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,9,None).indices(126) (0, 9, 1) Python 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,9,None).indices(126) (0, 9, 1) I think this issue is settled. There are several possible actions for people that find this discussion through a web search. 1. Use Ubuntu 12.04 LTS 2. Compile a fresh copy of 3.2 or 3.3 from python.org. 3. Use a pre-built 3.2 or 3.3 64-bit Windows binary from python.org. 4. Wait for your Linux distribution to catch up. Hynek, Éric: Thanks for your help. -- ___ Python tracker <http://bugs.python.org/issue14794> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Paul Upchurch added the comment: For the concept of "reasonable", it should be noted that this behaviour will affect code that works with reasonably sized sequences despite the largeness of the parameter. Consider an extremely large array. To work with such an array, one would typically break it into small segments. However, to simplify the code and reduce bugs it makes sense to use a consistent indexing method on each segment. The size of its parameter does not say anything about the size of a segment. Consider a class which implements virtual arrays. def __getitem__(...): ... start,stop,step=slice.indices(start,stop,step).indices(126) while True: if step>0 and start>=stop: break if step<0 and start<=stop: break p=pageid(start) make_page_resident(p) do work ... start=start+step As you can see, slice.indices should not be limited to sys.maxsize. If Python can perform the arithmetic calculation sys.maxsize+1 then slice.indices(sys.maxsize+1) should also work. The usage of slice.indices is to ensure consistent behaviour of the slicing operator. Another workaround for this bug: 5. write your own implementation of slice.indices I consider this a workaround. The correct way to handle the index parameter to __getitem__ and __setitem__ is to use slice.indices. That way, if the semantics of slicing changes in future versions of Python, your class will behave consistently. It seems to me that this is the main reason why slice.indices exists at all: to prevent inconsistent behaviour when people implement __getitem__ and __setitem__. -- ___ Python tracker <http://bugs.python.org/issue14794> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
