Meador Inge added the comment:
I just read through all this and see three separate points be discussed:
1. The unbounded caching behavior.
2. A more compact representation for repeat counts.
3. Correct __sizeof__ support for struct.
For issue (1) I think this is unfortunate, but I don&#
Meador Inge added the comment:
Thanks for the patch Julia!
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Meador Inge :
--
nosy: +meador.inge
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15397>
___
___
Python-bugs-list mai
Meador Inge added the comment:
This looks OK to me (I don't see a way to write a test case to cover the leak).
I will commit later today unless I hear some objections.
--
assignee: -> meador.inge
nosy: +meador.inge
stage: -> commit review
versions:
Changes by Meador Inge :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Meador Inge added the comment:
The problem is with the 'BIT_MASK' macro, which is currently defined as the
following for Windows:
#define BIT_MASK(size) ((1 << NUM_BITS(size))-1)
The C standard says that any attempt to shift left by exactly the bit width is
undefined be
Meador Inge added the comment:
I am closing this issue in favor of issue6493. This patch attached to this
issue is incorrect. The proposed definition of BIT_MASK allows for undefined
behavior when the number of bits shifted is 64 for a uint64. The patch in
issue6493 handles this case
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14596>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
D'oh! Thanks for catching that Serhiy! Fixing now. Sorry about that.
--
___
Python tracker
<http://bugs.python.org/is
Meador Inge added the comment:
Committed. Thanks for the reviews y'all.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2
___
Python tracker
<http:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue12834>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
BTW, I think this should be committed on 2.7 and 3.2 as well since the same
issue can happen when throwing -R. Any objections?
--
___
Python tracker
<http://bugs.python.org/issue15
Meador Inge added the comment:
I can commit today unless you think we need someone else to independently
verify the patch.
--
___
Python tracker
<http://bugs.python.org/issue15
Meador Inge added the comment:
Oh, cool -- I didn't know about the importlib benchmarks. Thanks Brett.
Here are the results (OS X 10.7.4, Dual 1.7GHz Core i5, 4 GB RAM):
$ ./python.exe -m importlib.test.benchmark
Measuring imports/second over 1 second, best out of 3
Entire benchmar
Meador Inge added the comment:
New patch that addresses feedback from Brett's code review (thanks!).
--
Added file: http://bugs.python.org/file26418/issue15368-v1.patch
___
Python tracker
<http://bugs.python.org/is
Meador Inge added the comment:
I haven't done any benchmarking (yet), but here is a patch implementing the
basic sorting approach.
--
keywords: +patch
Added file: http://bugs.python.org/file26409/issue15368-v0.patch
___
Python tracker
Meador Inge added the comment:
On Mon, Jul 16, 2012 at 8:11 AM, Brett Cannon wrote:
> I might come to regret asking this, but so what? Is this actually causing you
> issues,
> or are you literally just finding "this behavior surprising" and that's it?
I noticed it i
Meador Inge added the comment:
On Mon, Jul 16, 2012 at 7:13 AM, Antoine Pitrou wrote:
> I don't know, but you could open an issue just for the record.
> People may be surprised if bytecode generation isn't deterministic.
Yeah, I was somewhat surprised and it took some diggi
New submission from Meador Inge :
Consider this small example (you might have to run sample program multiple
times to see a difference):
$ cat dis-closure.py
import dis
def adder(a, b):
def add():
return a + b
return add
print(dis.dis(adder(1, 2).__code__))
$ ./python.exe
Meador Inge added the comment:
On Mon, Jul 16, 2012 at 5:20 AM, Antoine Pitrou wrote:
>> Anyway, I am hitting another problem now -- _freeze_importlib is *not*
>> idempotent.
>
> What do you mean with "idempotent"? Deterministic?
Whoops, yeah, determinis
Meador Inge added the comment:
Hmmm, I guess the idempotency issue is no worse than it already is -- the
same thing can still happen with trivial changes to the other prerequisites
for importlib.h.
Consider this small example (you might have to run sample program multiple
times to see a
Meador Inge added the comment:
Eric, that is a good point, but if someone forgets (like I did) or just hasn't
gotten around to bumping the number yet, then the build breaks because the
interpreter crashes. I think we should always try to avoid building an
interpreter that is
Meador Inge added the comment:
Patch attached.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26382/issue15352-v0.patch
___
Python tracker
<http://bugs.python.org/issu
New submission from Meador Inge :
Today I was hacking on a patch that changes the marshaling format for Code
objects. When building the patch I was met with:
ValueError: bad marshal data (unknown type code)
make: *** [Lib/_sysconfigdata.py] Abort trap: 6
This is because the frozen
Meador Inge added the comment:
This is still broken after the libffi update (issue15194). The errors are the
same as Alex mentioned when he tested libffi-3.0.11. The right way to go is to
get this fixed in upstream libffi and backport the patch.
--
assignee: theller ->
st
Meador Inge added the comment:
Matthias recently updated libffi to 3.0.11 (issue15194). It would seem that we
intend to keep a local copy of the libffi sources for now and that this issue
can be closed. Does anyone see a reason to keep this open
Meador Inge added the comment:
> Meador, can we close this issue?
I wanted to keep it open until the 'long double' problem is fixed as well.
--
___
Python tracker
<http://bugs.pytho
Meador Inge added the comment:
Stefan, nope -- I never got a reply. I will try again.
--
___
Python tracker
<http://bugs.python.org/issue12927>
___
___
Pytho
Changes by Meador Inge :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15119>
___
___
Python-bugs-list mailing list
Unsubscri
Meador Inge added the comment:
>> At a guess, BITS.M should therefore look like > ofs=0:17, bits=1> instead.
>
> Refined guess: it should be .
This refined guess seems reasonable. Although, bitfield allocation order for
GCC is dependent on the target ABI. What you have
Meador Inge added the comment:
Thanks for digging into this Mark. I will have a look too later in the day.
--
___
Python tracker
<http://bugs.python.org/issue15
Meador Inge added the comment:
Nice patch Antoine! The method of partitioning the object sets into frozen and
non-frozen is nice.
> The proposed "-X" or BOOTSTRAP_PY approaches would be difficult, since there
> doesn't appear to be an easy way to generate a g
Changes by Meador Inge :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: -Python 3.2
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
Python 2 patch looks OK too. I will commit these later today. Thanks for the
patches!
--
___
Python tracker
<http://bugs.python.org/issue15
Meador Inge added the comment:
Nevermind, the tests are OK. I missed the swapped quotes.
--
___
Python tracker
<http://bugs.python.org/issue15054>
___
___
Pytho
Meador Inge added the comment:
The Python 3 patch looks OK, except that several of the tests are duplicated.
I am looking at the Python 2 patch now.
--
___
Python tracker
<http://bugs.python.org/issue15
Meador Inge added the comment:
I didn't get around to updating my patch with Nick's comments yet.
Nick, the v3 patch I have attached still applies. I am happy to update it per
your comments (promptly this time) or you can take it over.
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14956>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14928>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue12370>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
> can you give me an example of how it could break working code?
This is a bit contrived, but:
# my fdopen
def fdopen(fd):
pass
fdopen(1)
# some stuff
from os import *
# more stuff
fdopen(1)
Here is a patch for 3.3 tip. After reviewing the 'os
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
I think this came in when we moved os.fdopen and os.popen from native C code to
Python code in http://hg.python.org/cpython/rev/1f7891d84d93. This works fine
in 2.7. The same issue exist with os.popen, but that is deprecated.
--
nosy: +meador.inge
Meador Inge added the comment:
Ouch. The '__class__' behavior is documented here too:
http://docs.python.org/py3k/library/functions.html?highlight=__class__#super.
Unfortunately I don't see any other documentation on the lexically scoped form
of __class__.
As implied,
Meador Inge added the comment:
> I would still like to see the zipfile module to be able to detect
> ill-formed zipfiles - certainly not by default.
Agreed. We already do produce some informational messages via the
documented 'ZipFile.debug' attribute. Just checking that fl
Meador Inge added the comment:
On Mon, May 14, 2012 at 12:31 PM, Serhiy Storchaka
wrote:
> Serhiy Storchaka added the comment:
>
>> This is definitely *not* a padding issue.
>
> This is definitely a padding issue. All uncompressed files are located
> so that the data
Meador Inge added the comment:
FWIW, I think it will OK to just ignore extra fields that we can't
interpret as according to the standard. The only one we currently
care about is the "Zip64 extended information extra field". Also,
other programs (including the Info-Zip tools)
Meador Inge added the comment:
This is definitely *not* a padding issue.
The problem is that one of the records has an extra field of length 1:
$ zipinfo -v bla.apk
...
Central directory entry #3:
---
There are an extra 16 bytes preceding this file.
res/raw
Changes by Meador Inge :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
And the examples make an explicit note of that:
"""
.. note::
All examples assume a native byte order, size, and alignment with a
big-endian machine.
"""
AMD64 is little-endian; the examples are noted to be in big-endian
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14701>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
> I suggest to not apply additional patches for Modules/_ctypes/libffi*
> due to issue #12081. Patches for libffi should be sent to libffi
> upstream.
For trunk I agree. However, it is probably worth considering this patch
for 2.7 and 3.2.
Did anyone
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue4130>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue8212>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14507>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue12864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14373>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
LLVM/clang bug report here: http://llvm.org/bugs/show_bug.cgi?id=12207.
--
___
Python tracker
<http://bugs.python.org/issue13
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14169>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14181>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13951>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14184>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14189>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
Ouch, WeakSet.__lt__ and WeakSet.__gt__ are defined in terms of set.issubset
and set.issuperset, respectively. set.issubset and set.issuperset are *not*
proper subset and superset operations, thus the error. The attached patch
fixes this.
--
keywords
Meador Inge added the comment:
The change in error handling makes this a bit harder to review, but it
otherwise looks OK if this is the intended behavior. I am not sure that it is.
The original version:
1. If __qualname__ was present in the original dictionary,
then it was deleted
Meador Inge added the comment:
haypo, I can reproduce the segfault using the 'None' test case on your patch as
well.
--
___
Python tracker
<http://bugs.python.o
Meador Inge added the comment:
I can reproduce the segfault on F16:
Python 3.3.0a0 (default:3828d93fd330, Feb 23 2012, 13:49:57)
[GCC 4.4.6] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {'__qua
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue14095>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13938>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13970>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13977>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
When I try to build with the attached patch on the 2.7 branch many (if not all)
of the modules fail to build:
Failed to build these modules:
_bisect_bsddb _codecs_cn
_codecs_hk _codecs_iso2022_codecs_jp
_codecs_kr
Meador Inge added the comment:
Stefan, how did you reproduce this? I tried:
1. Uncommenting '#define Py_USING_MEMORY_DEBUGGER' in
'Objects/obmalloc.c'.
2. Configuring with './configure --without-pymalloc'.
3. Running 'valgrind --tool=memcheck --log-
Meador Inge added the comment:
After thinking about it a bit more I am OK with Vinay's proposal. Attached is
an updated patch.
Also, I also noticed that the 'struct' module has the same problem:
>>> big_int = int(sys.float_info.max) * 2
>>> struct.pack(&#x
Changes by Meador Inge :
--
type: behavior -> enhancement
___
Python tracker
<http://bugs.python.org/issue6259>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Meador Inge :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
'find_library' itself actually loads no libraries. I suspect what happened was
that the following code in the 'uuid' module coupled with the 'find_library'
bug caused 'liblttng-ust-libc.so' to be loaded:
f
Meador Inge added the comment:
> So perhaps as a temporary workaround, we could tweak setup.py to set
> -O0 for building ctypes with clang?
That would make the tests pass, but it still won't fix the fundamental
issue. clang and GCC have a difference in opinion as to when function
Meador Inge added the comment:
It turns out that this isn't OS X specific. I can reproduce the exact same
issue by building with clang on a 64-bit Fedora 16 box.
--
components: -Macintosh
title: test_ctypes fails on osx 10.7 -> test_ctypes fails when building python
wi
Meador Inge added the comment:
> Since the first argument is a 'signed char', that should be 'movsbq'.
Hmmm, on second thought I am not 100% sure about that exact statement, but I
still think this is most likely a clang bug having something to
Meador Inge added the comment:
So I have debugged the first failure and it has to do with the sign extending
of 'signed char' parameters. The first test case basically does this:
_dll = CDLL(_ctypes_test.__file__)
_dll.tf_b.restype = c_byte
_dll.tf_b.argtypes
Meador Inge added the comment:
I can reproduce it without --with-pydebug. Thanks. I will investigate.
--
___
Python tracker
<http://bugs.python.org/issue13
Meador Inge added the comment:
I can't reproduce this on Lion using the 2.7 or default branches. I can't
build with GCC at the moment because of issue13241. I am using the clang that
ships with Lion:
motherbrain:cpython meadori$ sw_vers
ProductName:Mac OS X
ProductVersi
Meador Inge added the comment:
I just fixed the docs and error message for now. I might revisit the ASCII
decoding later. Thanks for the bug report Vincent.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
Meador Inge added the comment:
The 'create_unicode_buffer' docs are currently wrong too:
"""
If the first parameter is a bytes object, it is converted into an
unicode string according to ctypes conversion rules.
"""
>>> ctypes.create_unicod
New submission from Meador Inge :
As mentioned in issue13672 currently there is no way to specify a
qualname on types.FunctionType:
>>> def f():
...def g():
... pass
...return g
...
>>> g = f()
>>> g
.g at 0x7f1dac4d8ba0>
>
Meador Inge added the comment:
This seems to be a useful feature to me. Another area where it can help
is with fixing function types. Currently the qualname can be lost:
>>> def f():
...def g():
... pass
...return g
...
>>> g = f()
>>
Meador Inge added the comment:
On Wed, Dec 28, 2011 at 3:11 PM, Eric Snow wrote:
> One sticky point is that there isn't a guarantee of one-to-one between
> function object and code object. A code object could be bound to several
> different functions as happens with functi
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13840>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13814>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
'PyStopIteration_Create' is just a trivial wrapper:
PyObject *
PyStopIteration_Create(PyObject *value)
{
return PyObject_CallFunctionObjArgs(PyExc_StopIteration, value, NULL);
}
It is not needed.
As for 'PyGen_FetchStopIterationValue',
Meador Inge added the comment:
Fixed. Thanks for the report Stefan.
--
nosy: +meador.inge
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Meador Inge :
--
keywords: +easy
stage: -> needs patch
versions: -Python 3.1
___
Python tracker
<http://bugs.python.org/issue12949>
___
___
Python-
Meador Inge added the comment:
Fixed in 3.3.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
Fixed. Thanks for the reviews everyone.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Meador Inge added the comment:
On Tue, Jan 17, 2012 at 10:56 AM, Éric Araujo wrote:
> I don’t understand why some two-liners are allowed (like "class X:\n pass").
> The doc says “a single interactive statement”.
Because a single statement can be multiple lines (as is the c
201 - 300 of 629 matches
Mail list logo
