[issue20905] Adapt heapq push/pop/replace to allow passing a comparator.
Michael Rolle added the comment: I realize this request is closed, but I hope people will still be reading this comment, and can perhaps either reopen it or submit a new request. I don't know how to submit a new request myself. ... I'd like to see (key=) capability somehow, without degrading performance of time-critical applications. I've got some ideas for your consideration, if you please. 1. Make the heapq into a heap class. It would be more natural (for me, anyway) to push/pop using the heap's methods, rather than calling a function in the heap package and having to specify the heap list as well. A heap class in C could outperform current heapq with lists by storing the member objects in an internal array. This would also solve the issue of having the user switch comparison methods in the middle of things. The comparison method would be specified when the heap is constructed. It could be changed later, at the expense of resorting the heap. I suggest the comparison method parameters be the same as for .sort () and sorted (). By default, the heap class would directly compare elements using __lt__, and so the performance would be as good, or slightly better, than the current heapq package functions. 2. In my own use case, I have to define __lt__ for the objects in my heapq by comparing the _keys_ of the two items. So push/pop wind up calling the key function many times anyway. The heap push/pop themselves could do this same work probably a bit faster in C code than would calling my own __lt__ method. 3. Performance could be improved when there is a key function by having the heap store both the heap elements and their keys. I believe a C implementation could benefit by storing key and value objects next to each other in the internal array. 4. I'd be happy to submit a reference implementation, only I don't have time to do that right now, sorry. I'm sure someone else would be up to the challenge. -- nosy: +mrolle ___ Python tracker <https://bugs.python.org/issue20905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28646] Using a read-only buffer.
New submission from Michael Rolle: Suggest that the _CData.from_buffer (source) method allow a read-only source as an argument, in which case any assignments to the object would raise some type of exception. If the source is shared with some writable object, then changes to said object would be reflected in the _CData object. If this behavior is not what you want, then you could just make a new method called, say, from_buffer_shared (source). -- components: ctypes messages: 280375 nosy: mrolle priority: normal severity: normal status: open title: Using a read-only buffer. type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux
Michael Rolle added the comment: As a separate issue, I'd like to find an appropriate package, other than ctypes, for interpreting data bytes in a consistently defined manner, independent of the platform I'm running on. The struct package is perfect where there are no bitfields involved, i.e., where each item occupies whole bytes. But it doesn't support packing/unpacking bitfields. Actually, ctypes could fit the bill if you specified that bitfields be allocated from MSB to LSB for BigEndianStructure, and from LSB to MSB for LittleEndianStructure. This way, for instance, it wouldn't matter if a sequence of 4-bit fields were based on c_ubyte or c_ushort, etc. Each pair of fields would be allocated to the next consecutive byte. And if the platform native compiler for some strange reason doesn't follow either of these rules, then Structure would follow the platform compiler. differs from both Big and Little -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux
Michael Rolle added the comment:
Similar problem with 2.7.8 with cygwin.
My example is:
Python 2.7.8 (default, Jul 25 2014, 14:04:36)
[GCC 4.8.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> class C (BigEndianStructure): _fields_ = (('rva', c_uint, 31), ('fl',
>>> c_uint, 1))
...
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x00\x00\x00'
0L
0L
>>> x.rva = 256
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x00\x02\x00'
256L
0L
>>> x.rva = 256
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x00\x02\x00'
256L
0L
>>> x.fl = 1
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x02\x00\x01'
65536L
1L
>>> x.fl = 1
>>> buffer(x)[:]; x.rva; x.fl
'\x01\x00\x02\x01'
8388864L
1L
>>> x.fl = 1
>>> buffer(x)[:]; x.rva; x.fl
'\x01\x02\x00\x01'
8454144L
1L
>>> x.fl = 1
>>> buffer(x)[:]; x.rva; x.fl
'\x01\x00\x02\x01'
8388864L
1L
>>> x.rva = 256
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x00\x02\x01'
256L
1L
>>> x.rva = 256
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x00\x02\x00'
256L
0L
>>> x.rva = 256
>>> buffer(x)[:]; x.rva; x.fl
'\x00\x00\x02\x00'
256L
0L
I'm disappointed that this bug hasn't been fixed after two years!
I understand that ctypes might not be portable across different
platforms. However, the above behavior is clearly wrong.
BTW, I also have Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64
bit (AMD64)] on win32, and this version works fine.
--
nosy: +mrolle
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20629>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
