Meador Inge added the comment:
Is this work something that might be suitable for the features/pep-3118 repo
(http://hg.python.org/features/pep-3118/) ?
--
___
Python tracker
<http://bugs.python.org/issue3
Meador Inge added the comment:
Here is a patch that replaces the 'alloca' call with 'PyMem_Malloc'.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23094/issue12881.patch
__
Meador Inge added the comment:
This is busted for plain old assignment too:
Python 3.3.0a0 (default:6374b4ffe00c, Sep 2 2011, 23:50:39)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type "help", "copyright", "credits" or "license" for more inform
Meador Inge added the comment:
This has been fixed. I verified tip and 2.7.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
On Fri, Sep 2, 2011 at 4:26 PM, Amaury Forgeot d'Arc
wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Certainly the effect of some "alloca" call with a large value, then the stack
> overflows.
Yeah, I noticed that too.
New submission from Meador Inge :
Reproduced on Fedora 15 with tip Python:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:3102951cc1ce+, Sep 1 2011, 22:19:06)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type "help", "copyright", "credi
Meador Inge added the comment:
Vlad,
Thanks for the patch. A few nits:
1. The test case is in 'test_bitfields.py'.
I think it should go in 'test_structures.py'.
2. The test case would probably be cleaner using a 'with' context
manager:
Changes by Meador Inge :
--
assignee: theller ->
nosy: -theller
priority: normal -> low
stage: -> patch review
type: -> compile error
___
Python tracker
<http://bugs.pytho
Changes by Meador Inge :
--
assignee: theller ->
nosy: -theller
priority: normal -> low
stage: -> needs patch
___
Python tracker
<http://bugs.python.o
Meador Inge added the comment:
Whoops. I meant to post a link to the commit before. It is here:
http://hg.python.org/cpython/rev/584db03e5248.
--
___
Python tracker
<http://bugs.python.org/issue6
Meador Inge added the comment:
This was, in fact, committed already.
--
assignee: theller ->
nosy: +meadori -theller
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pytho
Changes by Meador Inge :
--
assignee: theller ->
nosy: -theller
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue9175>
___
___
Pyth
Changes by Meador Inge :
--
nosy: -theller
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue9030>
___
___
Python-bugs-list mai
Meador Inge added the comment:
Hi Steve,
There is currently no way to deal with this situation. Vlad has opened
issue12528 with a proposal to make the allocation strategy configurable from
the 'ctypes' API. Please follow that issue if you are still interested. I am
closing
Meador Inge added the comment:
I opened issue12880 for the doc bug. Closing this one out ...
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Meador Inge :
--
stage: test needed -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue6069>
___
___
Python-bugs-list mai
New submission from Meador Inge :
As issues like issue6069 and issue11920 allude to, figuring out how 'ctypes'
allocates bit-fields is not very clear. The documentation should be enhanced
to flesh this out in more detail. As an example, Microsoft documents the VC++
implement
Meador Inge added the comment:
Hi Vlad,
On Thu, Sep 1, 2011 at 1:30 PM, Vlad Riscutia wrote:
> Vlad Riscutia added the comment:
>
> Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC
> and MSVC builds. This feature tries to remove the
> hardcod
Meador Inge added the comment:
As stated, how a particular compiler allocates bitfields is *extremely*
implementation specific. There can be differences in implementations between
different compilers, different *versions* of the same compiler, and different
invocations of the same compiler
Meador Inge added the comment:
On Thu, Sep 1, 2011 at 9:45 AM, Vlad Riscutia wrote:
> Vlad Riscutia added the comment:
>
> Meador, I believe this was the first issue on the tracker that got me looking
> into bitfield allocation.
> I agree that big-endian on MSVC doesn't
Meador Inge added the comment:
Hmmm ... Assuming a native VC++ compiler on an x86 machine running Windows,
then it doesn't make sense to validate these test cases in such an environment.
All the tests are all big-endian.
'ctypes' can't be expected to behave the same as
Meador Inge added the comment:
Thanks a lot for committing this for me Amaury.
--
___
Python tracker
<http://bugs.python.org/issue11241>
___
___
Python-bug
Meador Inge added the comment:
That is a good question. While it is true that errors other than
'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is
a bad thing. Any errors that come out of 'PyFloat_AsDouble' should be handl
Meador Inge added the comment:
This patch was marked as accepted, but it doesn't seem to be committed. Will
someone commit it?
--
___
Python tracker
<http://bugs.python.org/is
Changes by Meador Inge :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue7433>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Meador Inge :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue2651>
___
___
Python-bugs-list mailing list
Un
Changes by Meador Inge :
--
resolution: accepted ->
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue8743>
___
___
Pyth
Meador Inge added the comment:
Ping. I think this one is OK to commit.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue9651>
___
___
Pytho
Meador Inge added the comment:
I agree that this violates C99, but is this actually causing any real world
problems with the platforms Python supports? If so, then we need a test case.
This seems low priority
--
assignee: theller ->
nosy: +amaury.forgeotdarc, belopol
Meador Inge added the comment:
Stefan, it is a constructed failure (I hacked the unit test to break it).
--
___
Python tracker
<http://bugs.python.org/issue12
Meador Inge added the comment:
On Sun, Aug 14, 2011 at 1:03 PM, Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> I like random tests in the stdlib, otherwise the same thing gets tested
> over and over again. `make buildbottest` prints the seed, and you can do
> it
Meador Inge added the comment:
The functionality part of the patch looks reasonable. However, the
pseudo-randomization in the unit tests seems like a bad idea. Say someone is
adding a new feature X. Runs the unit tests to find one of them failing. Then
runs them again to investigate and
Meador Inge added the comment:
Amaury, how about this patch? I got rid of querying the type dictionary and
hoisted the creation of the type instance earlier. Then
'PyObject_GetAttrString' can be used to lookup '_length_' and '_type_' by the
regular Pyt
Meador Inge added the comment:
Michael,
It is hard to tell from your description alone where the bug is. Could you
provide more detailed reproduction steps with a test case that exhibits the
issue?
--
nosy: +jnoller, meador.inge
stage: -> test nee
Changes by Meador Inge :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue12744>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue12744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue11105>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
I see two problems that cause the posted test cases to fail:
1. The 'next' fixer runs before the 'itertools' fixer and strips
out a 'power' node. This keeps the 'itertools' fixer from
matching.
2. The '
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue12613>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue4841>
___
___
Python-bugs-list mailing list
Un
Meador Inge added the comment:
OK, I am marking this as fixed then. If someone decides to fix this in 3.2 or
3.7, then they can reopen the issue.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
_
Meador Inge added the comment:
I have verified that the code checked in for issue12575 keep the test case from
this issue from crashing the interpreter:
[meadori@motherbrain cpython]$ ./python test.py
Traceback (most recent call last):
File "test.py", line 14, in
compiled
Meador Inge added the comment:
Thanks for the test case Albert. The attached patch adds a unit test based off
of the given repro case and fixes the bug in the FunctionDef compiler. The
compiler was hitting a NULL pointer deref on FunctionDefs with empty list
bodies.
Reproduced and fixed
Meador Inge added the comment:
> But what happens with a third level?
That doesn't work. I have a test case for that, but the test case has
a typo that caused it to pass. I will fix the test case and the code.
Thanks.
--
___
Python tracke
Changes by Meador Inge :
--
components: +Macintosh
___
Python tracker
<http://bugs.python.org/issue10910>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
This doesn't look like it has anything to to with the 'ctypes' library
component (http://docs.python.org/library/ctypes). So I am removing
'ctypes' from the 'Components' selection. Please correct me if I am
wrong ...
---
Meador Inge added the comment:
Verified that this is still broken in the main development branch.
The base type should be checked for '_type_' or '_length_' before throwing
an error. Attached is a patch that fixes the problem and adds covering
tests. The full test
Meador Inge added the comment:
This crash still occurs in the main development branch and Amaury's patch
still fixes the problem. I verified that all tests pass on OS X 10.6.5.
It should be OK to commit.
--
assignee: theller ->
nosy: +meador.inge -theller
versions: +Py
Meador Inge added the comment:
This problem still occurs in the main development branch. I think the
'PyErr_ExceptionMatches' check that Pauli suggested will work. The same
problem exist for 'c_float', 'c_double', and 'c_longdouble'.
Attached is a
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue11477>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
Is there still any interest in this work?
--
___
Python tracker
<http://bugs.python.org/issue3132>
___
___
Python-bugs-list mailin
Meador Inge added the comment:
Attached is the latest version of the struct string patch. I tested on OS X
10.6.5 (64-bit) and Ubuntu 10.04 (32-bit). I also scanned for memory problems
with Valgrind. There is one test failing on 32-bit systems ('test_crasher').
This is due t
Meador Inge added the comment:
> How is the compiler supposed to know whether a and b belong to the same
> array when compiling ptr_compare?
I agree with Mark, it doesn't need to know. However, many compilers [1,2]
support whole program optimization and could in theory figure the
Changes by Meador Inge :
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue9969>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Meador Inge :
Currently with 'py3k' only 'bytes' objects are accepted for tokenization:
>>> import io
>>> import tokenize
>>> tokenize.tokenize(io.StringIO("1+1").readline)
Traceback (most recent call last):
File
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue2180>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
I agree with Antoine's LIFO comment. Also, FWIW, the C standard library
behaves in a LIFO manner as well (C99 spec - 7.20.4.3 clause 3):
"First, all functions registered by the atexit function are called, in the
reverse order of their registration,2
Meador Inge added the comment:
> To fix the segfault, I suppose that we use a more strict validation on
> the input type. Eg. Use PyUnicode_Check() instead of
> PyObject_IsInstance()?
Where would the more strict validation take place? This problem is not unique
to Unicod
Meador Inge added the comment:
Overall, this patch look reasonable. I tested on py3k and the the tests pass.
I also did a few micro-benchmarks to verify the speedup.
One question I do have, though, is whether the 'len' calculation modifications
are necessary? This looks like
Meador Inge added the comment:
I believe this is slightly tricky because 'bdb.format_stack_entry' makes
references to '.f_locals' and 'bdb.format_stack_entry' is invoked in several
places in 'pdb'. One option would be to add a extra parameter
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue9633>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
Overall the patch looks good. I don't think it is an extremely important
feature, but similar support is already available in other places (e.g.
'struct', 'ctypes').
Here is a patch updated for py3k with some minor addition
Changes by Meador Inge :
--
assignee: teoliphant -> meador.inge
priority: critical -> high
stage: unit test needed -> needs patch
___
Python tracker
<http://bugs.python.o
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue5248>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue4188>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue9249>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Meador Inge added the comment:
Sure. I take it you meant http://svn.python.org/projects/sandbox/trunk/2to3,
though. Is this the location that all patches for 2to3 should be produced
against?
I dropped the documentation changes b/c I did not see any docs in the 2to3
trunk. Should the doc
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue9011>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Meador Inge added the comment:
[Mark]
> Can you think of any reason that we shouldn't just copy the py3k
> implementation ...
Not that I can think of. Like you pointed out, we should have removed the
coercion from the rich comparison when fixing issue 5211.
> Thanks for all
Changes by Meador Inge :
--
stage: -> needs patch
type: -> feature request
___
Python tracker
<http://bugs.python.org/issue2470>
___
___
Python-bugs-list
Changes by Meador Inge :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue8748>
___
___
Python-bugs-list mailing list
Unsubscri
Meador Inge added the comment:
> I'm not sure that's a good idea: mightn't this change behaviour for
> user-defined classes with a __coerce__ method? Maybe it would be
> better to just special-case ints and longs at the start of
> complex_richcompare, and then le
Meador Inge added the comment:
> Hmm. The current Python 2.7 behaviour really is a mess.
No doubt!
> Your patch removes the coercion entirely;
Yeah, I know. The funny thing about this is that according to the
documentation [1]:
"Arguments to rich comparison methods are ne
Meador Inge added the comment:
2.7 patch attached. The implementation is mostly the same as the 3.2 one, but
there is one quirk. Namely, 2.7 (and other 2.x's) has the following odd
behavior:
>>> 1j < None
False
>>> 1j < 1
Traceback (most recent cal
Meador Inge added the comment:
No problem! I have attached the updated patch.
I am starting on the 2.7 patch now.
--
Added file: http://bugs.python.org/file17424/issue-8748.2.patch
___
Python tracker
<http://bugs.python.org/issue8
Meador Inge added the comment:
> Granted, yes. But I wouldn't expect the same padding for 'BT{BI}' and
> 'BBI'. 'BT{BI}' should match a C struct which itself has an embedded
> struct. For C, I get the following results on my machine:
I wasn
Meador Inge added the comment:
> Thanks for the updated patch; I'll take a closer look tonight, and
> apply it if all looks good.
I incorporated the changes locally and have not updated the patch yet. I will
update it later today.
--
___
Meador Inge added the comment:
> As a separate issue, I notice that the new 'T{}' code doesn't respect
> multiplicities, e.g., as in 'H3T{HHL}'. Is that
> intentional/desirable?
That could have been an oversight on my part. I don't see any immediate r
Meador Inge added the comment:
Thanks for the review. I incorporated the check re-orderings.
I am also writing more tests. Which already exposed a subtly that I was not
expecting:
Python 3.2a0 (py3k:81284M, May 20 2010, 09:08:20)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "
Meador Inge added the comment:
> is that correct, or should the production list be something like:
Yup, you are right. I will change the grammar.
> Whether these cases are valid or not (personally, I think they should
> be), we should add some tests for them. '<' *
Meador Inge added the comment:
Does this patch seem reasonable?
--
___
Python tracker
<http://bugs.python.org/issue7902>
___
___
Python-bugs-list mailin
Meador Inge added the comment:
> For a complex number z and an integer i, 'z == i' should be exactly
> equivalent to 'z.real == i and z.imag == 0.0'.
Like you mentioned before a lot of care is taken in 'floatobject.c' to ensure
that the comparison is rob
Meador Inge added the comment:
Sure - http://codereview.appspot.com/1258041
--
___
Python tracker
<http://bugs.python.org/issue3132>
___
___
Python-bugs-list m
Meador Inge added the comment:
Attached is a patch that implements part of the additions. More specifically,
the 'T{}' syntax and the ability to place byte-order specifiers ('<', '>', '@',
'^', '!", '=') anywhere in
Meador Inge added the comment:
Those last two sentences where meant to be in response to your "Merged your
changes and subsequent tweaks to py3k in r80016." comment. I tried to reply to
the tracker from my mail client and things got r
Meador Inge added the comment:
> Sure, if you want to. [Then I won't be able to reproduce what's in the
> docs on either of my machines. :) One's 32-bit big-endian; the other's
> 64-bit little-endian.]
>
I guess it's painful either way. I think the only
Meador Inge added the comment:
> wonder whether they should be converted to little-endian
I thought about that as well. It sure would make creating new examples easier
:) I had to construct the new examples "by hand".
I can regenerate the examples for little-endian if y
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue7433>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Meador Inge added the comment:
> would be to add enough padding so that the alignment of the struct
> matches the largest alignment of any member of the struct.
That might work. I will have to think about it a bit.
> On the subject of documentation
Attached a doc patch which
Meador Inge added the comment:
> I'm half-convinced that struct.pack *should* ideally add trailing
> padding in the same situation that C does, for consistency with C.
> Then calcsize would match C's sizeof.
Maybe... AFAIK, the C language does not mandate structure paddi
Changes by Meador Inge :
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue7355>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Meador Inge added the comment:
Looks good to me.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue8300>
___
___
Python-bugs-list mai
Meador Inge added the comment:
I may be missing something subtle, but how can 'PyNumber_Index(v) != NULL'
*and* '!PyInt_Check(v) && !PyLong_Check(v)' both be satisfied in the
'get_pylong' mods? It seems to me that 'PyNumber_Index' only return
Meador Inge added the comment:
Hi Eric,
(-2) and (-3) are different. The changes that I made, however, are pretty
minor. Also, they are all in 'test_builtin.py'.
--
___
Python tracker
<http://bugs.python.
Meador Inge added the comment:
> (2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer
> on top of the C layer. Partly I'm worried about accidentally breaking
> something (it's not 100% clear to me whether there might be hidden
> side-ef
Meador Inge added the comment:
It seems to me from the grammar
(http://docs.python.org/reference/expressions.html#grammar-token-conditional_expression)
that the precedence for conditional expressions fall in between that of
'lambda' and 'or' expressions.
--
k
Meador Inge added the comment:
> If anyone's interested in submitting a patch, it would be welcome.
Sure. I saw where this was partly addressed in r78690. The attached patch
adds support for the '__index__' conversion that Mark
suggested.
At first glance, the patch
Meador Inge added the comment:
> This is common practice in the standard library.
This doesn't necessarily mean it is a correct practice :-). All
kidding aside, I think the assumption that the standard documentation
on '__enter__' and '__exit__' is sufficient is
Meador Inge added the comment:
> What about changing the exception test to something like what I did in >
> issue7232.4.diff?
That is definitely more succinct, but Lars' solution provides more information
about _why_ the test fails. IMHO, the descriptiveness is
more
501 - 600 of 629 matches
Mail list logo
