[issue41285] memoryview does not support subclassing
Michiel de Hoon added the comment: You are correct, this is indeed a duplicate of #13797. My apologies for not finding this issue before opening a new one. If there are no objections, I will close this issue as a duplicate. -- ___ Python tracker <https://bugs.python.org/issue41285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41285] memoryview does not support subclassing
Michiel de Hoon added the comment: Thank you, I have posted an explanation in the "Ideas" category of discuss.python.org. -- ___ Python tracker <https://bugs.python.org/issue41285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41285] memoryview does not support subclassing
New submission from Michiel de Hoon : Currently memoryview does not support subclassing: >>> class B(memoryview): pass ... Traceback (most recent call last): File "", line 1, in TypeError: type 'memoryview' is not an acceptable base type Subclassing memoryview can be useful when - class A supports the buffer protocol; - class B wraps class A and should support the buffer protocol provided by class A; - class A does not support subclassing. In this situation, class B(memoryview): def __new__(cls, a): return super(B, cls).__new__(cls, a) where a is an instance of class A, would let instances of B support the buffer protocol provided by a. Is there any particular reason why memoryview does not support subclassing? -- components: C API messages: 373554 nosy: mdehoon priority: normal severity: normal status: open title: memoryview does not support subclassing type: enhancement versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: Anything I can do to help this patch move forward? -- ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: I tried the patch hook-interrupt.3.6.patch ; as far as I can tell it is working fine. -- ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: I am not sure if I follow. With the patch to _tkinter.c, interrupts seem to work correctly with all three variations of PyOS_InputHook. -- ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: Patch for Modules/_tkinter.c. To be used together with issue23237.version2.patch. -- Added file: http://bugs.python.org/file39616/_tkinter.c.patch ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: I am uploading an updated version of the patch. I'd be happy to submit a patch to the documentation also, but wasn't able to find it on Mercurial. Can somebody please point me to the right repository for the documentation? -- Added file: http://bugs.python.org/file39608/issue23237.version2.patch ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: Vadmium, thank you for carefully looking at this patch. Polling PyErr_CheckSignals() directly in the tkinter EventHook loop works in the #if defined(WITH_THREAD) || defined(MS_WINDOWS) block, as there Tcl_DoOneEvent(TCL_DONT_WAIT) exits immediately. However in the #else block Tcl_DoOneEvent(0) is called. Here, Tcl_DoOneEvent does not return until there is some event. So if a user presses Ctrl-C, then trip_signal in Modules/signalmodule.c does get called, but Tcl_DoOneEvent won't know about it and will continue to wait for an event. The KeyboardInterrupt will then happen only after the user presses enter or moves the mouse over the Tk window. That said, now I realize that my patch doesn't solve that problem either. So I need to go back and think of a proper way to exit Tcl_DoOneEvent in case of an interrupt. I think that that is a sufficiently complex problem to warrant its own patch. For the current patch, I suggest we consider the changes to Modules/readline.c and Parser/myreadline.c only, and leave out any changes to Modules/_tkinter.c. In response to your comments on Modules/readline.c: >Modules/readline.c:998: > if(PyOS_InputHook) has_input = PyOS_InputHook(); > This contradicts the documentation, which says > PyIO_InputHook()’s return value is ignored Yes you are correct; the documentation will have to be updated if we start using the return value of PyOS_InputHook(). My proposal to use return value == -1 and errno == EINTR to indicate interrupts is based on the convention for select(). In extension modules such as Tkinter, PyOS_InputHook points to a function that returns if input is available on stdin, so effectively it's like a simplified version of select() that only looks at stdin. In Tkinter, pygtk, and PyQT, PyOS_InputHook returns 0; in matplotlib's MacOSX backend it returns +1. So I think it is safe to start using -1 for interrupts. But yes, the documentation will have to be updated. >Modules/readline.c:1065: > old_timeout = rl_set_keyboard_input_timeout(0); > Won’t this poll PyOS_InputHook over and over, wasting CPU time? No it won't. In well-designed code (including Tkinter, pygtk, PyQT, and matplotlib's MacOSX backend) PyOS_InputHook does not return until there is some activity on stdin, and therefore PyOS_InputHook does not get called repetitively anyway. So the timeout is only relevant as the delay until readline() calls PyOS_InputHook(). Since there is no point to this delay, it's better to set it to zero. -- ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Changes by Michiel de Hoon : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
Michiel de Hoon added the comment: I am attaching a patch for this bug for Python 2.7. -- keywords: +patch nosy: +mdehoon Added file: http://bugs.python.org/file37832/issue23237.patch ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3180] Interrupts are lost during readline PyOS_InputHook processing
Michiel de Hoon added the comment: I have opened a new issue 23237 for this bug; please see http://bugs.python.org/issue23237 -- ___ Python tracker <http://bugs.python.org/issue3180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening)
New submission from Michiel de Hoon: This bug was previously reported in http://bugs.python.org/issue3180 but was closed after seven years for being out of date. Still, the bug remains: Interrupts are lost during readline PyOS_InputHook processing. To reproduce the bug, try >>> from Tkinter import * >>> Tk() You will notice that Ctrl-C now does not generate a KeybordInterrupt. This bug appears in all Python versions I tested (Python 2.7, 3.3, 3.4) and, judging from the source code, is still present in the current Python source code in Mercurial. The bug appears both on Mac and on Linux; I do not have access to Windows. The suggested patch at http://bugs.python.org/issue3180 makes multiple changes to the behavior of PyOS_InputHook. In particular, it allows for waiting for a file descriptor other than stdin. I think that this is unrelated to the current bug, so it should not be included in the patch, in particular since that would change the API. -- components: Extension Modules messages: 233997 nosy: Michiel.de.Hoon priority: normal severity: normal status: open title: Interrupts are lost during readline PyOS_InputHook processing (reopening) type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3180] Interrupts are lost during readline PyOS_InputHook processing
Michiel de Hoon added the comment: As it happens, we just ran into the same bug. To reproduce this issue, run >>> from Tkinter import * >>> Tk() Then Ctrl-C will not generate a KeyboardInterrupt. At first glance, the solution suggested by the original poster seems good. Can this issue by reopened? I'd be happy to take over this issue report and check the patch in more detail. -- nosy: +Michiel.de.Hoon ___ Python tracker <http://bugs.python.org/issue3180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16726] expat ParseFile expects bytes, not string
New submission from Michiel de Hoon: The expat parser in xml.parsers.expat has a Parse method and a ParseFile method. The Parse method parses a string, however the ParseFile method wants bytes. This is a minimal example of the Parse method: >>> import xml.parsers.expat >>> p = xml.parsers.expat.ParserCreate() >>> p.Parse('') which runs fine. Note that argument to p.Parse is a string, not bytes. This is the corresponding example of ParseFile: >>> import xml.parsers.expat >>> handle = open("test.xml") >>> p = xml.parsers.expat.ParserCreate() >>> p.ParseFile(handle) where the file test.xml only contains This gives an error: Traceback (most recent call last): File "", line 1, in TypeError: read() did not return a bytes object (type=str) Opening the file test.xml in binary raises an Error: >>> import xml.parsers.expat >>> handle = open("test.xml", "rb") >>> p = xml.parsers.expat.ParserCreate() >>> p.ParseFile(handle) Traceback (most recent call last): File "", line 1, in xml.parsers.expat.ExpatError: no element found: line 2, column 0 suggesting that in reality, the expat Parser needs a string, not bytes. (the same error appears with a more meaningful XML file). I would expect that both Parse and ParseFile accept strings, but not bytes. -- messages: 177733 nosy: mdehoon priority: normal severity: normal status: open title: expat ParseFile expects bytes, not string type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16726> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16723] io.TextIOWrapper on urllib.request.urlopen terminates prematurely
New submission from Michiel de Hoon: I am trying to use io.TextIOWrapper to wrap a handle returned by urllib.request.urlopen. Reading line-by-line from the wrapped handle terminates prematurely. As an example, consider this script: import urllib.request import io url = "http://www.python.org"; handle = urllib.request.urlopen(url) wrapped_handle = io.TextIOWrapper(handle, encoding='utf-8') for line in wrapped_handle: pass This gives: Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file. This happens after 335 out of the 430 lines have been read (the last line read is "The Python Software Foundation holds the intellectual property\n", which is line 335 on the www.python.org website. -- messages: 177726 nosy: mdehoon priority: normal severity: normal status: open title: io.TextIOWrapper on urllib.request.urlopen terminates prematurely type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5863] bz2.BZ2File should accept other file-like objects. (issue4274045)
Michiel de Hoon added the comment: Would it be possible to add an open() function to the bz2 module? Currently gzip has such a function, but bz2 does not: >>> import gzip >>> gzip.open >>> import bz2 >>> bz2.open Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'open' >>> -- nosy: +mdehoon ___ Python tracker <http://bugs.python.org/issue5863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8868] Framework install does not behave as a framework
Michiel de Hoon added the comment: The patch solves the problem also on Mac OS X 10.5 (I tried 32-bits and 64-bits with the current python in trunk, after applying the patch). Thanks again! -- ___ Python tracker <http://bugs.python.org/issue8868> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8868] Framework install does not behave as a framework
Michiel de Hoon added the comment: The patch fixes the problem on Mac OS X 10.4. I'll try on 10.5 tomorrow. Thanks! -- ___ Python tracker <http://bugs.python.org/issue8868> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8868] Framework install does not behave as a framework
New submission from Michiel de Hoon : (The discussion for this bug started on the pythonmac-sig mailing list; see http://mail.python.org/pipermail/pythonmac-sig/2010-May/022362.html) When I try to install Python as a framework: ./configure --enable-framework make make install then Python gets installed under /Library/Frameworks/Python.framework/Versions/2.7, but it doesn't seem to function as a framework: >>> import MacOS >>> MacOS.WMAvailable() False >>> Python 2.6.5 returns True here. This is important for GUI extension modules; such modules do not interact correctly with the window manager if Python is not installed as a framework. I see the same behavior with the current Python in trunk with Mac OS X 10.4 and 10.5 both with Python installed from source and the precompiled python 2.7b2. Python revision 77030 seems to be the last revision without this problem. In revision 77031, posix_spawn() was introduced instead of execv() in pythonw.c to start the Python executable. -- assignee: ronaldoussoren components: Macintosh messages: 106838 nosy: mdehoon, ronaldoussoren priority: normal severity: normal status: open title: Framework install does not behave as a framework type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue8868> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3205] bz2 iterator fails silently on MemoryError
New submission from Michiel de Hoon <[EMAIL PROTECTED]>: PyMem_Malloc is called in the Util_ReadAhead function in bz2module.c. The code checks if PyMem_Malloc returns NULL, but in that case no MemoryError is raised. So, if in the following code: >>> input = bz2.BZ2File("myfile.txt.bz2") >>> for line in input: ... # do something with the line Python runs out of memory during the for-loop, then the for-loop exits without an Exception being raised. To the user, it appears that the end of the myfile.txt.bz2 file was reached and that no error occurred. In the attached patch, I call PyErr_NoMemory() if PyMem_Malloc fails. This then raises the MemoryError exception as appropriate. -- components: Extension Modules files: bz2module.c.patch keywords: patch messages: 68770 nosy: mdehoon severity: normal status: open title: bz2 iterator fails silently on MemoryError type: behavior Added file: http://bugs.python.org/file10740/bz2module.c.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3205> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com