[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
[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
[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
[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
[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
[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
[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:
> 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
[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
[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
[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
[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: 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
[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
[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
[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
[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
[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: 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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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: > 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
[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
[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
[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
[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
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
[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
[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
[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
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
[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
[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
[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
[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
[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
[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
[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
[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
[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: 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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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: 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
[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
[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
[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
[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
[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
[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
[issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
Meador Inge added the comment: >> P.S. We could probably get rid of the HAVE macro all together by doing >> all the work in the 'configure' script. > Would that be a breach of backward compatibility for sysconfig? Yeah, I think so. Best to leave it alone then. -- ___ 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
[issue12618] py_compile cannot create files in current directory
Meador Inge added the comment: I think it might be easier to just always use the absolute path rather than looking at the directory length. Maybe something like the attached. I added unit tests as well. -- nosy: +meador.inge stage: test needed -> patch review Added file: http://bugs.python.org/file23523/issue12618-0.py ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13272] 2to3 fix_renames doesn't rename string.lowercase/uppercase/letters
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13272> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13266> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13253] 2to3 fix_renames renames sys.maxint only in imports
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13298] Result type depends on order of operands for bytes and bytearray
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13298> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue10977> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13328] pdb shows code from wrong module
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13328> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11427] ctypes from_buffer no longer accepts bytes
Meador Inge added the comment: I agree this is a regression. I am looking more into it now. -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue11427> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13370] test_ctypes fails on osx 10.7
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11427] ctypes from_buffer no longer accepts bytes
Meador Inge added the comment: Hmmm... I take back what I said before (not sure what I was thinking), I don't think this is a regression. If this ever did work, it must have been a bug. For one reason, Python byte strings are now immutable. Allowing their memory to be indirectly mutated in Python via buffers created from 'from_buffer' would be very bad. Also, I can't reproduce the reported behavior with 3.1.3: Python 3.1.3 (unknown, Nov 9 2011, 19:57:58) [GCC 4.6.1 20110908 (Red Hat 4.6.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> (ctypes.c_char*5).from_buffer(b'abcde') Traceback (most recent call last): File "", line 1, in TypeError: expected an object with a writable buffer interface Are you sure it was 3.1.3? At first I thought you might be using 3.0a, since bytes are mutable in that version, but 'from_buffer' didn't exist in those times. -- ___ Python tracker <http://bugs.python.org/issue11427> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13380] ctypes: add an internal function for reseting the ctypes caches
New submission from Meador Inge : Currently it is possible to somewhat easily get false positives for reference leaks when running the ctypes regression tests with -R. See issue13250 for an example where I got tripped up. The reason is that the ctypes caches are not cleared in between test runs like they are with some of the other modules that cache objects. The attached patch adds an internal function for reseting the ctypes caches. regrtest.py is then fixed up to use it. Finally, two tests that previously relied on the caching being present to work in back-to-back runs have been fixed. In particular, the tests were written to do something like: # Global dll = CDLL(_ctypes_test.__file__) # Local to test f = dll._testfunc_callback_i_if f.restype = c_int MyCallback = CFUNCTYPE(c_int, c_int) def callback(value) return value cb = MyCallback(callback) result = f(-10, cb) f.argtypes = [c_int, MyCallback] cb = MyCallback(callback) result = f(-10, cb) Thus when run in back-to-back runs where caching is cleared in between you effectively get: # Global dll = CDLL(_ctypes_test.__file__) # Local to test f = dll._testfunc_callback_i_if f.restype = c_int MyCallback = CFUNCTYPE(c_int, c_int) def callback(value): return value cb = MyCallback(callback) result = f(-10, cb) f.argtypes = [c_int, MyCallback] cb = MyCallback(callback) result = f(-10, cb) _reset_cache() f = dll._testfunc_callback_i_if f.restype = c_int MyCallback = CFUNCTYPE(c_int, c_int) cb = MyCallback(callback) result = f(-10, cb) which causes: types.ArgumentError: argument 2: : expected CFunctionType instance instead of CFunctionType because the final MyCallback instance passed to f is not of the same type as the MyCallback type saved in f.argtypes. The fix is to set f.argtypes to None at the beginning of each test. I would also like to commit this to 2.7 and 3.2. It will make fixing true reference leaks in those branches easier. OK? -- assignee: meador.inge components: ctypes files: ctypes-reset-cache.patch keywords: patch messages: 147394 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: patch review status: open title: ctypes: add an internal function for reseting the ctypes caches type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23651/ctypes-reset-cache.patch ___ Python tracker <http://bugs.python.org/issue13380> ___ ___ 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: I opened issue13380 for fixing the ctypes regrtest caching problem. -- ___ 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
[issue13380] ctypes: add an internal function for reseting the ctypes caches
Meador Inge added the comment: > - you duplicated the part with "CFUNCTYPE(c_int)(lambda: None)" without > removing the original chunk of code > - some platforms can't compile ctypes, you must handle that case in > regrtest Both fixed. Thanks for the review. Second patch attached. -- Added file: http://bugs.python.org/file23689/ctypes-reset-cache-2.patch ___ Python tracker <http://bugs.python.org/issue13380> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13411] Hashable memoryviews
Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker <http://bugs.python.org/issue13411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Meador Inge added the comment: Éric, sure, I will commit the tests sometime today. Then I will respond to the 'os.path.abspath' question as well. -- ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13380] ctypes: add an internal function for reseting the ctypes caches
Meador Inge added the comment: Committed. Thanks for the review Antoine. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13380> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Meador Inge added the comment: On Sat, Nov 26, 2011 at 7:17 AM, Antoine Pitrou wrote: > The tests break on the Windows buildbots: I am investigating now. -- ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Meador Inge added the comment: The tests are fixed now. A relative path was being computed, but on Windows the current working directory drive and the drive of the relative path we were computing was different (and so this test bug would *not* be seen if running on a Windows box with a single "C: drive" setup). /me sighs at the concept of Windows drives. Thanks for the heads up on the test break Antoine. -- ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Meador Inge added the comment: > we don’t know what people do with symlinks and relative paths out > there, so I’d prefer adding a safe special case* rather than always > calling abspath. What do you think? Éric, I agree. I didn't know about the strange symlink + relative path behavior with 'os.path.normpath', but [1] cleared me up. With that in mind the special casing is OK. I have attached an updated patch with a unit test. Also, this is not an issue for Python 2.7. The 2.7 implementation assumes any directories mentioned in the path already exist. So, I removed 2.7 from the affected versions. [1] http://mail.python.org/pipermail/python-dev/2005-December/058452.html -- versions: -Python 2.7 Added file: http://bugs.python.org/file23789/issue12618-1.patch ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
