[issue13062] Introspection generator and function closure state
Meador Inge added the comment: Nick, the revised definition of 'getclosurevars' seems reasonable to me. I will cut a new patch this week. -- ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13250] ctypes: reference leak in POINTER code
Meador Inge added the comment: Ah, I see now. Thanks Benjamin. > So it's not a bug at all, right? A bug in regrtest.py maybe. 'dash_R_cleanup' clears various other caches in between test runs to avoid false positives like this. Perhaps 'ctypes._pointer_type_cache' should be cleared there as well. -- ___ Python tracker <http://bugs.python.org/issue13250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13250] ctypes: reference leak in POINTER code
New submission from Meador Inge : While implementing a patch for issue13096 I found a reference leak in 'ctypes'. I couldn't find the cause immediately, but it can be reproduced by applying the attached patch and running: [meadori@motherbrain cpython]$ ./python -m test -R : test_ctypes [1/1] test_ctypes beginning 9 repetitions 123456789 . test_ctypes leaked [51, 51, 51, 51] references, sum=204 1 test failed: test_ctypes [174347 refs] -- components: ctypes files: ctypes-refleak-repro.patch keywords: patch messages: 146242 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: needs patch status: open title: ctypes: reference leak in POINTER code type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23504/ctypes-refleak-repro.patch ___ Python tracker <http://bugs.python.org/issue13250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Meador Inge added the comment: > Most definitely not. It is very deliberate that asdl_c.py is only > invoked when the ASDL sources change. Otherwise, having Python installed > would be a build requirement for Python, which it must be not. OK, thanks for the background. To be clear, though, the build dependency is already there. You just have to touch the ASDL sources to run into it (Lib/opcode.py as well). This is even documented in the Makefile*: # XXX Note that a build now requires Python exist before the build starts ASDLGEN= $(srcdir)/Parser/asdl_c.py However, modifying the ASDL source is, with respect to other source modifications, not as common. So, I see no reason to make the situation worse by running asd_c.py all the time. Suggestion withdrawn. * If not relying on an external Python is a hard requirement (and I do see why that may be useful), then the build system could be changed to only allow changes to problematic sources (ASDL, opcode.py) after Python has been built once. Then the built Python could be used. -- ___ Python tracker <http://bugs.python.org/issue13243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
Meador Inge added the comment: > Actually, I think sysconfig does the right thing when it comes to all > the configure-generated HAVE_XXX variables I agree. The 'configure' script could be improved, though. If we truly want to enable this by default, then the defaulting should be moved to configure. This will give a more accurate portrayal in sysconfig. Also, we can do the USE but !HAVE check in configure, which is better anyway because the error is caught earlier. I am thinking something like the attached. Thoughts? P.S. We could probably get rid of the HAVE macro all together by doing all the work in the 'configure' script. -- keywords: +patch nosy: +meador.inge Added file: http://bugs.python.org/file23503/issue13240.patch ___ Python tracker <http://bugs.python.org/issue13240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12675] tokenize module happily tokenizes code with syntax errors
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue12675> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Meador Inge added the comment: Committed. Thanks! -- nosy: -python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Meador Inge added the comment: Oh, and just to be clear I reproduced the build break by doing: ./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl make in a built tree. The reason that this wasn't caught is that the make rules have the ASDL files as dependencies on the AST C files. So, the C files are *not* updated unless the ASDL files are. Maybe we should change the build system to always regenerate the files or add something to automation that regenerates the AST C file every time. -- ___ Python tracker <http://bugs.python.org/issue13243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Meador Inge added the comment: Good catch. I see what happened. 7109f31300fb updated Python/Python-ast.c but not Parser/asdl_c.py. I will apply your patch shortly. Thanks. -- assignee: -> meador.inge nosy: +meador.inge stage: -> patch review ___ Python tracker <http://bugs.python.org/issue13243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13217] Missing header dependencies in Makefile
Changes by Meador Inge : -- nosy: +meador.inge stage: -> patch review ___ Python tracker <http://bugs.python.org/issue13217> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13183] pdb skips frames after hitting a breakpoint and running step
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13183> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13199] slice_richcompare() might leak an object in rare cases
Changes by Meador Inge : -- nosy: +meador.inge stage: -> test needed type: -> resource usage versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13187] relative imports don't work when circular
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13187> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Meador Inge added the comment: > perhaps 'getclosurevars' would do as the name? I like vars. Updated patch attached. -- Added file: http://bugs.python.org/file23368/issue13062-3.patch ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Meador Inge added the comment: Here is an updated patch with error handling. One other thought is that 'getclosure' should be called something like 'getclosureenv' since technically a closure is a function plus its environment and our implementation only returns the environment. But that may be converging on pedantic. -- Added file: http://bugs.python.org/file23356/issue13062-2.patch ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13097] ctypes: segfault with large number of callback arguments
Meador Inge added the comment: As mentioned in issue12881, this issue is a result of an unbounded 'alloca' call that trashes the stack. -- ___ Python tracker <http://bugs.python.org/issue13097> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13096] ctypes: segfault with large POINTER type names
Meador Inge added the comment: Yup, it is the 'alloca' call. This issue and issue13097 are both 'alloca' related as mentioned in issue12881. -- ___ Python tracker <http://bugs.python.org/issue13096> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue10399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Meador Inge added the comment:
On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
>> compiler settings.
>
> They are set by the configure script:
>
> gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
> Objects/unicodeobject.o Objects/unicodeobject.c
>
>> Such optimizations are normally performed by the
>> compiler and don't need to be implemented in C, making maintenance
>> harder.
>
> The fact that the glibc includes such optimization (in much more
> sophisticated form) suggests to me that many compilers don't perform
> these optimizations automically.
I agree. This is more of an optimized runtime library problem than
code optimization problem.
>> I tested using memchr() when writing those "naive" loops.
>
> memchr() is mentioned in another issue, #13134.
Yeah, this conversation is really more relevant to issue13134, but I will
reply to these here anyway
>> memchr()
>> is inlined by the compiler just like the direct loop
>
> I don't think so. If you look at the glibc's memchr() implementation,
> it's a sophisticated routine, not a trivial loop. Perhaps you're
> thinking about memcpy().
Without link-time optimization enabled, I doubt the toolchain can
"inline" 'memchr'
in the traditional sense (i.e. inserting the body of the routine
inline). Even if it could,
the inline heuristics would most likely choose not to. I don't think we use LTO
with GCC, but I think we might with VC++.
GCC does something else called builtin folding that is more likely.
For example,
'memchr ("bca", 'c', 3)' gets replace with instructions to compute a pointer
index into "bca". This won't happen in this case because all of the 'memchr'
arguments are all variable.
>> and the generated
>> code for the direct version is often easier to optimize for the compiler
>> than the memchr() one, since it receives more knowledge about the used
>> data types.
>
> ?? Data types are fixed in the memchr() definition, there's no knowledge
> to be gained by inlining.
I think what Marc-Andre is alluding to is that the first parameter of
'memchr' is 'void *'
which could (in theory) limit optimization opportunities. Where as if
it knew that
the data being searched is a 'char *' or something it could take
advantage of that.
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13136>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Meador Inge added the comment: I can't reproduce this problem in either 2.7.2 or 3.3.0a0. > For example if executed with pypy. Do you mean that this problem is only reproducible when the attached script is run with pypy? -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13133> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Changes by Meador Inge : -- assignee: docs@python -> meador.inge resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: Éric, thanks. I fixed most of your points. And thanks to everyone that reviewed this. Much appreciated. -- ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Meador Inge added the comment: No problem. This last version LGTM. -- ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Meador Inge added the comment: Found a few test case nits. Comments in rietveld. -- ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ 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
Meador Inge added the comment: > Look in 'cfield.c' where all of the native alignments Well, not *all* the native alignments, but many of them. -- ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ 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
Meador Inge added the comment: On Tue, Oct 4, 2011 at 10:21 AM, Vlad Riscutia wrote: > First, I'm saying "toying with the underlying buffer" because none of the > bugs are actual issues of the form "I created this bitfield > structure with Python, passed it to C function but C structure was > different". That would be a bitfield bug. All of these bugs are people > setting raw memory to some bytes, then looking at bitfield members and not > seeing what they expect. Please qualify "all" instead of generalizing. I can point to two issues (issue11990 "I'm generating python code from real c code.", issue12945 "We have raw data packages from some tools. These packages contains bitfields, arrays, simple data and so on.") where C code or raw data was, in fact, involved and the reporters just don't understand what layout algorithm is being used. They may not need to know the specifics of the algorithm, but they *do* need to know if it matches the compiler they are using to do interop or the one that generated the raw data. The reason that we are seeing folks cast raw memory into a cyptes bitfield structure is because they do not understand how the structure layout algorithm works and are trying to figure it out via these examples. > Second, one of your review comments is: "GCC is used for most Unix systems > and Microsoft VC++ is used on Windows.". This is not > how ctypes works. Ctypes implements the bitfield allocation algorithm itself, > it doesn't use the compiler with which it is built. Basically > it says #ifdef WIN32 - allocate like VC++ - #else - allocate like GCC. So it > doesn't really matter with which compiler you are building > Python. It will still do GCC style allocation on Solaris. I understand how it works. This quote is taken somewhat out of context as the preceding sentence is important. Perhaps saying GCC- style and VC++-style would have been more clear. The reason that I mentioned the compiler used to build Python is that it is an easy reference point and more times than not the bitfield allocation and layout *do* match that of the compiler used to build the interpreter. Anyway, I am fine with dropping the "used to build the Python interpreter" and going with something similar to what you originally had. Also, in general, the compiler used to build the ctypes extension *does* matter. Look in 'cfield.c' where all of the native alignments are computed at compile time. These alignments affect the structure layout and are defined by the compiler building the ctypes extension. -- ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Meador Inge added the comment: Mostly LGTM. I have a few comments in rietveld. -- nosy: +meador.inge stage: needs patch -> patch review ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ 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
Meador Inge added the comment: Added some comments in rietveld. P.S. watch out for trailing whitespace when writing patches. Use 'make patchcheck' to help find bad whitespace formatting. -- ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ 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
Meador Inge added the comment: On Fri, Sep 30, 2011 at 12:19 PM, Vlad Riscutia wrote: > I believe this is the better thing to do rather than detailing how GCC and > MSVC allocated their bitfields because that would just > encourage people to use this feature incorrectly. So clearly documenting how a feature works will cause people to use the feature incorrectly? I think not. In any case, I agree that documenting the low-level specifics of each compiler's algorithm is too much. > Most bugs opened on bit fields are because people are toying with the > underlying buffer and get other results than what they expect. The issues that I have looked at (issue6069, issue11920, and issue11920) all involve fundamental misunderstandings of *how* the structure layout is determined. I don't know if I would generalize these misunderstanding as "toying with the underlying buffer". Some times people need to know the exact layout for proper C interop. In some of the bugs reported folks are casting buffers in an attempt to discover the structure layout since it is not clearly documented. The general content of your patch seems reasonable. I will provide more specific comments shortly. -- ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ 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
Meador Inge added the comment: Fixed. Opened issue13096 and issue13097 for the other crashers. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13097] ctypes: segfault with large number of callback arguments
New submission from Meador Inge : Reproducible in 2.7 and tip: [meadori@motherbrain cpython]$ ./python Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04) [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 * >>> NARGS = 2 ** 20 >>> proto = CFUNCTYPE(None, *(c_int,) * NARGS) >>> def func(*args): ...return (1, "abc", None) ... >>> cb = proto(func) >>> cb(*(1,) * NARGS) Segmentation fault (core dumped) -- components: ctypes messages: 144852 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: needs patch status: open title: ctypes: segfault with large number of callback arguments type: crash versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13097> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13096] ctypes: segfault with large POINTER type names
Meador Inge added the comment:
There is similar crasher to this one that can be reproduced like:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04)
[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 *
>>> p = POINTER('x' * 2 ** 25)
Segmentation fault (core dumped)
It should be fixed as well.
--
___
Python tracker
<http://bugs.python.org/issue13096>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13096] ctypes: segfault with large POINTER type names
New submission from Meador Inge :
Reproducible in 2.7 and tip:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04)
[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 *
>>> T = type('x' * 2 ** 25, (Structure,), {})
>>> p = POINTER(T)
Segmentation fault (core dumped)
--
components: Extension Modules, ctypes
messages: 144850
nosy: amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: segfault with large POINTER type names
type: crash
versions: Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue13096>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: Fixed a few more nits pointed out in review. -- Added file: http://bugs.python.org/file23304/issue12943-6.patch ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Meador Inge added the comment: Here is a first cut at a patch. There is one slight deviation from the original spec: > some nice error checking for when the generator's frame is already gone > (or > the supplied object isn't a generator iterator). The attached patch returns empty mappings for these cases. I can easily add the error checks, but in what cases is it useful to know *exactly* why a mapping could not be created? Having an empty mapping for all invalid cases is simpler and seems more robust. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file23303/issue13062.patch ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Meador Inge added the comment:
> this pointer is tied to a CDataObject; its tp_alloc should free the
> memory
The free in 'PyCData_clear' is conditional:
if ((self->b_needsfree)
&& ((size_t)dict->size > sizeof(self->b_value)))
PyMem_Free(self->b_ptr);
As written, 'PyCData_clear' has no way of knowing that memory has been
{m,re}alloc'd in 'resize'. So in some cases memory will leak. Here is
a small reproduction case extracted from 'test_varsize_struct.py'.
from ctypes import *
class X(Structure):
_fields_ = [("item", c_int),
("array", c_int * 1)]
x = X()
x.item = 42
x.array[0] = 100
new_size = sizeof(X) + sizeof(c_int) * 5
resize(x, new_size)
One potential fix is:
diff --git a/Modules/_ctypes/_ctypes.c b/Modules/_ctypes/_ctypes.c
--- a/Modules/_ctypes/_ctypes.c
+++ b/Modules/_ctypes/_ctypes.c
@@ -2440,7 +2440,7 @@ PyCData_clear(CDataObject *self)
assert(dict); /* Cannot be NULL for CDataObject instances */
Py_CLEAR(self->b_objects);
if ((self->b_needsfree)
-&& ((size_t)dict->size > sizeof(self->b_value)))
+&& (self->b_ptr != (char *)&self->b_value))
PyMem_Free(self->b_ptr);
self->b_ptr = NULL;
Py_CLEAR(self->b_base);
I need to think about that more, though.
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue13091>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Meador Inge added the comment: I can reproduce this with: valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_ctypes Where as: valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_multiprocessing turns up nothing in 'ctypes.resize'. -- ___ Python tracker <http://bugs.python.org/issue13091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Changes by Meador Inge : -- components: +ctypes nosy: +amaury.forgeotdarc, belopolsky, meador.inge ___ Python tracker <http://bugs.python.org/issue13091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13089] parsetok.c: memory leak
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13089> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Meador Inge added the comment:
I'll take a shot and writing a patch for this one. Nick, are the
elements in 'co_freevars' and '__closures__' always expected to match
up? In other words, is the 'closure' function below always expected to
work (simplified; no error checking):
>>> def make_adder(x):
... def add(y):
... return x + y
... return add
...
>>> def curry(func, arg1):
... return lambda arg2: func(arg1, arg2)
...
>>> def less_than(a, b):
... return a < b
...
>>> greater_than_five = curry(less_than, 5)
>>> def closure(func):
... vars = [var for var in func.__code__.co_freevars]
... values = [cell.cell_contents for cell in func.__closure__]
... return dict(zip(vars, values))
...
>>> inc = make_adder(1)
>>> print(closure(inc))
{'x': 1}
>>> print(closure(greater_than_five))
{'arg1': 5, 'func': }
?
--
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Changes by Meador Inge : -- components: +Library (Lib) stage: -> needs patch versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ 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
Changes by Meador Inge : -- assignee: -> meador.inge versions: +Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue12881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] _ctypes.c: refleak
Changes by Meador Inge : -- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] _ctypes.c: refleak
Meador Inge added the comment: > If the function is public I guess that some external module > might use it Agreed; That is the only case I could deduce as well, which I hinted at in msg144397. So, I will leave the error check and keep the function public for now. I will commit the ref leak fix today. -- ___ Python tracker <http://bugs.python.org/issue13013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13044] pdb throws AttributeError at end of debugging session
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13044> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] _ctypes.c: refleak
Meador Inge added the comment: OK, I will just fix the ref leak in 2.7, 3.2, and 3.3. This is a pretty low-risk fix (as I mentioned before, I can't see how the error condition is even executed). -- ___ Python tracker <http://bugs.python.org/issue13013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Meador Inge added the comment: > Doing two separate commits is probably better. Out of curiosity, what is typically the convention on that? The devguide seems to suggest one changeset per issue: """ Just please make sure that you generate a single, condensed patch rather than a series of several changesets. """ I think for this case two patches is better. In general, I am OK with the git-style series and hg-style patchbombs, but the devguide seems to say otherwise. Hmmm, that makes me wonder if we can patchbomb the tracker :-) -- ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: > I don't think the help option needs to be documented, it will document > itself. Normally I would document it anyway, but in this case there is only the one option. So, I dropped it. > An additional suggestion is to catch errors on tokenizing and exiting > with a non-zero exit status in these cases. I like that idea. Sample output: $ python -m tokenize foo.py foo.py: error: unknown encoding: meador $ python -m tokenize foo.py foo.py:7:2: error: unindent does not match any outer indentation level $ ./python -m tokenize bogus.py error: [Errno 2] No such file or directory: 'bogus.py' $ python -m tokenize foo.py $ echo '[1,' | ./python -m tokenize 1,0-1,1:OP '[' 1,1-1,2:NUMBER '1' 1,2-1,3:OP ',' 1,3-1,4:NL '\n' :2:0: error: EOF in multi-line statement Attached is the latest patch implementing these suggestions. -- Added file: http://bugs.python.org/file23228/issue12943-5.patch ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Meador Inge added the comment: I agree that 'bytecode_instructions' is a long-winded. FWIW, I have worked on or with a fair amount instruction level things and "instruction" or "instr" seem to be the established domain terminology. Here are a few examples: * Java ASM - http://asm.ow2.org/asm33/javadoc/user/index.html - Classes named 'InsnList', 'InsnNode' * PyPy - https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/assemble.py - class named 'Instruction' * Python - http://hg.python.org/cpython/file/a06ef7ab7321/Python/compile.c#l45 - struct named 'instr' * binutils - http://sourceware.org/git/?p=binutils.git;a=tree - structs, variables, etc ... with use of 'insn' and 'instruction' * gcc - http://gcc.gnu.org/git/?p=gcc.git;a=tree - structs, variables, etc ... with use of 'insn' and 'instruction' -- ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Meador Inge added the comment: I took a quick look over the final patch (I will do a more thorough review later). I like the general idea a lot. The first thing that popped out at me are the names 'OpInfo' and 'get_opinfo'. 'OpInfo' makes it sound like information concerning only the opcode, but these objects really represent bytecode instructions. I see a lot of code in the future like: for opinfo in dis.get_opinfo(thing): process(opinfo) which seems vague. The following seems clearer to me: for instr in dis.bytecode_instructions(thing): process(instr) And instead of 'OpInfo' perhaps 'ByteCodeInstruction'. Even the current 'dis' documentation uses the terminology "Byte Code Instruction". -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ 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
Meador Inge added the comment: I am going to open separate issues for the other crashers. > Also, PyUnicode_FromFormat could be used instead of sprintf. Amaury, how so? 'sprintf' and 'stgdict->format' work with 'char *'s where as 'PyUnicode_FromFormat' builds a unicode string object. Unless there are any objections, I am going to commit as is. -- ___ Python tracker <http://bugs.python.org/issue12881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13020] structseq.c: refleak
Meador Inge added the comment: In general I agree that a test case is needed, but in this particular case its looks to be non-trivial to come up with one. The only way the reference leak is triggered is when memory is exhausted during an attempt to new up a 'PyStructSequence' object. -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13020> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] _ctypes.c: refleak
Meador Inge added the comment:
This patch seems reasonable. Upon looking at the code in more
detail, however, I can't see how the error condition that leaks the
reference can ever by triggered. In particular, the following code
from the 'PyCArrayType_from_ctype' function:
if (!PyType_Check(itemtype)) {
PyErr_SetString(PyExc_TypeError,
"Expected a type object");
return NULL;
}
'PyCArrayType_from_ctype' is only called from 'CDataType_repeat'. The
'CDataType_repeat' function is only used to implement the 'sq_repeat'
slot in 'CDataType_as_sequence'. 'CDataType_as_sequence' is used in all
of the implemented ctypes (struct, array, union, simple, ...).
Unless 'PyCArrayType_from_ctype' is called through some other means
(it is public), then 'itemtype' should *always* be a type. Or am
I missing something obvious? So, we could add the decref or just remove
the type check code all together (and make 'PyCArrayType_from_ctype'
private).
--
nosy: +amaury.forgeotdarc, belopolsky
___
Python tracker
<http://bugs.python.org/issue13013>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] Resource is not released before returning from the functiion
Meador Inge added the comment: I'll take this one. Suman, thanks for finding this. It will help in the future if you don't open a ton of bugs with the *exact* same title. They are harder to filter and keep track of that way. -- assignee: -> meador.inge nosy: +meador.inge stage: -> test needed versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Meador Inge added the comment: Patch looks good. I noticed a change in the conventional type for 'keepends' from 'int' to 'bool'. Several unit tests were updated to match this change. Perhaps other call sites should be updated too? A little greping shows: $ grep -Rl 'splitlines(0)' * --include='*.py' Doc/tools/docutils/writers/newlatex2e/__init__.py $ grep -Rl 'splitlines(1)' * --include='*.py' Doc/tools/sphinx/pycode/pgen2/tokenize.py Doc/tools/docutils/readers/python/moduleparser.py Lib/test/test_tokenize.py Lib/difflib.py Lib/lib2to3/pgen2/tokenize.py Lib/codecs.py -- ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ 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 : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13008] syntax error when pasting valid snippet into console without empty string after the function def
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13008> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Changes by Meador Inge : -- stage: -> patch review ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Meador Inge added the comment: +1; the keyword arg version is much more readable. -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: Updated patch which adds and documents a '-h,--help' option. This option was suggested during code review. -- Added file: http://bugs.python.org/file23196/issue12943-4.patch ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: Updated patch fixing some issues pointed out by Ezio on Rietveld. -- Added file: http://bugs.python.org/file23193/issue12943-3.patch ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Changes by Meador Inge : -- nosy: +meador.inge stage: test needed -> patch review ___ Python tracker <http://bugs.python.org/issue1294232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: > Did you get commit rights already? I have not. I still need to submit a contributor agreement as well. I plan to fax that today. -- ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: v2 patch which addresses comments made by merwok via rietveld. -- Added file: http://bugs.python.org/file23184/issue12943-2.patch ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13002] peephole.c: unused parameter
Meador Inge added the comment: Looks like it was checked in that way (http://hg.python.org/cpython/rev/14205d0fee45). Patch looks good to me. -- nosy: +meadori ___ Python tracker <http://bugs.python.org/issue13002> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12974] array module: deprecate '__int__' conversion support for array elements
Meador Inge added the comment:
> I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
> never allowed __int__(), but now index objects can be packed as pointers.
> It isn't a big deal, I just have to know for features/pep-3118.
>
> To illustrate, this is python2.5.0; INT is an object with an __int__() method:
>
> '\x07\x00\x00\x00\x00\x00\x00\x00'
>>>> struct.pack('P', INT(7))
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/stefan/hg/r25/Lib/struct.py", line 63, in pack
> return o.pack(*args)
> struct.error: cannot convert argument to long
Huh, that's interesting. It doesn't allow 'unsigned long' packs either (2.6.7):
Python 2.6.7+ (unknown, Sep 16 2011, 09:53:25)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> class IDX(object):
... def __init__(self, value):
... self.value = value
... def __int__(self):
... return self.value
...
>>> for code in ['l', 'L', 'P']:
...try:
... struct.pack(code, IDX(9))
...except Exception as e:
... print "pack('%s'): %s" % (code, e)
...
'\t\x00\x00\x00'
pack('L'): unsupported operand type(s) for &: 'IDX' and 'long'
pack('P'): cannot convert argument to long
The behavior around '__int__' in previous versions seems somewhat accidental.
--
___
Python tracker
<http://bugs.python.org/issue12974>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7201] double Endian problem and more on arm
Meador Inge added the comment: I think Mark's original pointer to issue1762561 was right on. The last two cases are failing due to the mixed-endian format (mentioned in that issue) used in OABI. You can see this in the output of 'test_endian_double': '182D4454FB210940' != 'FB210940182D4454' Note that the values are the same except the two 32-bit words are swapped. Similarly, in 'test_unaligned_native_struct_fields': '123412007856341200B81E09401F85EB51' != '1234120078563412001F85EB51B81E0940' The first 8 bytes in each case are the same. The last 8 bytes of each (which represent floating-point doubles) are the same except, again, the words are swapped. I am going to close this out as "won't fix". As mentioned in issue1762561, supporting OABI will involve taking on another host platform. EABI is surely more predominant these days anyway. -- resolution: -> wont fix stage: -> committed/rejected type: -> behavior ___ Python tracker <http://bugs.python.org/issue7201> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7201] double Endian problem and more on arm
Meador Inge added the comment:
The 'test_endian_double' test fails because the 'double' floating-point
type for an interpreter built for OABI is unknown:
>>> float.__getformat__("float")
'IEEE, little-endian'
>>> float.__getformat__("double")
'unknown'
According to [1], the double format discrepancies seem to be expected.
[1] http://wiki.debian.org/ArmEabiPort#ARM_floating_points
--
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7201] double Endian problem and more on arm
Meador Inge added the comment:
OK, I got an OABI system setup. I am seeing the 'test_struct_return_2H'
failure, which actually segfaults in my setup. The difference does,
indeed, seem like an ABI mismatch.
The test code that is failing has a Python side like:
def test_struct_return_2H(self):
class S2H(Structure):
_fields_ = [("x", c_short),
("y", c_short)]
dll.ret_2h_func.restype = S2H
dll.ret_2h_func.argtypes = [S2H]
inp = S2H(99, 88)
s2h = dll.ret_2h_func(inp)
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
and a C code side that looks like:
typedef struct {
short x;
short y;
} S2H;
S2H ret_2h_func(S2H inp)
{
inp.x *= 2;
inp.y *= 3;
return inp;
}
The APCS Section 5.4 Result Return [1], says:
"""
A Composite Type not larger than 4 bytes is returned in r0. The format
is as if the result had been stored in memory at a word-aligned address
and then loaded into r0 with an LDR instruction. Any bits in r0 that
lie outside the bounds of the result have unspecified values.
"""
The EABI implementation does exactly this and packs the structure into r0,
where as the OABI implementation places the address of a structure in r0.
'ctypes' is assuming the former and on an OABI system the contents of r0 are
treated as an address, where they are actually a value. Boom goes the dynamite.
I am looking into 'test_endian_double' and
'test_unaligned_native_struct_fields' now.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
--
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
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
Meador Inge added the comment:
> Note that there is at least one other place where alloca() is
> used with potentially large values:
Ouch! I found three more crashers (including the one you found)
by grepping for 'alloca' in ctypes:
>>> from ctypes import *
>>> T = type('x' * 2 ** 25, (Structure,), {})
>>> p = POINTER(T)
Segmentation fault (core dumped)
>>> from ctypes import *
>>> p = POINTER('x' * 2 ** 25)
Segmentation fault (core dumped)
>>> from ctypes import *
>>> NARGS = 2 ** 20
>>> proto = CFUNCTYPE(None, *(c_int,) * NARGS)
>>> def func(*args):
...return (1, "abc", None)
...
>>> cb = proto(func)
>>> cb(*(1,) * NARGS)
Segmentation fault (core dumped)
I will fix those too.
--
___
Python tracker
<http://bugs.python.org/issue12881>
___
___
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 added the comment: Updated patch with the 'Py_ssize_t' fixes. -- Added file: http://bugs.python.org/file23148/issue-1172711.patch ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ 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 added the comment:
> Okay, understood. But the new 'long long' support provided by this patch
> still allows for __int__-based duck typing, right?
Yes, but ...
> That's the new duck typing I meant. I see this acceptance of things with an
> __int__ method as a mistake, and my gut
> reaction earlier was that it seems wrong to propagate that mistake into the
> new long long functionality, even though it's already
> present in other places in the array module.
>
> On second thoughts though, it would be a peculiar inconsistency to be able to
> pass Decimal objects to array('L', ...) but not
> to array('Q', ...). So probably better to accept this behaviour for now, and
> open another issue for the __int__ / __index__ discussion,
> as you suggest.
... I had this inconsistency in mind. I opened issue12974 for the
__int__/__index__ problem.
Now we just have to figure out which issue gets fixed first :-D I am
OK with applying the fix for this issue first.
--
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12974] array module: deprecate '__int__' conversion support for array elements
New submission from Meador Inge :
When reviewing the fix for issue1172711 it was discovered that the 'array'
module allows for '__int__' conversions:
>>> import array, struct
>>> a = array.array('L', [1,2,3])
>>> class T(object):
... def __init__(self, value):
... self.value = value
... def __int__(self):
... return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])
As discussed in issue1172711, this behavior may not be desirable. We should
look at deprecating '__int__' and adding '__index__' as was done for the struct
module in issue1530559.
--
components: Library (Lib)
messages: 144000
nosy: mark.dickinson, meadori, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: array module: deprecate '__int__' conversion support for array elements
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue12974>
___
___
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 added the comment: > Yes, please let's not add any new __int__-based duck typing here; Mark, just to clarify a bit, the behavior is already there in the array module (by way of 'PyLong_AsLong'). The fact that it is there was picked up on a code review for this issue. Anyway, I think we should open a new issue to track the '__index__' vs. '__int__' stuff. -- ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ 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 added the comment:
>>>> import array, struct
>>>> a = array.array('L', [1,2,3])
>>>> class T(object):
> ... def __init__(self, value):
> ... self.value = value
> ... def __int__(self):
> ... return self.value
> ...
>>>> a = array.array('L', [1,2,3])
>>>> struct.pack_into('L', a, 0, 9)
>>>> a
> array('L', [9, 2, 3])
>>>> a[0] = T(100)
>>>> a
> array('L', [100, 2, 3])
>>>> struct.pack_into('L', a, 0, T(200))
> Traceback (most recent call last):
> File "", line 1, in
> struct.error: required argument is not an integer
>>>>
>
> I vastly prefer the struct module behavior. Since the code isn't executed
> by any tests:
Yeah, but if it is a good feature we can always add more tests. I think the
real issue is whether or not this behavior is even desirable. Also, similar
behavior can be achieved with struct by using '__index__':
... def __init__(self, value):
... self.value = value
... def __int__(self):
... return self.value
... def __index__(self):
... return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, T(200))
>>> a
array('L', [200, 2, 3])
Also, check out issue1530559. Originally, struct did allow the
'__int__' and '__long__' behavior, but it was deprecated and replaced
with '__index__'. Maybe we should do the same for array?
IMO, having some way to convert objects to integers is a nice feature
and I think we will find more cases like the PyCUDA case from
issue1530559 where folks need this.
--
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
Meador Inge added the comment: Heh, I was just about to upload another patch with your test case. Thanks for committing this Amaury. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12483> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7201] double Endian problem and more on arm
Meador Inge added the comment:
On Mon, Sep 12, 2011 at 7:10 AM, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> I believe the problem is specific to machines still using the old ABI
> ('OABI'). Which ABI was being used on your test machine?
I tested the new ABI (armel). I will try the old ABI. However, after
reading over the ABI differences, the problems seem to be expected.
In particular:
"""
Struct packing and alignment
With the new ABI, default structure packing changes, as do some
default data sizes and alignment (which also have a knock-on effect on
structure packing). In particular the minimum size and alignment of a
structure was 4 bytes. Under the EABI there is no minimum and the
alignment is determined by the types of the components it contains.
This will break programs that know too much about the way structures
are packed and can break code that writes binary files by dumping and
reading structures.
"""
Once I get an OABI system up and running I will substantiate that
claim. I don't think there is going to be a bug fix here as I don't
think it is practical to support both ABIs. Just a "these tests are
expected to fail due to ABI differences x, y, z" kind of thing.
--
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7201] double Endian problem and more on arm
Meador Inge added the comment: I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl Versatile kernel and everything passed. Is anyone else still seeing errors? -- assignee: theller -> nosy: +meadori -theller ___ Python tracker <http://bugs.python.org/issue7201> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Meador Inge added the comment: Would you mind explaining your use case and why ctypes won't fit it? Maybe there is something that can be fixed. FWIW, I agree that the overloading of 'size' is unnecessary. -- ___ Python tracker <http://bugs.python.org/issue12945> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Changes by Meador Inge : -- nosy: +meadori ___ Python tracker <http://bugs.python.org/issue12936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge added the comment: Patch against tip. -- assignee: -> docs@python components: +Documentation keywords: +needs review, patch nosy: +docs@python stage: needs patch -> patch review Added file: http://bugs.python.org/file23127/issue12943.patch ___ Python tracker <http://bugs.python.org/issue12943> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
Meador Inge added the comment: This patch seems reasonable, is consistent with the GC docs, and passed all regression tests. Can someone apply? -- nosy: +amaury.forgeotdarc, belopolsky, meadori stage: -> patch review type: -> behavior ___ Python tracker <http://bugs.python.org/issue12483> ___ ___ 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
Meador Inge added the comment: Ping. Any thoughts on this one? -- ___ Python tracker <http://bugs.python.org/issue12881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Meador Inge added the comment:
Yes I can. This seems strange, but it is correct. The little endian case look
like:
Little endian
---
| unsigned short | unsigned short |
---
| |
---
| 00010010 00110100 01010110 0000 |
---
where the 'd' bits pack from left to right, so '1000 01010110'.
The big endian case look like:
Big endian
---
| unsigned short | unsigned short |
---
| |
---
| 00010010 00110100 01010110 0000 |
---
where the 'd' bits pack from right to left, so '01010110 0111'.
The native case (Structure) can typically be verified using your host C
compiler. For example, the above code can be represented in C as:
#include
struct T
{
unsigned char a : 4;
unsigned char b : 4;
unsigned short c : 4;
unsigned short d : 12;
};
int main (int argc, char **argv)
{
unsigned char bytes[] = {0x12, 0x34, 0x56, 0x78};
struct T *t = (struct T*)&bytes;
printf ("%X\n", t->a);
printf ("%X\n", t->b);
printf ("%X\n", t->c);
printf ("%X\n", t->d);
}
With respect to structure layout, ctypes typically behaves the same way as the
native compiler used to build the interpreter.
--
___
Python tracker
<http://bugs.python.org/issue12945>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12927] test_ctypes: segfault with suncc
Meador Inge added the comment: I am not sure, but it does seem that way considering the most recent libffi says that 3.0.10 was released on Aug-23-11. What is the process for updating libffi anyway? Also, I posted a question concerning the Solaris Studio support on libffi-discuss: http://sourceware.org/ml/libffi-discuss/2011/msg00185.html. -- ___ Python tracker <http://bugs.python.org/issue12927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Meador Inge added the comment: Pavel, I looked into to this a little more and have some ideas. First off, '_swappedbytes_' is an undocumented implementation detail that is used to implement the LittleEndianStructure and BigEndianStructure types. So using it directly like that is not expected to work. If you want to change the endianity of the layout, then use LittleEndianStructure or BigEndianStructure instead. Next, consider your test case when removing '_swappedbytes_' and using a LittleEndianStructure. I am using a Linux hosted Python which lays out the structures in a manner similar to GCC. This gives a layout like: --- | unsigned short | unsigned short | --- | | --- | 00010010 00110100 01010110 0000 | --- 'a', 'b', and 'c' all get "expanded" into one 'unsigned short'. Then 'd' has to go in an 'unsigned short' as well leaving one byte left over with don't cares. Similarly, the big endian layout looks like: --- | unsigned short | unsigned short | --- | | --- | 00010010 00110100 01010110 0000 | --- All of this is really a roundabout way of saying that the documentation for ctypes structure layout stinks. issue12880 has been opened to fix it. Does this seem reasonable to you? -- ___ Python tracker <http://bugs.python.org/issue12945> ___ ___ 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
Meador Inge added the comment: Another example of desperately needed documentation: issue12945. -- components: +ctypes ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12927] test_ctypes: segfault with suncc
Meador Inge added the comment: According to the latest release notes (https://github.com/atgreen/libffi/blob/master/README) the Solaris compiler should be supported for building: 3.0.10 Aug-23-11 Add support for Apple's iOS. Add support for ARM VFP ABI. Add RTEMS support for MIPS and M68K. Fix instruction cache clearing problems on ARM and SPARC. Fix the N64 build on mips-sgi-irix6.5. Enable builds with Microsoft's compiler. Enable x86 builds with Oracle's Solaris compiler. Fix support for calling code compiled with Oracle's Sparc Solaris compiler. Testsuite fixes for Tru64 Unix. Additional platform support. So 'x86' builds work with 'suncc', but I guess no runtime testing was performed, which is consistent with (http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.11). I will open a bug with 'libffi'. -- ___ Python tracker <http://bugs.python.org/issue12927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12927] test_ctypes: segfault with suncc
Meador Inge added the comment:
I see what is going on. I don't think the 'libffi' code can be executed
correctly when built by 'suncc'. The code currently requires
'__attribute__((regparm(1)))', which AFAICT is not implemented by 'suncc';
only 'gcc'.
Take a look at 'ffi_closure_SYSV_inner' in
'Modules/_ctypes/libffi/src/x86/ffi.c':
void FFI_HIDDEN ffi_closure_raw_SYSV (ffi_raw_closure *)
__attribute__ ((regparm(1)));
...
/* This function is jumped to by the trampoline */
unsigned int FFI_HIDDEN
ffi_closure_SYSV_inner (closure, respp, args)
ffi_closure *closure;
void **respp;
void *args;
{
/* our various things... */
ffi_cif *cif;
void **arg_area;
cif = closure->cif;
arg_area= (void**) alloca (cif->nargs * sizeof (void*));
The '__attribute__ ((regparm(1)))' causes the first parameter to be passed in a
register and the rest of the parameters to be spilled to the stack. For most
(all?) x86 compilers, '%eax' is the first register used to pass parameters when
the calling convention requires registers.
'suncc' ignores this attribute (you can see warnings by greping the build logs)
and expects 'closure' to be on the stack where as the trampoline code puts it
in '%eax'. This causes a bogus 'closure' and a huge value for 'cif->nargs',
which overflows the stack with 'alloca'.
If you build Python on OpenSolaris with 'gcc' (pkg install gcc-dev), then
everything works fine. Does 'libffi' claim to support Solaris Studio? If not,
then this can be closed.
Also see issue1544339. This issue was run into there as well (although no one
ever really diagnosed it).
--
nosy: +meadori
___
Python tracker
<http://bugs.python.org/issue12927>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Meador Inge added the comment: I can reproduce this on Fedora 15 with the Python tip revision. I am investigating the behavior now. -- nosy: +meadori stage: -> needs patch type: -> behavior versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue12945> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
New submission from Meador Inge :
In 2.x, 'python -m tokenize' worked great:
[meadori@motherbrain cpython]$ python2.7 -m tokenize test.py
1,0-1,5:NAME'print'
1,6-1,21: STRING '"Hello, World!"'
1,21-1,22: NEWLINE '\n'
2,0-2,0:ENDMARKER ''
In 3.x, however, the functionality has been removed and replaced with
some hard-wired test code:
[meadori@motherbrain cpython]$ python3 -m tokenize test.py
TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='')
TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3),
line='def parseline(self, line):')
TokenInfo(type=1 (NAME), string='parseline', start=(1, 4), end=(1,
13), line='def parseline(self, line):')
TokenInfo(type=53 (OP), string='(', start=(1, 13), end=(1, 14),
line='def parseline(self, line):')
...
The functionality was removed here [1], but with no explanation. Let's add it
back and document the functionality this time around.
[1] http://hg.python.org/cpython/rev/51e24512e305/
--
components: Library (Lib)
messages: 143752
nosy: meadori
priority: normal
severity: normal
stage: needs patch
status: open
title: tokenize: add python -m tokenize support back
type: feature request
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue12943>
___
___
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 added the comment: Victor, I like the decorator approach much better. Thanks. Attached is a new patch with that update. -- ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ 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 : Added file: http://bugs.python.org/file23121/issue-1172711.patch ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3353] make built-in tokenizer available via Python C API
Meador Inge added the comment: It would be nice if this same C API was used to implement the 'tokenize' module. Issues like issue2180 will potentially require bug fixes in two places :-/ -- nosy: +meadori ___ Python tracker <http://bugs.python.org/issue3353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Meador Inge added the comment: That syntax error is coming from the CPython parser and *not* the tokenizer. Both CPython and the 'tokenizer' modules produce the same tokenization: [meadori@motherbrain cpython]$ cat repro.py if 1: \ pass [meadori@motherbrain cpython]$ ./python tokenize.py repro.py 0,0-0,0:ENCODING'utf-8' 1,0-1,2:NAME'if' 1,3-1,4:NUMBER '1' 1,4-1,5:OP ':' 1,5-1,6:NEWLINE '\n' 2,0-2,2:INDENT ' ' 3,0-3,1:NEWLINE '\n' 4,2-4,6:NAME'pass' 4,6-4,7:NEWLINE '\n' 5,0-5,0:DEDENT '' 5,0-5,0:ENDMARKER '' [44319 refs] [meadori@motherbrain cpython]$ ./python -d repro.py | grep Token | tail -10 File "repro.py", line 3 ^ SyntaxError: invalid syntax [44305 refs] Token NEWLINE/'' ... It's a token we know Token DEDENT/'' ... It's a token we know Token NEWLINE/'' ... It's a token we know Token ENDMARKER/'' ... It's a token we know Token NAME/'if' ... It's a keyword Token NUMBER/'1' ... It's a token we know Token COLON/':' ... It's a token we know Token NEWLINE/'' ... It's a token we know Token INDENT/'' ... It's a token we know Token NEWLINE/'' ... It's a token we know The NEWLINE INDENT NEWLINE tokenization causes the parser to choke because 'suite' nonterminals: suite: simple_stmt | NEWLINE INDENT stmt+ DEDENT are defined as NEWLINE INDENT. It seems appropriate that the NEWLINE after INDENT should be dropped by both tokenizers. In other words, I think: """ if 1: \ pass """ should produce the same tokenization as: """ if 1: pass """ This seems consistent with with how explicit line joining is defined [2]. [1] http://hg.python.org/cpython/file/92842e347d98/Grammar/Grammar [2] http://docs.python.org/reference/lexical_analysis.html#explicit-line-joining -- stage: test needed -> needs patch ___ Python tracker <http://bugs.python.org/issue2180> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12927] test_ctypes: segfault with suncc
Changes by Meador Inge : -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue12927> ___ ___ 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 added the comment: Vlad, I agree that having both 'c_char_p' and 'POINTER(c_char)' will just be more work for two seemingly identical constructs. I don't fully understand why both would be needed either (or the implications of removing one of them or making them synonyms). I guess a little software archeology is in order. -- ___ Python tracker <http://bugs.python.org/issue5149> ___ ___ 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 added the comment: Here is a refresh of this patch for 3.3. Please review. -- Added file: http://bugs.python.org/file23100/issue-1172711.patch ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ 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
Meador Inge added the comment: Attached is a first cut at a patch. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file23099/issue9969.patch ___ Python tracker <http://bugs.python.org/issue9969> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
