[issue11852] New QueueListener is unusable due to threading and queue import
New submission from Baptiste Lepilleur : How to reproduce: >>> from logging.handlers import QueueListener >>> from multiprocessing import Queue >>> q = Queue(100) >>> l = QueueListener(q) Traceback (most recent call last): File "", line 1, in File "C:\Python32\lib\logging\handlers.py", line 1234, in __init__ self._stop = threading.Event() NameError: global name 'threading' is not defined And after adding the 'threading' import, you run into a second missing module: Traceback (most recent call last): File "C:\Python32\lib\threading.py", line 736, in _bootstrap_inner self.run() File "C:\Python32\lib\threading.py", line 689, in run self._target(*self._args, **self._kwargs) File "C:\Python32\lib\logging\handlers.py", line 1297, in _monitor except queue.Empty: NameError: global name 'queue' is not defined Solution: Adds import of 'threading' and 'queue' module in logging.handlers module. -- components: Library (Lib) messages: 133862 nosy: blep priority: normal severity: normal status: open title: New QueueListener is unusable due to threading and queue import type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11852] New QueueListener is unusable due to threading and queue import
Baptiste Lepilleur added the comment: Forgot to give the precise python version: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 -- ___ Python tracker <http://bugs.python.org/issue11852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11852] New QueueListener is unusable due to missing threading and queue import
Changes by Baptiste Lepilleur : -- title: New QueueListener is unusable due to threading and queue import -> New QueueListener is unusable due to missing threading and queue import ___ Python tracker <http://bugs.python.org/issue11852> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10870] Last line of argparse code samples can not be read on Windows
New submission from Baptiste Lepilleur : When the code samples from the CHM documentation are displayed, if the lines are too long, a scroll bar is added at the bottom which prevents reading the last line of the code sample. Usually this can be worked-around by making the windows larger, but some examples in the documentation of the argparse are so wide that even in full screen, the window is not wide enough. I attached a screen capture to illustrate the issue (taken from section 14.4.3.3. nargs of Python 3.2b2). This is even worth with one-liner code sample when not browsing full screen (e.g. with the index on the side). Environment: Windows XP SP3, resolution: 1024x768, python 3.2b2. I don't know if it is possible, but adding a blank line at the end of code sample that are more than 80 characters wide would likely work-around the issue. -- assignee: d...@python components: Documentation files: argparse-codesample-unreadable.png messages: 125832 nosy: blep, d...@python priority: normal severity: normal status: open title: Last line of argparse code samples can not be read on Windows versions: Python 3.2 Added file: http://bugs.python.org/file20321/argparse-codesample-unreadable.png ___ Python tracker <http://bugs.python.org/issue10870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10871] argparse example use "file" instead of "open"
New submission from Baptiste Lepilleur :
In section "14.4.3.6. type" of the argparse module, the following code sample
is given:
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', type=int)
>>> parser.add_argument('bar', type=file)
>>> parser.parse_args('2 temp.txt'.split())
Namespace(bar=, foo=2)
The built-in "file" used for argument 'bar' no longer exists in python 3.2.
--
assignee: d...@python
components: Documentation
messages: 125834
nosy: blep, d...@python
priority: normal
severity: normal
status: open
title: argparse example use "file" instead of "open"
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue10871>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7280] PCBuild instruction says to use nasmw.exe but it no longer exist
New submission from Baptiste Lepilleur : PCBuild requires nasmw.exe but it no longer exists in the latest version of nasm. I had to rename nasm.exe to nasmw.exe. Would be nice to add this to the readme to avoid confusion... -- components: Build files: nasm-doc.patch keywords: patch messages: 95025 nosy: blep severity: normal status: open title: PCBuild instruction says to use nasmw.exe but it no longer exist versions: Python 3.1 Added file: http://bugs.python.org/file15286/nasm-doc.patch ___ Python tracker <http://bugs.python.org/issue7280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7287] import hook demo does not work
New submission from Baptiste Lepilleur : The import hook demo in the source directory Python-3.1.1\Demo\imputil\knee.py fails to run correctly: Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import knee >>> import ctypes.utils Traceback (most recent call last): File "", line 1, in TypeError: import_hook() takes at most 4 positional arguments (5 given) >>> -- components: Demos and Tools messages: 95040 nosy: blep severity: normal status: open title: import hook demo does not work type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7578] Behavio of operations on a closed file object is not documented correctly
New submission from Baptiste Lepilleur : The io.IOBase class doc says: """Note that calling any method (even inquiries) on a closed stream is undefined. Implementations may raise IOError in this case.""" But the io.IOBase.close() method document says: """Once the file is closed, any operation on the file (e.g. reading or writing) will raise an IOError.""" which unlike the class doc is not conditional about the behavior... Experimentation (see below) show that I get a ValueError in practice (python 3.1, but also true for 2.6) with io.BufferedWriter and io.StringIO objects. >>> with open( 'dummy', 'wb') as f: ... pass ... >>> f.write( b'' ) Traceback (most recent call last): File "", line 1, in ValueError: write to closed file >>> f.writable() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file >>> import io >>> s = io.StringIO() >>> s.close() >>> s.read() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file -- assignee: georg.brandl components: Documentation messages: 96892 nosy: blep, georg.brandl severity: normal status: open title: Behavio of operations on a closed file object is not documented correctly versions: Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue7578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7578] Behavior of operations on a closed file object is not documented correctly
Changes by Baptiste Lepilleur : -- title: Behavio of operations on a closed file object is not documented correctly -> Behavior of operations on a closed file object is not documented correctly ___ Python tracker <http://bugs.python.org/issue7578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17285] subprocess.check_output incorrectly state that output is always bytes
New submission from Baptiste Lepilleur: Documentation states: >>> help( subprocess.check_output ) check_output(*popenargs, timeout=None, **kwargs) Run command with arguments and return its output as a byte string. But the most common usage is: >>> subprocess.check_output( 'echo test', shell=True, universal_newlines=True ) 'test\n' Which obviously output a text string, not a byte string. IMHO, one of the example should also be modified to show the existence of this flag, as it is what user want 90% of the times. -- assignee: docs@python components: Documentation messages: 182868 nosy: Baptiste.Lepilleur, docs@python priority: normal severity: normal status: open title: subprocess.check_output incorrectly state that output is always bytes versions: Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue17285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17286] Make subprocess handling text output with universal_newlines more obious
New submission from Baptiste Lepilleur: It tooks me a while to figure out that using universal_newlines was the solution to "tell" subprocess that I wanted text string output instead of byte string. A search on stackoverflow shows that this issue is common and the solution nearly unknown (answer is usually to decode the byte string manually)... Because dealing with text output is IMHO the most common use case, the subprocess documentation should make it easier to "find" the recipe. I would suggest changing the documentation so that the universal_newlines is made obvious as it is very important: 1) the first /bin/vikings example be modified to show the use of this flag (at the top of the documentation, most people copy/past that): >>> p = subprocess.Popen(args, universal_newlines=True) # Success! and at a small comment below the example to explain that flag 2) change other example similarly when that make sense, IMHO: - ifconfig example - one of the subprocess.check_output example - subprocess.check_output() example, consider separating the byte string / text string example for increased visibility 3) consider adding a section with an obvious title "Dealing with binary and text input/output", providing examples and pointer to the correct documentation (I would place it after the convenience functions section for visibility). I think this would help attracting "eye" on this large piece of documentation. -- assignee: docs@python components: Documentation messages: 182872 nosy: Baptiste.Lepilleur, docs@python priority: normal severity: normal status: open title: Make subprocess handling text output with universal_newlines more obious type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue17286> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
