[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 <rep...@bugs.python.org> <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 rep...@bugs.python.org 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 rep...@bugs.python.org 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 rep...@bugs.python.org 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 mdeh...@users.sourceforge.net: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org 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 rep...@bugs.python.org 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 rep...@bugs.python.org 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 rep...@bugs.python.org 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 rep...@bugs.python.org 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('?xml version=1.0?')
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 ?xml version=1.0?
This gives an error:
Traceback (most recent call last):
File stdin, line 1, in module
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 stdin, line 1, in module
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 rep...@bugs.python.org
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 stdin, line 1, in module ValueError: I/O operation on closed file. This happens after 335 out of the 430 lines have been read (the last line read is pThe a class=reference external href=/psf/Python Software Foundation/a 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 rep...@bugs.python.org 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 mdeh...@users.sourceforge.net 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 function open at 0x781f0 import bz2 bz2.open Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'module' object has no attribute 'open' -- nosy: +mdehoon ___ Python tracker rep...@bugs.python.org 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
New submission from Michiel de Hoon mdeh...@users.sourceforge.net: (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 rep...@bugs.python.org 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 mdeh...@users.sourceforge.net added the comment: The patch fixes the problem on Mac OS X 10.4. I'll try on 10.5 tomorrow. Thanks! -- ___ Python tracker rep...@bugs.python.org 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 mdeh...@users.sourceforge.net 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 rep...@bugs.python.org 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
