Meador Inge mead...@gmail.com added the comment:
Whoops. Nick, I missed that this was assigned to you when I committed a fix.
Sorry about that.
--
nosy: +meador.inge
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - behavior
versions: +Python 3.3
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15381
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
The general wording and example look good; thanks. I reworded things a
little. Updated patch attached.
--
stage: needs patch - commit review
Added file: http://bugs.python.org/file26443/issue14201-v2.patch
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com added the comment:
I can commit today unless you think we need someone else to independently
verify the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15368
Meador Inge mead...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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 rep
Meador Inge mead...@gmail.com added the comment:
D'oh! Thanks for catching that Serhiy! Fixing now. Sorry about that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15368
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14596
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6493
Meador Inge mead...@gmail.com 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 rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
On Mon, Jul 16, 2012 at 5:20 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Anyway, I am hitting another problem now -- _freeze_importlib is *not*
idempotent.
What do you mean with idempotent? Deterministic?
Whoops, yeah, deterministic
New submission from Meador Inge mead...@gmail.com:
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__
Meador Inge mead...@gmail.com added the comment:
On Mon, Jul 16, 2012 at 7:13 AM, Antoine Pitrou rep...@bugs.python.org 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
Meador Inge mead...@gmail.com added the comment:
On Mon, Jul 16, 2012 at 8:11 AM, Brett Cannon rep...@bugs.python.org 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
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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
New submission from Meador Inge mead...@gmail.com:
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
Meador Inge mead...@gmail.com added the comment:
Patch attached.
--
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file26382/issue15352-v0.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com 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 mead...@gmail.com 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
Meador Inge mead...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue12142
Meador Inge mead...@gmail.com added the comment:
Stefan, nope -- I never got a reply. I will try again.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12927
Meador Inge mead...@gmail.com added the comment:
At a guess, BITS.M should therefore look like Field type=c_int,
ofs=0:17, bits=1 instead.
Refined guess: it should be Field type=c_short, ofs=2:1, bits=1.
This refined guess seems reasonable. Although, bitfield allocation order for
GCC
Changes by Meador Inge mead...@gmail.com:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15119
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
Thanks for digging into this Mark. I will have a look too later in the day.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15119
Meador Inge mead...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue15054
Meador Inge mead...@gmail.com added the comment:
Nevermind, the tests are OK. I missed the swapped quotes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15054
Meador Inge mead...@gmail.com added the comment:
Python 2 patch looks OK too. I will commit these later today. Thanks for the
patches!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15054
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15054
Meador Inge mead...@gmail.com 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 given file (the Python
Meador Inge mead...@gmail.com 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. Whichever
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14805
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14956
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9041
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14928
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12370
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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 mead...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14757
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
On Mon, May 14, 2012 at 12:31 PM, Serhiy Storchaka
rep...@bugs.python.org wrote:
Serhiy Storchaka storch...@gmail.com added the comment:
This is definitely *not* a padding issue.
This is definitely a padding issue. All uncompressed files
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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 mead...@gmail.com 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.
Is that note not sufficient
Changes by Meador Inge mead...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14765
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14701
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8212
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4130
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12864
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14373
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
LLVM/clang bug report here: http://llvm.org/bugs/show_bug.cgi?id=12207.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13370
Meador Inge mead...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14195
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14189
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14184
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13951
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14181
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14169
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14095
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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 = {'__qualname__':'XXX'}
[66934 refs]
T = type('foo', (), d
Meador Inge mead...@gmail.com added the comment:
haypo, I can reproduce the segfault using the 'None' test case on your patch as
well.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14095
Meador Inge mead...@gmail.com 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-file=leaks.txt
Meador Inge mead...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13959
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13977
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13970
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13938
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13979
Changes by Meador Inge mead...@gmail.com:
--
type: behavior - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6259
___
___
Python-bugs
Meador Inge mead...@gmail.com 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('d', big_int)
Traceback
Meador Inge mead...@gmail.com 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:
for libname in ['uuid', 'c
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com added the comment:
I can reproduce it without --with-pydebug. Thanks. I will investigate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13370
Meador Inge mead...@gmail.com 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 mead...@gmail.com 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 do with sign
extension
Meador Inge mead...@gmail.com 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
Meador Inge mead...@gmail.com 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 - closed
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13840
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
On Wed, Dec 28, 2011 at 3:11 PM, Eric Snow rep...@bugs.python.org 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
Meador Inge mead...@gmail.com 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()
g
function f.locals.g
New submission from Meador Inge mead...@gmail.com:
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
function f.locals.g at 0x7f1dac4d8ba0
types.FunctionType(f.__code__
Meador Inge mead...@gmail.com 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_unicode_buffer(b'foo')
Traceback (most recent call
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13814
___
___
Python-bugs-list
Meador Inge mead...@gmail.com 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', does
Changes by Meador Inge mead...@gmail.com:
--
keywords: +easy
stage: - needs patch
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12949
Meador Inge mead...@gmail.com added the comment:
Fixed. Thanks for the report Stefan.
--
nosy: +meador.inge
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
Fixed. Thanks for the reviews everyone.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
Fixed in 3.3.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12705
Meador Inge mead...@gmail.com added the comment:
The attached patch fixes this be checking what is left in the input
buffer after parsing. Anything but trailing whitespace and comments
triggers the exception.
Ignoring trailing whitespace and comments makes sense, but it is also
somewhat
Meador Inge mead...@gmail.com added the comment:
On Tue, Jan 17, 2012 at 10:56 AM, Éric Araujo rep...@bugs.python.org 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
201 - 300 of 625 matches
Mail list logo
