[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
[issue33749] pdb.Pdb constructor stdout override required to disable use_rawinput
Michiel added the comment: Based on code inspection, this affects 2.7 - current master -- versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33749] pdb.Pdb constructor stdout override required to disable use_rawinput
New submission from Michiel :
It looks like there's possibly a typo/small bug in the pdb.Pdb code. If I
supply the stdin argument to the constructor, and provide e.g. a io.StringIO
object, then I expect commands to be read from there. This however doesn't
happen. If I additionally supply a stdout argument, then it works.
This is because use_rawinput is only disabled if stdout is specified, see
https://github.com/python/cpython/blob/3.7/Lib/pdb.py#L144:
...
def __init__(self, completekey='tab', stdin=None, stdout=None, skip=None,
nosigint=False, readrc=True):
bdb.Bdb.__init__(self, skip=skip)
cmd.Cmd.__init__(self, completekey, stdin, stdout)
if stdout:
self.use_rawinput = 0
...
I think it should be disabled if stdin is supplied, or possibly if either is
specified (I'm not sure).
Repro:
import pdb
import io
pdb_script = io.StringIO("p 'hello';; c")
output = io.StringIO()
Buggy behaviour:
In [5]: pdb.Pdb(stdin=pdb_script).set_trace()
--Call--
> /usr/lib/python3.6/site-packages/IPython/core/displayhook.py(247)__call__()
-> def __call__(self, result=None):
(Pdb) c
Expected behaviour:
(Pdb) 'hello'
Working if stdout is supplied:
In [6]: pdb_script.seek(0)
Out[6]: 0
In [7]: pdb.Pdb(stdin=pdb_script, stdout=output).set_trace()
In [8]: print(output.getvalue())
--Call--
> /usr/lib/python3.6/site-packages/IPython/core/displayhook.py(247)__call__()
-> def __call__(self, result=None):
(Pdb) 'hello'
I would've had a go at fixing this, but even after reading the docs at
https://docs.python.org/3/library/cmd.html#cmd.Cmd.use_rawinput it's not
entirely obvious to me which combinations of stdin/stdout overrides should be
valid and when use_rawinput should be set to 0. However, I'm pretty sure it
should at least be set to 0 if stdin is supplied, which currently isn't the
case.
--
components: Library (Lib)
messages: 318536
nosy: m01
priority: normal
severity: normal
status: open
title: pdb.Pdb constructor stdout override required to disable use_rawinput
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue33749>
___
___
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
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
Michiel added the comment: Hey Peter, Cool, thanks for the feedback! Looks like my email replies didn't get attached to the bug tracker.. I've just signed the form. Regarding the .broadcast* question, I think that's probably best handled in a separate issue, but I think there are two other options in addition to the one you suggested: a) ensuring the .broadcast_address() function isn't actually defined for IPv6Networks (this would also trigger an exception if someone tried to call it, like you suggested) or b) making it return the link-local all-nodes multicast address. Personally speaking I'd probably favour option a, but I'm still new to Python standard library development ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19157 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
New submission from Michiel:
(See also: http://stackoverflow.com/q/19159168/1298153. This is my first bug
submission)
Contrary to IPv4, IPv6 does not have a concept of network and broadcast
addresses. It looks like the same code is used to generate the hosts for both
IPv4 and IPv6, resulting in the network and broadcast addresses being omitted
in IPv6, even though these are valid IPv6 addresses, albeit they may have a
special meaning.
Repro:
$ python3
Python 3.3.2 (default, Sep 6 2013, 09:30:10)
[GCC 4.8.1 20130725 (prerelease)] on linux
Type help, copyright, credits or license for more information.
import ipaddress
print(\n.join([str(x) for x in
ipaddress.ip_network(2001:0db8::/120).hosts()]))
2001:db8::1
2001:db8::2
...
2001:db8::fe
hex(int(ipaddress.ip_address('2001:db8::fe')))
'0x20010db800fe'
The v4 docs state, that the hosts() function...
Returns an iterator over the usable hosts in the network. The usable hosts are
all the IP addresses that belong to the network, except the network address
itself and the network broadcast address.
Assuming hosts excludes routers, this should probably return a generator/an
iterator covering all addresses in the network, apart from the very first one
(all 0's after the prefix), since this is typically the subnet-router anycast
address (http://tools.ietf.org/html/rfc4291#section-2.6.1).
While the top range (including the currently omitted prefix + all 1's
address) contains reserved anycast addresses
(http://tools.ietf.org/html/rfc2526), I'm not sure whether excluding them is a
great idea, as in the future some of these may become valid (anycast) host
addresses.
Backwards compatibility considerations:
The proposed fix would add one extra address to the ones already returned. I
think this is less likely to break code, than, say, removing all the reserved
anycast addresses.
Implementation options:
1. override _BaseNetwork hosts() implementation in IPv6Network
2. add an is_host_address(ip_address) method, or something along those lines,
to IPv4 and IPv6Address classes, and change the hosts() function to only return
addresses for which is_host_address is True. This function might be generally
useful, but the implementation is likely to be slower than 1.
3. use address_exclude perhaps..
I'm sure there are many other ways to implement the fix, but I've attached a
naive diff. I'm not sure if there's a better way to implement it that doesn't
involve copying code from hosts()/__iter__ and slightly tweaking it.
With 1:
print(\n.join([str(x) for x in
ipaddress.ip_network(2001:0db8::/124).hosts()]))
2001:db8::1
2001:db8::2
2001:db8::3
2001:db8::4
2001:db8::5
2001:db8::6
2001:db8::7
2001:db8::8
2001:db8::9
2001:db8::a
2001:db8::b
2001:db8::c
2001:db8::d
2001:db8::e
2001:db8::f
--
components: Library (Lib)
files: ipaddress_ipv6_hosts.diff
keywords: patch
messages: 198927
nosy: m01
priority: normal
severity: normal
status: open
title: ipaddress.IPv6Network.hosts function omits network and broadcast
addresses
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31956/ipaddress_ipv6_hosts.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19157
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16765] Superfluous import in cgi module
Michiel Holtkamp added the comment: Thanks, I will do that next time. Happy holidays everyone! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16765] Superfluous import in cgi module
New submission from Michiel Holtkamp: The standard module cgi.py from Python 2.x imports urllib, but urllib is not used. This causes a little bit of extra memory usage and a small increase in load time. It's not much, but it was enough for me to notice when I was profiling my program. I think the urllib import can be safely removed in 2.6 and 2.7. I've tested without the import and it works as expected in my case. In Python 3.2 (other 3.x versions not checked), urllib.parse is imported but here it is actually used, so no problem there. PS. first time submitting a bug here, so if I'm doing something wrong, please be gentle :) -- components: Library (Lib) messages: 178055 nosy: mjholtkamp priority: normal severity: normal status: open title: Superfluous import in cgi module type: performance versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16765] Superfluous import in cgi module
Michiel Holtkamp added the comment: Fair enough, I think I'm using 2.7 only. I wasn't sure about the patch format, so I added a unified diff. If you require a different format, please let me know. -- keywords: +patch Added file: http://bugs.python.org/file28420/patch-python2.7-cgi.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[issue11878] No SOAP libraries available for Python 3.x
New submission from Michiel Van den Berghe michiel@gmail.com: There doesn't seem to exist a SOAP library for Python 3.x. Several different third party libraries exist for the 2.x releases, but none of these are being ported to 3.x. None of these modules are easily ported using 2to3 due to string encoding issues. Seeing how SOAP is a major webservices technologies, I think Python should get its own standard SOAP module to keep up with its batteries included principle. -- components: Library (Lib) messages: 134064 nosy: Michiel.Van.den.Berghe priority: normal severity: normal status: open title: No SOAP libraries available for Python 3.x versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11878 ___ ___ 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
[issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick
Michiel Overtoom mot...@xs4all.nl added the comment: I experience the same, on FreeBSD 7.0-REL, with tkinter compiled to use Tk8.5 instead of Tk8.4. Tkinter compiled for Tk8.4 doesn't have the problem. Moving the mouse over the text widget changes the cursor to the I-beam as expected, but click on text doesn't position the beam at the mouse position. It is also impossible to select text with the mouse. Selecting text with shift-arrow keys works, however. The same bug has been reported on the OLPC wiki: http://dev.laptop.org/ticket/7661 http://wiki.laptop.org/go/User:Rmyers/IDLE_on_the_XO -- nosy: +michiel.overtoom ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2995 ___ ___ 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
