[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg

2015-02-17 Thread Robin Schoonover
Robin Schoonover added the comment: I'm not sure I follow, as it has little to say on whether the application's expected behavior here, and only a recommendation that the server allow it. But, it also defers to the Python Standard Library, which does have an opinion. I feel

[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called

2014-07-02 Thread Robin Schoonover
Robin Schoonover added the comment: Fair enough, I misled myself. However, and I feel like I'm getting really picky here, but it still doesn't fulfill the paragraph I quoted: def application(environ, start_response): start_response('200 OK', [('Content-type

[issue21890] wsgiref.simple_server sends headers on empty bytes

2014-07-02 Thread Robin Schoonover
Robin Schoonover added the comment: I agree, the current patch is too permissive. Both a server I wrote a while ago, and most other complaint servers deal with the problem the exact same way as that patch, and that extra permissiveness led to my misinterpretation when analyzing why I had made

[issue21890] wsgiref.simple_server sends headers on empty bytes

2014-07-02 Thread Robin Schoonover
Changes by Robin Schoonover ro...@cornhooves.org: Added file: http://bugs.python.org/file35836/wsgiref-empty-byte-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21890

[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called

2014-06-30 Thread Robin Schoonover
Changes by Robin Schoonover ro...@cornhooves.org: -- keywords: +patch Added file: http://bugs.python.org/file35810/wsgiref-empty-byte.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21890

[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called

2014-06-30 Thread Robin Schoonover
New submission from Robin Schoonover: Consider this paragraph of PEP, referring to headers obtained via start_response, emphasis mine: Instead, it must store them for the server or gateway to transmit only after the first iteration of the application return value that yields

[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg

2014-06-30 Thread Robin Schoonover
Changes by Robin Schoonover ro...@cornhooves.org: -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18610 ___ ___ Python-bugs-list

[issue21878] wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data

2014-06-28 Thread Robin Schoonover
New submission from Robin Schoonover: In the reference WSGI server in wsgiref.simple_server, wsgi.input's readline() hangs if the request body does not actually contain any newlines. Consider the following (slightly silly) example: from wsgiref.simple_server import make_server def

[issue21878] wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances

2014-06-28 Thread Robin Schoonover
Robin Schoonover added the comment: Issue also occurs if .read() is used with no size. -- title: wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data - wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances

[issue18610] wsgiref.validator expects wsgi.input read to give exactly one arg

2013-07-31 Thread Robin Schoonover
New submission from Robin Schoonover: wsgiref.validator requires wsgi.input's read to always give EXACTLY one argument. This is incorrect. It's own documentation says: * That wsgi.input is used properly: - .read() is called with zero or one argument PEP says: A server should allow read

[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg

2013-07-31 Thread Robin Schoonover
Changes by Robin Schoonover ro...@cornhooves.org: -- title: wsgiref.validator expects wsgi.input read to give exactly one arg - wsgiref.validate expects wsgi.input read to give exactly one arg ___ Python tracker rep...@bugs.python.org http

[issue8323] multiprocessing.Queue ignores pickle restrictions in .put()

2010-04-05 Thread Robin Schoonover
New submission from Robin Schoonover e...@cornhooves.org: The multiprocessing module's version of the Queue class, which causes objects to be pickled for process to process transfer, ignores pickle restrictions when objects are added to the queue. Example code (buffer isn't pickleable

[issue8323] multiprocessing.Queue ignores pickle restrictions in .put()

2010-04-05 Thread Robin Schoonover
Robin Schoonover e...@cornhooves.org added the comment: Since these sort of buffer objects don't exist in 3.x (so far as I know), I came up with a different way to test in 3.x (basically, trying to pickle bound or unbound methods). It turns out that using this method to test it in 2.6 seems

[issue3871] cross and native build of python for mingw32 with distutils

2010-01-28 Thread Robin Schoonover
Changes by Robin Schoonover e...@cornhooves.org: -- nosy: +rschoon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list