[issue12881] ctypes: segfault with large structure field names
Meador Inge mead...@gmail.com added the comment: On Fri, Sep 2, 2011 at 4:26 PM, Amaury Forgeot d'Arc rep...@bugs.python.org wrote: Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Certainly the effect of some alloca call with a large value, then the stack overflows. Yeah, I noticed that too. I was actually pretty surprised to see alloca in there :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12764] segfault in ctypes.Struct with bad _fields_
Meador Inge mead...@gmail.com added the comment: This has been fixed. I verified tip and 2.7. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12764 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5149] syntactic sugar: type coercion on pointer assignment
Meador Inge mead...@gmail.com added the comment:
This is busted for plain old assignment too:
Python 3.3.0a0 (default:6374b4ffe00c, Sep 2 2011, 23:50:39)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type help, copyright, credits or license for more information.
from ctypes import *
buff = create_string_buffer(b'foo')
p = c_char_p()
p.value = addressof(buff)
print(p.value)
b'foo'
p.value = buff.value
print(p.value)
b'foo'
p.value = buff
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: string or integer address expected instead of c_char_Array_4 instance
I think having the conversion is an entirely reasonable request. It is the
equivalent of:
char buff[128] = foo;
char *p = buff;
in C. I imagine a lot of C programmers would expect this behavior.
Also, 'ctypes' already does this type of conversion for function parameters.
Consider a function exported from a shared library 'libfoo' called
'print_string':
void print_string (char *str)
{
printf (%s\n, str);
}
The following all work fine:
libfoo = CDLL(./libfoo.so.1.0)
buff = create_string_buffer(foo)
libfoo.print_string(buff)
foo
libfoo.print_string(foo)
foo
libfoo.print_string(addressof(buff))
foo
I am working on a patch for this. I will post it soon.
--
assignee: theller -
nosy: +amaury.forgeotdarc, belopolsky, meadori -theller
stage: test needed - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5149
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Meador Inge mead...@gmail.com added the comment: On Thu, Sep 1, 2011 at 9:45 AM, Vlad Riscutia rep...@bugs.python.org wrote: Vlad Riscutia riscutiav...@gmail.com added the comment: Meador, I believe this was the first issue on the tracker that got me looking into bitfield allocation. I agree that big-endian on MSVC doesn't make too much sense but you can disregard that - using default endianess will still yield different sizes of bitfields when compiled with GCC and MSVC. Sure, but this particular issue is purporting that the layout of the structure is incorrect, not that the size is. Basically bitfield allocation is compiler specific and patch in issue12528 implements a way to select which allocation strategy to be used at runtime instead of hardcoding the one with which Python is compiled. This should improve cross-compiler interop. I wanted to hyperlink that patch to all other bitfield bugs, that's why I followed up with link to the patch. Yes, it is very compiler specific. I have some thoughts about making this configurable, but I will comment on issue12528 with those. Feel free to close this, either as not an issue or as a duplicate of issue12528. I will open a documentation bug and close this one out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Meador Inge mead...@gmail.com added the comment: As stated, how a particular compiler allocates bitfields is *extremely* implementation specific. There can be differences in implementations between different compilers, different *versions* of the same compiler, and different invocations of the same compiler where the options are varied. I am wondering whether adding this feature will open up a can of worms that we don't want to deal with. There are other options beyond MSVC and GCC that seem reasonable. For example, GCC packs bitfields together on structures defined with '__attribute__((packed))'. Do we need a GCCPACKED option now? Also, GCC 4.4 fixed a bug that can lead to differences in structure layout from previous versions. See -Wpacked-bitfield-compat option [1]. Do we need a GCC44 option now? Finally, structure layout is architecture specific. GCC for x86, for example, has the 'ms_struct' attribute extensions for x86 [2]. Does this mean that for a GCC compiled Python that the MSVC option will only work for an x86 host? My point is that there are many, many variations on how a *single* compiler can allocate bitfields. So just saying GCC allocation strategy is not adequate. So, lets take a step back. What exact problem is this feature trying to solve? Is one of the use cases that 'ctypes' for a Windows hosted Python built with MSVC++ can interop with C code compiled with a Windows hosted GCC (e.g. cygwin)? If so, then is that realistic? ISTM, that there are other ABI differences that would prevent that from working. It seem perfectly reasonable to me that ctypes will only interact with bits that were constructed with the exact same compiler (and options) as the interpreter itself. If it is not already, then we should document this. [1] http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [2] http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html -- nosy: +meadori ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Meador Inge mead...@gmail.com added the comment: Hi Vlad, On Thu, Sep 1, 2011 at 1:30 PM, Vlad Riscutia rep...@bugs.python.org wrote: Vlad Riscutia riscutiav...@gmail.com added the comment: Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC and MSVC builds. This feature tries to remove the hardcoded behavior and implement it as a runtime option. This should improve interop with other compilers. Currently I provided these for MSVC-style and GCC-style bitfield allocations. These, of course, can be extended with other strategies. Yup, I understand what the feature is doing. I just wanted to reiterate (as I am sure you already know) that typically the rules for implementing bit fields in a particular compiler are pretty complex. I just wanted to make sure that the use cases are out there to justify the complexity. issue11920 really does seem like a use case where someone would otherwise be stuck without a runtime configurable allocation strategy. BTW, out of curiosity I explored the packed case that I mentioned earlier with GCC more (reproduction case attached): [meadori@motherbrain ctypes]$ make clean; make rm -f foo.o libfoo.so.1.0 gcc -Wall -fPIC -c foo.c gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o python repro.py In Python: (85, 85) From C: (85, 85) From Python: (85, 85) [meadori@motherbrain ctypes]$ make clean; CFLAGS=-DPACK=1 make rm -f foo.o libfoo.so.1.0 gcc -Wall -fPIC -DPACK=1 -c foo.c gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o python repro.py In Python: (85, 85) From C: (85, 85) From Python: (85, 170) This shows that there are already cases that can't be handled with packed bit fields and GCC. This runtime configuration feature, could fix this case as well. However, it is probably better to wait for a real world use case before implementing some pathological case that I cooked up ;-) Wouldn't a GCC44 constant provided at API level be better than saying you can't interop with anything build with GCC 4.4 and up? Or vice-versa, anything built with GCC 4.4. Yeah, probably so. I think the compiler constraint I stated before is probably a bit too strong. I need to think about it more. But, again, my point is that there are a lot of different variations when it comes to bit field allocations. I don't think we want to end up implementing all of them. -- Added file: http://bugs.python.org/file23084/ctypes-packed-bitfields.tar.bz2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12528 ___ ctypes-packed-bitfields.tar.bz2 Description: BZip2 compressed data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12880] ctypes: clearly document how structure bit fields are allocated
New submission from Meador Inge mead...@gmail.com: As issues like issue6069 and issue11920 allude to, figuring out how 'ctypes' allocates bit-fields is not very clear. The documentation should be enhanced to flesh this out in more detail. As an example, Microsoft documents the VC++ implementation in a reasonably clear manner ( http://msdn.microsoft.com/en-us/library/ewwyfdbe(v=vs.71).aspx ). -- assignee: docs@python components: Documentation messages: 143369 nosy: docs@python, meadori, terry.reedy, vladris priority: normal severity: normal stage: needs patch status: open title: ctypes: clearly document how structure bit fields are allocated type: feature request versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Changes by Meador Inge mead...@gmail.com: -- stage: test needed - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Meador Inge mead...@gmail.com added the comment: I opened issue12880 for the doc bug. Closing this one out ... -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11920] ctypes: Strange bitfield structure sizing issue
Meador Inge mead...@gmail.com added the comment: Hi Steve, There is currently no way to deal with this situation. Vlad has opened issue12528 with a proposal to make the allocation strategy configurable from the 'ctypes' API. Please follow that issue if you are still interested. I am closing this issue. -- nosy: +meadori resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - Implement configurable bitfield allocation strategy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9030] ctypes variable limits
Changes by Meador Inge mead...@gmail.com: -- nosy: -theller stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9030 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9175] ctypes doesn't build on hp-ux
Changes by Meador Inge mead...@gmail.com: -- assignee: theller - nosy: -theller priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6980] fix ctypes build failure on armel-linux-gnueabi with -mfloat-abi=softfp
Meador Inge mead...@gmail.com added the comment: This was, in fact, committed already. -- assignee: theller - nosy: +meadori -theller resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6980] fix ctypes build failure on armel-linux-gnueabi with -mfloat-abi=softfp
Meador Inge mead...@gmail.com added the comment: Whoops. I meant to post a link to the commit before. It is here: http://hg.python.org/cpython/rev/584db03e5248. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5718] Problem compiling ffi part of build on AIX 5.3.
Changes by Meador Inge mead...@gmail.com: -- assignee: theller - nosy: -theller priority: normal - low stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6006] ffi.c compile failures on AIX 5.3 with xlc
Changes by Meador Inge mead...@gmail.com: -- assignee: theller - nosy: -theller priority: normal - low stage: - patch review type: - compile error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12764] segfault in ctypes.Struct with bad _fields_
Meador Inge mead...@gmail.com added the comment: Vlad, Thanks for the patch. A few nits: 1. The test case is in 'test_bitfields.py'. I think it should go in 'test_structures.py'. 2. The test case would probably be cleaner using a 'with' context manager: with self.assertRaises(TypeError): class S(Structure): _fields_ = [(bx, c_int)] A few more test cases might be nice too. 3. The TypeError message display something like: structure field name must be string not bytes maybe the following would be more understandable: field name must be an object of type str not bytes 4. The 'ptr', 'len', and 'buf' initializers are unnecessary. Otherwise, looks good. -- nosy: +meadori stage: - patch review versions: +Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12764 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12881] ctypes: segfault with large structure field names
New submission from Meador Inge mead...@gmail.com:
Reproduced on Fedora 15 with tip Python:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:3102951cc1ce+, Sep 1 2011, 22:19:06)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type help, copyright, credits or license for more information.
import ctypes
[68588 refs]
class S(ctypes.Structure):
... _fields_ = [('x' * 1000, ctypes.c_int)]
...
Segmentation fault (core dumped)
--
components: ctypes
messages: 143376
nosy: amaury.forgeotdarc, belopolsky, meadori
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: segfault with large structure field names
type: crash
versions: Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12881
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Meador Inge mead...@gmail.com added the comment:
Hmmm ... Assuming a native VC++ compiler on an x86 machine running Windows,
then it doesn't make sense to validate these test cases in such an environment.
All the tests are all big-endian.
'ctypes' can't be expected to behave the same as the native compiler that
compiled the Python interpreter for structures of non-native endianities
produced by 'ctypes'. That doesn't make sense. The best we can do is document
how 'ctypes' does handle non-native endianites on various platforms.
FWIW, I did try the first set of tests (http://bugs.python.org/msg88145) with
GCC for a 32-bit MIPS ELF target using the following test case:
#include stdio.h
struct T {
unsigned int x : 31;
unsigned int y : 32;
};
struct S {
unsigned long long x : 31;
unsigned long long y : 32;
};
int main (int argc, char **argv)
{
unsigned char buf[8] = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55};
struct T *t = (struct T*)buf;
struct S *s = (struct S*)buf;
printf (%X, %X\n, t-x, t-y);
printf (%X, %X\n, s-x, s-y);
}
The test output:
Data0 is 0x2AAA, Data1 is 0x for uint
Data0 is 0x2AAA, Data1 is 0x for ulonglong
is correct with respect to that environment.
The difference in the first case (uint) and the second case (ulonglong) is that
the first is placed into two 4-byte unsigned integer units where as the second
is placed into one 8-byte unsigned long long unit.
I am slightly confused how issue12528 is going to address this, when there
seems to be no bug; only what seems to be a test case problem. I think we
should close this issue out.
Another issue should be opened to enhance the documentation, though. We should
document exactly how 'ctypes' does the structure layout for different
endianities on different platforms. Something similar to how VC++ documents
this ( http://msdn.microsoft.com/en-us/library/ewwyfdbe(v=vs.71).aspx ).
--
assignee: theller -
nosy: +meadori -theller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9041] raised exception is misleading
Meador Inge mead...@gmail.com added the comment: That is a good question. While it is true that errors other than 'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is a bad thing. Any errors that come out of 'PyFloat_AsDouble' should be handled on a case-by-case basis and not blindly passed back out the call chain. Otherwise, we may end up passing back errors (which are who knows what) that make sense for a caller of 'PyFloat_AsDouble', but not for callers of 'g_set'. Also, the interface would become variable, meaning that whenever 'PyFloat_AsDouble' introduces new exceptions, then this code would too, which would lead to a somewhat unpredictable interface for callers of 'g_set'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11241] ctypes: subclassing an already subclassed ArrayType generates AttributeError
Meador Inge mead...@gmail.com added the comment: Thanks a lot for committing this for me Amaury. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11241] ctypes: subclassing an already subclassed ArrayType generates AttributeError
Meador Inge mead...@gmail.com added the comment: This patch was marked as accepted, but it doesn't seem to be committed. Will someone commit it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8743] set() operators don't work with collections.Set instances
Changes by Meador Inge mead...@gmail.com: -- resolution: accepted - stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Changes by Meador Inge mead...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7433] MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer
Changes by Meador Inge mead...@gmail.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10320] printf %qd is nonstandard
Meador Inge mead...@gmail.com added the comment: I agree that this violates C99, but is this actually causing any real world problems with the platforms Python supports? If so, then we need a test case. This seems low priority -- assignee: theller - nosy: +amaury.forgeotdarc, belopolsky, meador.inge -theller priority: normal - low stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9651] ctypes crash when writing zerolength string buffer to file
Meador Inge mead...@gmail.com added the comment: Ping. I think this one is OK to commit. -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12740] Add struct.Struct.nmemb
Meador Inge mead...@gmail.com added the comment: Stefan, it is a constructed failure (I hacked the unit test to break it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12740] Add struct.Struct.nmemb
Meador Inge mead...@gmail.com added the comment: On Sun, Aug 14, 2011 at 1:03 PM, Stefan Krah rep...@bugs.python.org wrote: Stefan Krah stefan-use...@bytereef.org added the comment: I like random tests in the stdlib, otherwise the same thing gets tested over and over again. `make buildbottest` prints the seed, and you can do it for a single test as well: $ ./python -m test -r test_heapq Using random seed 5857004 [1/1] test_heapq 1 test OK. Ah, I see. Then you can reproduce a run like: $ ./python -m test -r --randseed=5857004 test_heapq Perhaps it might be useful to include the failing output in the assertion message as well (just in case the seed printing option is not used): == FAIL: test_Struct_nmemb (__main__.StructTest) -- Traceback (most recent call last): File Lib/test/test_struct.py, line 596, in test_Struct_nmemb self.assertEqual(s.nmemb, n, for struct.Struct(%s) % fmt) AssertionError: 3658572 != 3658573 : for struct.Struct(378576l?403320c266165pb992937H198961PiIL529090sfh887898d796871B) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12740] Add struct.Struct.nmemb
Meador Inge mead...@gmail.com added the comment: The functionality part of the patch looks reasonable. However, the pseudo-randomization in the unit tests seems like a bad idea. Say someone is adding a new feature X. Runs the unit tests to find one of them failing. Then runs them again to investigate and they are now passing. Unit tests should be repeatable. -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12744] inefficient pickling of long integers on 64-bit builds
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12744] inefficient pickling of long integers on 64-bit builds
Changes by Meador Inge mead...@gmail.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04
Meador Inge mead...@gmail.com added the comment: Michael, It is hard to tell from your description alone where the bug is. Could you provide more detailed reproduction steps with a test case that exhibits the issue? -- nosy: +jnoller, meador.inge stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11241] ctypes: subclassing an already subclassed ArrayType generates AttributeError
Meador Inge mead...@gmail.com added the comment: Amaury, how about this patch? I got rid of querying the type dictionary and hoisted the creation of the type instance earlier. Then 'PyObject_GetAttrString' can be used to lookup '_length_' and '_type_' by the regular Python attribute lookup rules. I extended the test cases to cover more error paths as well. -- Added file: http://bugs.python.org/file22893/issue11241.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11105] Compiling evil ast crashes interpreter
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11105 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12608] crash in PyAST_Compile when running Python code
Meador Inge mead...@gmail.com added the comment: I have verified that the code checked in for issue12575 keep the test case from this issue from crashing the interpreter: [meadori@motherbrain cpython]$ ./python test.py Traceback (most recent call last): File test.py, line 14, in module compiled = compile(exprAst, foo, single) ValueError: empty body on FunctionDef Do we have any intent on fixing this crasher for 3.2 and 2.7? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12608] crash in PyAST_Compile when running Python code
Meador Inge mead...@gmail.com added the comment: OK, I am marking this as fixed then. If someone decides to fix this in 3.2 or 3.7, then they can reopen the issue. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4841] io's close() not handling errors correctly
Changes by Meador Inge mead...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12613] itertools fixer fails
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12613] itertools fixer fails
Meador Inge mead...@gmail.com added the comment: I see two problems that cause the posted test cases to fail: 1. The 'next' fixer runs before the 'itertools' fixer and strips out a 'power' node. This keeps the 'itertools' fixer from matching. 2. The 'itertools' fixer does not handle any 'trailer' nodes after the itertool function application it is transforming. I have fixed both of these issues in the attached patch. Full test suite run; no regressions. -- keywords: +patch stage: needs patch - patch review type: - behavior Added file: http://bugs.python.org/file22878/issue12613.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12608] crash in PyAST_Compile when running Python code
Meador Inge mead...@gmail.com added the comment: Thanks for the test case Albert. The attached patch adds a unit test based off of the given repro case and fixes the bug in the FunctionDef compiler. The compiler was hitting a NULL pointer deref on FunctionDefs with empty list bodies. Reproduced and fixed on tip. Full test suite ran on Fedora 15; no regressions. -- keywords: +patch nosy: +meador.inge stage: - patch review Added file: http://bugs.python.org/file22852/issue12608.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11241] ctypes: subclassing an already subclassed ArrayType generates AttributeError
Meador Inge mead...@gmail.com added the comment: But what happens with a third level? That doesn't work. I have a test case for that, but the test case has a typo that caused it to pass. I will fix the test case and the code. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11241] ctypes: subclassing an already subclassed ArrayType generates AttributeError
Meador Inge mead...@gmail.com added the comment: Verified that this is still broken in the main development branch. The base type should be checked for '_type_' or '_length_' before throwing an error. Attached is a patch that fixes the problem and adds covering tests. The full test suite passed on OS X 10.6.5 and I ran './python.exe -m test -R : -v test_ctype' to verify that I didn't introduce any resource leaks. -- assignee: theller - keywords: +patch nosy: +amaury.forgeotdarc, belopolsky, meador.inge -theller stage: - patch review versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file21701/issue-11241.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10910] pyport.h FreeBSD/Mac OS X fix causes errors in C++ compilation
Meador Inge mead...@gmail.com added the comment: This doesn't look like it has anything to to with the 'ctypes' library component (http://docs.python.org/library/ctypes). So I am removing 'ctypes' from the 'Components' selection. Please correct me if I am wrong ... -- components: -Extension Modules, Library (Lib), Macintosh, Unicode, ctypes nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10910] pyport.h FreeBSD/Mac OS X fix causes errors in C++ compilation
Changes by Meador Inge mead...@gmail.com: -- components: +Macintosh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9041] raised exception is misleading
Meador Inge mead...@gmail.com added the comment: This problem still occurs in the main development branch. I think the 'PyErr_ExceptionMatches' check that Pauli suggested will work. The same problem exist for 'c_float', 'c_double', and 'c_longdouble'. Attached is a patch that fixes the issue and includes covering tests. Tested on OS X 10.6.5. -- assignee: theller - keywords: +patch nosy: +amaury.forgeotdarc, belopolsky, meador.inge -theller stage: - patch review versions: +Python 3.3 -Python 2.6 Added file: http://bugs.python.org/file21690/issue9041.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9651] ctypes crash when writing zerolength string buffer to file
Meador Inge mead...@gmail.com added the comment: This crash still occurs in the main development branch and Amaury's patch still fixes the problem. I verified that all tests pass on OS X 10.6.5. It should be OK to commit. -- assignee: theller - nosy: +meador.inge -theller versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11477] Bug in code dispatching based on internal slots
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment: Is there still any interest in this work? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment:
Attached is the latest version of the struct string patch. I tested on OS X
10.6.5 (64-bit) and Ubuntu 10.04 (32-bit). I also scanned for memory problems
with Valgrind. There is one test failing on 32-bit systems ('test_crasher').
This is due to the fact that 'struct.pack(357913941b, ...)' no longer tries
to allocate 357913941 format codes. This implementation just allocates *one*
code and assigns a count of 357913941, which is utilized later when
packing/unpacking. Some work could be done to add better large memory
consumption checks, though.
Previous feedback has been incorporated:
1. Multiplicities allowed on struct specifiers.
2. Maximum alignment rule.
3. Struct nesting depth limited (64 levels).
4. The old behavior of only one byte order specified. However,
the code is written in a way such that the scoped behavior
would be easy to add.
As before, there will surely be more iterations, but this is good enough for
general review to see if things are headed in the right direction.
This is a difficult one for review because the diffs are really large. I
placed a review on Rietveld here: http://codereview.appspot.com/3863042/. If
anyone has any ideas on how to reduce the number number of diffs (perhaps a way
to do multiple smaller pataches), then that would be cool. I don't see an
obvious way to do this at this point.
--
Added file: http://bugs.python.org/file20298/struct-string.py3k.3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Meador Inge mead...@gmail.com added the comment: How is the compiler supposed to know whether a and b belong to the same array when compiling ptr_compare? I agree with Mark, it doesn't need to know. However, many compilers [1,2] support whole program optimization and could in theory figure the address out using that technique. [1] GCC -flto - http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Optimize-Options.html#Optimize-Options [2] VC++ LTCG - http://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9969] tokenize: add support for tokenizing 'str' objects
New submission from Meador Inge mead...@gmail.com: Currently with 'py3k' only 'bytes' objects are accepted for tokenization: import io import tokenize tokenize.tokenize(io.StringIO(1+1).readline) Traceback (most recent call last): File stdin, line 1, in module File /Users/minge/Code/python/py3k/Lib/tokenize.py, line 360, in tokenize encoding, consumed = detect_encoding(readline) File /Users/minge/Code/python/py3k/Lib/tokenize.py, line 316, in detect_encoding if first.startswith(BOM_UTF8): TypeError: Can't convert 'bytes' object to str implicitly tokenize.tokenize(io.BytesIO(b1+1).readline) generator object _tokenize at 0x1007566e0 In a discussion on python-dev (http://www.mail-archive.com/python-...@python.org/msg52107.html) it was generally considered to be a good idea to add support for tokenizing 'str' objects as well. -- messages: 117516 nosy: meador.inge priority: normal severity: normal stage: needs patch status: open title: tokenize: add support for tokenizing 'str' objects type: feature request versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9969] tokenize: add support for tokenizing 'str' objects
Changes by Meador Inge mead...@gmail.com: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9788] atexit and execution order
Meador Inge mead...@gmail.com added the comment: I agree with Antoine's LIFO comment. Also, FWIW, the C standard library behaves in a LIFO manner as well (C99 spec - 7.20.4.3 clause 3): First, all functions registered by the atexit function are called, in the reverse order of their registration,253) except that a function is called after any previously registered functions that had already been called at the time it was registered. If, during the call to any such function, a call to the longjmp function is made that would terminate the call to the registered function, the behavior is undefined. -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9756] Crash with custom __getattribute__
Meador Inge mead...@gmail.com added the comment: To fix the segfault, I suppose that we use a more strict validation on the input type. Eg. Use PyUnicode_Check() instead of PyObject_IsInstance()? Where would the more strict validation take place? This problem is not unique to Unicode objects: motherbrain:py3k minge$ ./python.exe Python 3.2a2 (py3k:84541, Sep 5 2010, 15:11:19) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. class MyClass(object): ...def __init__(self): ... self.pwn = None ...def __getattribute__(self, name): ... return getattr(187, name) ... [49633 refs] instance = MyClass() [49640 refs] int.bit_length(instance) Assertion failed: (PyLong_Check(v)), function long_bit_length, file Objects/longobject.c, line 4397. Abort trap -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5109] array.array constructor very slow when passed an array object.
Meador Inge mead...@gmail.com added the comment:
Overall, this patch look reasonable. I tested on py3k and the the tests pass.
I also did a few micro-benchmarks to verify the speedup.
One question I do have, though, is whether the 'len' calculation modifications
are necessary? This looks like an attempt to optimize more by taking advantage
of a particular type's 'len' implementation, but in practice I am not sure it
pays off. In addition, it complicates the patch slightly. I did the
micro-benchmarks with the old 'len' calculation and the results where
more-or-less the same as with the new 'len' calculation. However, perhaps
there are other cases where it would pay off that this simple micro-benchmark
will not show.
# Micro-benchmarks
# python --with-pydebug
# OS X 10.6
# 2.26 GHz Core 2 Duo
# without patch
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 10)))
10 loops, best of 3: 17.7 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 100)))
1 loops, best of 3: 106 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 1000)))
1000 loops, best of 3: 1.57 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 1)))
100 loops, best of 3: 17.4 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 10)))
10 loops, best of 3: 178 msec per loop
# with patch
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 10)))
10 loops, best of 3: 11.9 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 100)))
1 loops, best of 3: 56.1 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 1000)))
1000 loops, best of 3: 785 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 1)))
100 loops, best of 3: 8.69 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 10)))
10 loops, best of 3: 88.7 msec per loop
# with patch, but 'len' mods removed
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 10)))
10 loops, best of 3: 11.2 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 100)))
1 loops, best of 3: 54.6 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 1000)))
1000 loops, best of 3: 782 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 1)))
100 loops, best of 3: 8.66 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array'
array.array('i', array.array('i', range(0, 10)))
10 loops, best of 3: 88.3 msec per loop
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5109
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9633] pdb go stack up/down
Meador Inge mead...@gmail.com added the comment: I believe this is slightly tricky because 'bdb.format_stack_entry' makes references to '.f_locals' and 'bdb.format_stack_entry' is invoked in several places in 'pdb'. One option would be to add a extra parameter to 'bdb.format_stack_entry' to accept a dictionary of locals to operate with. I implemented this approach and added a doctest to verify. See attached patch. I didn't update the 'bdb' documentation to note the new parameter, but will if this approach seems reasonable. -- keywords: +patch Added file: http://bugs.python.org/file18706/issue9633.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9633 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9633] pdb go stack up/down
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9633 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Meador Inge mead...@gmail.com added the comment: Overall the patch looks good. I don't think it is an extremely important feature, but similar support is already available in other places (e.g. 'struct', 'ctypes'). Here is a patch updated for py3k with some minor additions: (1) Fixed some doc inconsistencies. (2) Added pickling support for the new type codes. The special pickling support looks only to be in py3k. (2) needs unit tests if possible. If anyone has any good ideas on how to test, then I would be happy to implement the tests. -- stage: unit test needed - patch review Added file: http://bugs.python.org/file18627/issue-1172711.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1172711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Changes by Meador Inge mead...@gmail.com: -- assignee: teoliphant - meador.inge priority: critical - high stage: unit test needed - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4188] Lib/threading.py causes infinite recursion when running as verbose
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5248] Adding T_SIZET to structmember.h
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1172711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5077] 2to3 fixer for the removal of operator functions
Meador Inge mead...@gmail.com added the comment: Sure. I take it you meant http://svn.python.org/projects/sandbox/trunk/2to3, though. Is this the location that all patches for 2to3 should be produced against? I dropped the documentation changes b/c I did not see any docs in the 2to3 trunk. Should the doc updates be applied somewhere else? -- Added file: http://bugs.python.org/file18316/issue-5077-2to3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9249] struct.pack and Long Integer datatype should be 4, but is 8 bytes
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9011] ast_for_factor unary minus optimization changes AST
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9011 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: [Mark] Can you think of any reason that we shouldn't just copy the py3k implementation ... Not that I can think of. Like you pointed out, we should have removed the coercion from the rich comparison when fixing issue 5211. Thanks for all your help with this! No problem! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: I'm not sure that's a good idea: mightn't this change behaviour for user-defined classes with a __coerce__ method? Maybe it would be better to just special-case ints and longs at the start of complex_richcompare, and then leave everything else more-or-less intact? I looked into this more and agree. I have attached a patch with the strategy that leaves the coercion intact. Although, even with removing the coercion from the complex rich compare a user-defined __coerce__ is still called somewhere up in object.c. It does not have the same behavior, though, e.g. __coerce__ is called, but the coerced args don't actually seem to be used in the comparison as they are in the explicit coerce in the complex object rich compare. Somewhat of topic, but the comparison rules in 2.7 seems to be pretty inconsistent anyway (due to different behavior between new and old style classes): motherbrain:trunk minge$ ./python.exe Python 2.7b2+ (trunk:81489M, May 29 2010, 09:44:06) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. from itertools import product [35627 refs] class T: ...def __init__(self, x): ... self.x = x ...def __coerce__(self, other): ... return (self.x, other) ... [35676 refs] class U(T, object): ...def __init__(self, x): ... super(U, self).__init__(x) ... [35723 refs] for tobj, value in product((T, U), (12, 12.0, complex(12.0))): ...print tobj, - , tobj(value) == value ... __main__.T - True __main__.T - True __main__.T - True class '__main__.U' - True class '__main__.U' - False class '__main__.U' - True [35740 refs] Given the complexities and subtleties of how comparison works in 2.7 I am a little hesitant to commit this change as well. -- Added file: http://bugs.python.org/file17493/issue-8748.py27.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Changes by Meador Inge mead...@gmail.com: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Changes by Meador Inge mead...@gmail.com: -- stage: - needs patch type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: Hmm. The current Python 2.7 behaviour really is a mess. No doubt! Your patch removes the coercion entirely; Yeah, I know. The funny thing about this is that according to the documentation [1]: Arguments to rich comparison methods are never coerced. I'm not sure that's a good idea: mightn't this change behaviour for user-defined classes with a __coerce__ method? Maybe it would be better to just special-case ints and longs at the start of complex_richcompare, and then leave everything else more-or-less intact? I will look into that today. I'm beginning to wonder whether it's actually worth fixing this at all in 2.7. :) [1] http://docs.python.org/dev/reference/datamodel.html#basic-customization -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment:
is that correct, or should the production list be something like:
Yup, you are right. I will change the grammar.
Whether these cases are valid or not (personally, I think they should
be), we should add some tests for them. '' *is* currently valid, I
believe.
I agree, they should be valid. I will add more test cases.
The possibility of mixing native size/alignment with standard
size/alignment in a single format string makes me a bit uneasy
I agree. It is hard for me to see how this might be used. In any case,
the relevant part of the PEP that I was following is:
Endian-specification ('!', '@','=','','', '^') is also allowed inside the
string so that it can change if needed. The previously-specified endian string
is in force until changed. The default endian is '@' which means native
data-types and alignment. If un-aligned, native data-types are requested, then
the endian specification is '^'.
However, I am not quite sure how to interpret the last sentence.
Should the switch to '' within the embedded struct be regarded as
local to the struct?
No, there is no notion of scope here. A given specifier is active until the
next one is found.
Ah, it should have been:
assert(soself-s_tree != NULL);
D'oh! I missed that when I merge over to py3k -- I started this work on trunk.
Thanks.
--
Added file: http://bugs.python.org/file17416/struct-string.py3k.2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: Thanks for the review. I incorporated the check re-orderings. I am also writing more tests. Which already exposed a subtly that I was not expecting: Python 3.2a0 (py3k:81284M, May 20 2010, 09:08:20) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. n = 2 ** 53 [37447 refs] complex(n + 2) == n + 2 True [37457 refs] complex(n + 1) == n + 1 False [37459 refs] complex(n + 3) == n + 3 False [37460 refs] complex(n + 4) == n + 4 True [37461 refs] It seems as if 'complex(n + delta) == n + delta' when 'delta' is even. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment:
As a separate issue, I notice that the new 'T{}' code doesn't respect
multiplicities, e.g., as in 'H3T{HHL}'. Is that
intentional/desirable?
That could have been an oversight on my part. I don't see any immediate reason
why we wouldn't allow it.
But now I've got a new open issue: how much padding should be
inserted/expected (for pack/unpack respectively) between the 'B' and
the 'T{...}' in a struct format string of the form 'BT{...}'?
Doesn't that depend on what is in the '...'? For example, I would expect the
same padding for 'BT{I}' and 'BI'. In general, I would expect the padding to
be the same for 'x+T{y+}' and 'x+y+'. The 'T{...}'s are merely organizational,
right?
I'm tempted to suggest that for native mode, changing the specifier be
disallowed entirely.
I am tempted to suggest that we just go back to having one specifier at the
beginning of the string :). Things seem to be getting complicate without any
clear benefits.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: Thanks for the updated patch; I'll take a closer look tonight, and apply it if all looks good. I incorporated the changes locally and have not updated the patch yet. I will update it later today. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment:
Granted, yes. But I wouldn't expect the same padding for 'BT{BI}' and
'BBI'. 'BT{BI}' should match a C struct which itself has an embedded
struct. For C, I get the following results on my machine:
I wasn't sure. The C99 standard does not specify what the behavior should be.
It is implementation defined. I guess most implementations just set the
alignment of the struct with the alignment of its most demanding member.
I need to change how the alignment for nested structures is computed. Right
now alignments are being computed as if the 'T{...}' codes were not there. I
will hold off until we decide what that rule should be, but I think the most
demanding element rule seems reasonable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: No problem! I have attached the updated patch. I am starting on the 2.7 patch now. -- Added file: http://bugs.python.org/file17424/issue-8748.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment: 2.7 patch attached. The implementation is mostly the same as the 3.2 one, but there is one quirk. Namely, 2.7 (and other 2.x's) has the following odd behavior: 1j None False 1j 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: no ordering relation is defined for complex numbers To perserve this behavior I had to do the type checks for 'int', 'long', 'complex', and 'float' at the beginning. I tried 'PyNumber_Check' first, but it returns 1 for old-style classes since the number protocol is filled in for the 'instance' type. -- Added file: http://bugs.python.org/file17425/issue-8748.py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8748] integer-to-complex comparisons give incorrect results
Meador Inge mead...@gmail.com added the comment:
For a complex number z and an integer i, 'z == i' should be exactly
equivalent to 'z.real == i and z.imag == 0.0'.
Like you mentioned before a lot of care is taken in 'floatobject.c' to ensure
that the comparison is robust. Would it be a good approach to leverage that
work?
I have attached a patch with that idea. If it seems reasonable, then I can
clean it up and add more tests. I created the patch for py3k. I think the 2.x
changes will be slightly different due to the coercion aspects.
One of the unit tests ('test_complex.test_richcompare') explicitly checks for
the overflow. However, the approach of just having the comparison return
'False' in these cases is more robust. Is there any use case for explicitly
notifying of overflow with comparisons? It seems like more of an
implementation artifact to me...
--
keywords: +patch
nosy: +minge
Added file: http://bugs.python.org/file17402/issue-8748.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8748
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7902] relative import broken
Meador Inge mead...@gmail.com added the comment: Does this patch seem reasonable? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment: Sure - http://codereview.appspot.com/1258041 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Meador Inge mead...@gmail.com added the comment:
Attached is a patch that implements part of the additions. More specifically,
the 'T{}' syntax and the ability to place byte-order specifiers ('', '', '@',
'^', '!, '=') anywhere in the struct string.
The changes dictated by the PEP are so big that it is better to split things up
into multiple patches. These two features will lay some ground work and are
probably less controversial than the others.
Surely some more tweaks will be needed, but I think what I have now is at least
good enough for review. I tested on OS X 10.6 and Ubuntu 10.4. I also used
valgrind and 'regrtest.py -R:' to check for memory and
reference leaks, respectively.
--
Added file: http://bugs.python.org/file17386/struct-string.py3k.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7355] Struct incorrectly compiles format strings
Meador Inge mead...@gmail.com added the comment: wonder whether they should be converted to little-endian I thought about that as well. It sure would make creating new examples easier :) I had to construct the new examples by hand. I can regenerate the examples for little-endian if you would like? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7355] Struct incorrectly compiles format strings
Meador Inge mead...@gmail.com added the comment: Sure, if you want to. [Then I won't be able to reproduce what's in the docs on either of my machines. :) One's 32-bit big-endian; the other's 64-bit little-endian.] I guess it's painful either way. I think the only fair thing to do is provide examples for multiple scenarios, e.g. 32-bit little-endian, 64-bit big-endian, etc... Share the pain :) Cool, thanks! Your padding note tweak is a definite improvement over what I originally had. -- Added file: http://bugs.python.org/file16903/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7355 ___brdiv class=gmail_quoteblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;Sure, if you want to. Â [Then I won#39;t be able to reproduce what#39;s in the docs on either of my machines. :) Â One#39;s 32-bit big-endian; Â the other#39;s 64-bit little-endian.]br /blockquotedivbr/divdivI guess it#39;s painful either way. Â I think the only fair thing to do is provide examples for multiple scenarios, e.g. 32-bit little-endian, 64-bit big-endian, etc... Â Share the pain :)/div divbr/divblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex; Merged your changes and subsequent tweaks to py3k in r80016.br divdiv/divdiv class=h5br/div/div/blockquotedivbr/divdivCool, thanks! Â Your padding note tweak is a definite improvement over what I originally had./div/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7355] Struct incorrectly compiles format strings
Meador Inge mead...@gmail.com added the comment: Those last two sentences where meant to be in response to your Merged your changes and subsequent tweaks to py3k in r80016. comment. I tried to reply to the tracker from my mail client and things got reformatted :( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7433] MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7355] Struct incorrectly compiles format strings
Changes by Meador Inge mead...@gmail.com: -- nosy: +minge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7355] Struct incorrectly compiles format strings
Meador Inge mead...@gmail.com added the comment: I'm half-convinced that struct.pack *should* ideally add trailing padding in the same situation that C does, for consistency with C. Then calcsize would match C's sizeof. Maybe... AFAIK, the C language does not mandate structure padding. Section 6.7.2.1 of the C99 standard says that unnamed padding may be inserted anywhere inside of a structure object *except* at the beginning. In other words, padding between members and trailing padding is very implementation specific. When and why things are padded usually depends on the compiler, OS, and computer architecture. For example, padding between members is usually just an optimization for architectures like x86, but on architectures like ARM and MIPS you may end up with alignment faults. Moreover, I think trailing padding is typically added to maintain alignment for arrays of structures, which again may be an optimization or correctness issue depending on the architecture. So, I don't think we can match what C does since C leaves it open. Perhaps we could match the C implementation that compiles the 'struct' module, though? Maybe there is a way we can compute the trailing padding in a fashion similar to how alignment is computed for various types in the '*_ALIGN' macros in '_struct.c'? Another thing that came to mind when thinking about structure layout issues was whether it might be useful to provide packed structures, e.g. no padding. If the goal is to provide a way to read\write C-compatible structs, then currently there is no easy way to handle structures that have been serialized after being compiled with something like GCC's '-fpack-struct' option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7355] Struct incorrectly compiles format strings
Meador Inge mead...@gmail.com added the comment: would be to add enough padding so that the alignment of the struct matches the largest alignment of any member of the struct. That might work. I will have to think about it a bit. On the subject of documentation Attached a doc patch which addresses Mark's two points plus the following: (1) Organized things more clearly into sub-sections. (2) Fixed up the notes column from the '__index__' change that was submitted last week. (3) Added some examples. -- keywords: +patch Added file: http://bugs.python.org/file16864/issue-7355.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8300] Allow struct.pack to handle objects with an __index__ method.
Meador Inge mead...@gmail.com added the comment: Looks good to me. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8300] Allow struct.pack to handle objects with an __index__ method.
Meador Inge mead...@gmail.com added the comment: I may be missing something subtle, but how can 'PyNumber_Index(v) != NULL' *and* '!PyInt_Check(v) !PyLong_Check(v)' both be satisfied in the 'get_pylong' mods? It seems to me that 'PyNumber_Index' only returns non-NULL when the object being returned is an 'int' or 'long'. Attached a patch with the extra check removed and a few more test cases. -- Added file: http://bugs.python.org/file16751/struct_index_trunk3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7994] object.__format__ should reject format strings
Meador Inge mead...@gmail.com added the comment: Hi Eric, (-2) and (-3) are different. The changes that I made, however, are pretty minor. Also, they are all in 'test_builtin.py'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7994 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1530559] struct.pack raises TypeError where it used to convert
Meador Inge mead...@gmail.com added the comment: (2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer on top of the C layer. Partly I'm worried about accidentally breaking something (it's not 100% clear to me whether there might be hidden side-effects to such a change), I understand. I am worried about that as well. The main area that concerns me is the interface for the 'Struct' class. I did my best to match the methods and functions from the C implementation. I need to look into this in more detail, though. One quirk I currently know about is that the following methods: '__delattr__', '__getattribute__', '__setattr__', '__new__' show up in 'help' for the C implementation, but not the Python one. Although, the implementations do exist in both places. but I also notice that this seems to have a significant impact on performance. In fact, I seem to recall that the previously existing Python component of the struct module was absorbed into Modules/_struct.c precisely for performance reasons. A quick, unscientific benchmark: the time taken to run test_struct with this patch (excluding the changes to test_struct itself) on my machine (OS X 10.6, 64-bit non-framework non-debug build of Python) is around 1.52--1.53 seconds; without the patch it's around 1.02--1.03 seconds. Agreed that this is not a really scientific benchmark. I did experiment with this idea a little further though on my machine (OS X 10.5 32-bit): == | Configuration| Seconds | == | Original | 1.26| -- | __index__ patch v1 | 1.88| -- | Hoisted imports out of functions | 1.53| -- | Hoisted imports and no __index__ | 1.34| -- So with this simple experiment pulling the 'imports' out of the function wrappers made quite a difference. And, of course, removing the '__index__' transform brought the times down even more. So, the wrapper overhead does not look to be terrible for this simple test. However, as you alluded to, we should find a better benchmark. Any ideas on a good one? (4) For 2.x, perhaps we don't need the extra __index__ functionality anyway, now that the previous use of __int__ has been restored. That would give us a bit more time to think about this for 3.x. Agreed. Thanks for taking the time to look at the patch anyway! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1530559 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1530559] struct.pack raises TypeError where it used to convert
Meador Inge mead...@gmail.com added the comment: If anyone's interested in submitting a patch, it would be welcome. Sure. I saw where this was partly addressed in r78690. The attached patch adds support for the '__index__' conversion that Mark suggested. At first glance, the patch may seem more than what is needed. However, most of the diffs are due to pulling parts of the C implementation into a Python veneer. This will make preprocessing work (like what was needs for this fix) easier now and in the future. In addition, it will lay a small amount of groundwork for the changes that are needed for resolving issue 3132. As that work will be simplified by having the veneer as well. -- nosy: +minge Added file: http://bugs.python.org/file16476/issue-1530559.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1530559 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8039] precedence rules for ternary operator
Meador Inge mead...@gmail.com added the comment: It seems to me from the grammar (http://docs.python.org/reference/expressions.html#grammar-token-conditional_expression) that the precedence for conditional expressions fall in between that of 'lambda' and 'or' expressions. -- keywords: +patch nosy: +minge versions: +Python 2.7 Added file: http://bugs.python.org/file16477/issue-8039.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7232] Support of 'with' statement fo TarFile class
Meador Inge mead...@gmail.com added the comment: This is common practice in the standard library. This doesn't necessarily mean it is a correct practice :-). All kidding aside, I think the assumption that the standard documentation on '__enter__' and '__exit__' is sufficient is a bad one. With respect to how the 'tarfile' versions of these methods behave, that documentation is not that helpful. In particular, the special behavior of an 'IOError' potentially being thrown from '__enter__' and the fact that '__exit__' does not swallow the exception. These special behaviors should be documented either in a docstring or the library documentation. I think this is important, but I may be being a bit pedantic. Also, the last change to 'test_context_manager_exception' has a bug. If the call to 'tarfile.open' throws an exception, then the call to 'self.assertRaises' will swallow it. This will cause an undefined variable reference to 'tar' in 'self.assertTrue(tar.closed, ...)'. I attached another update that fixes this problem. -- Added file: http://bugs.python.org/file16398/issue7232.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7232] Support of 'with' statement fo TarFile class
Meador Inge mead...@gmail.com added the comment: What about changing the exception test to something like what I did in issue7232.4.diff? That is definitely more succinct, but Lars' solution provides more information about _why_ the test fails. IMHO, the descriptiveness is more important than succinctness. Especially when debugging a failed test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7994] object.__format__ should reject format strings
Meador Inge mead...@gmail.com added the comment: The patch looks reasonable. I built on it with the following changes: 1. Added some extra test cases to cover Unicode format strings, since the code was changed to handle these as well. 2. Changed test_builtin.py by s/m[0].message.message/str(w[0].message)/, since BaseException.message was deprecated in 2.6. I also have the following general comments: 1. PEP 3101 explicitly defines the string conversion for object.__format__. What is the rationale behind this? Should we find out before making this change? 2. I don't think the comments in 'abstract.c' and 'typeobject.c' explaining that the warning will eventually become an error are needed. I think it would be better to open separate issues for these migration steps as they can be tracked easier and will be more visible. 3. test_unicode, test_str have cases that trigger the added warning. Should they be altered now or when (if) this becomes an error? -- nosy: +minge Added file: http://bugs.python.org/file16376/issue7994-3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7994 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7232] Support of 'with' statement fo TarFile class
Meador Inge mead...@gmail.com added the comment: Built on Brian's patch by adding the following items: * Added a unit test case to cover exceptional conditions. * Added doc strings on __enter__ and __exit__ (more consistent with the surrounding code). * Spelling error in doc update: s/manaager/manager/. * Link doc update to context manager type documentation (just in case the tarfile user is unfamiliar with context manager types). -- nosy: +minge Added file: http://bugs.python.org/file16367/issue7232.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
