[Python-Dev] Unexpected behaviour in compileall
I just started getting errors in my PEP 404 / pythonv branch, but they don't at first glance appear related to the functionality of this branch. What I'm seeing is that during installation, some of the .pyc/.pyo files written by compileall have mode 600 rather than the expected 644, with the result that test_compileall fails when run from the installed Python as an unprivileged user. If I manually do sudo chmod a+r /usr/local/lib/python3.3/__pycache__/* then test_compileall works again. I added a diagnostic to compileall.py, here's an extract from the log of the subsequent installation: Listing '/usr/local/lib/python3.3'... Compiling '/usr/local/lib/python3.3/__future__.py'... Mode of [...]/__pycache__/__future__.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/__phello__.foo.py'... Mode of [...]/__pycache__/__phello__.foo.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_compat_pickle.py'... Mode of [...]/__pycache__/_compat_pickle.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_dummy_thread.py'... Mode of [...]/__pycache__/_dummy_thread.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_markupbase.py'... Mode of [...]/__pycache__/_markupbase.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_pyio.py'... Mode of [...]/__pycache__/_pyio.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_strptime.py'... Mode of [...]/__pycache__/_strptime.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_sysconfigdata.py'... Mode of [...]/__pycache__/_sysconfigdata.cpython-33.pyc is 600 Compiling '/usr/local/lib/python3.3/_threading_local.py'... Mode of [...]/__pycache__/_threading_local.cpython-33.pyc is 644 Compiling '/usr/local/lib/python3.3/_weakrefset.py'... Mode of [...]/__pycache__/_weakrefset.cpython-33.pyc is 600 Compiling '/usr/local/lib/python3.3/abc.py'... Mode of [...]/__pycache__/abc.cpython-33.pyc is 600 Compiling '/usr/local/lib/python3.3/aifc.py'... Mode of [...]/__pycache__/aifc.cpython-33.pyc is 644 The 600s and 644s are interspersed with no pattern immediately apparent. All the source files have mode 644, as expected. This happens on two different Posix machines - Ubuntu Natty and OS X Leopard - so doesn't seem to be related to the external environment. Can anyone shed any light as to what might be going on? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unexpected behaviour in compileall
2011/11/2 Vinay Sajip : > I just started getting errors in my PEP 404 / pythonv branch, but they don't > at first glance appear related to the functionality of this branch. What I'm > seeing is that during installation, some of the .pyc/.pyo files written by > compileall have mode 600 rather than the expected 644, with the result that > test_compileall fails when run from the installed Python as an unprivileged > user. If I manually do It's a consequence of http://hg.python.org/cpython/rev/740baff4f169. I'll fix that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unexpected behaviour in compileall
Charles-François Natali free.fr> writes: > It's a consequence of http://hg.python.org/cpython/rev/740baff4f169. > I'll fix that. Should a new issue be opened (or #13303 re-opened) pending this fix? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unexpected behaviour in compileall
On Wed, Nov 2, 2011 at 09:13, Vinay Sajip wrote: > Charles-François Natali free.fr> writes: > > > It's a consequence of http://hg.python.org/cpython/rev/740baff4f169. > > I'll fix that. > > Should a new issue be opened (or #13303 re-opened) pending this fix? > Re-open the issue. > > Regards, > > Vinay Sajip > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code cleanups in stable branches?
On Nov 1, 2011, at 1:31 PM, Barry Warsaw wrote: > On Oct 31, 2011, at 06:23 PM, Éric Araujo wrote: > >> I thought that patches that clean up code but don’t fix actual bugs were >> not done in stable branches. Has this changed? > > I hope not. Sure, if they fix actual bugs, that's fine, but as MvL often > points out, even innocent looking changes can break code *somewhere*. We > don't lose by being conservative with our stable branches. > > -Barry I concur with Barry and MvL. Random code cleanups increase the risk of introducing new bugs. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ints not overflowing into longs?
I just found an unexpected behavior and I'm wondering if it is a bug. In my 2.7.2 interpreter on OS X, built and installed via MacPorts, it appears that integers are not correctly overflowing into longs and instead are yielding bizarre results. I can only reproduce this when using the exponent operator with two ints (declaring either operand explicitly as long prevents the behavior). >>> 2**100 0 >>> 2**100L 1267650600228229401496703205376L >>> 20**20 -2101438300051996672 >>> 20L**20 1048576L >>> 10**20 7766279631452241920 >>> 10L**20L 1L To confirm I'm not crazy, I tried in the 2.7.1 and 2.6.7 installations included in OS X 10.7, and also a 2.7.2+ (not sure what the + is) on an Ubuntu machine and didn't see this behavior. This looks like some kind of truncation error, but I don't know much about the internals of Python and have no idea what's going on. I assume since it's only in my MacPorts installation, it must be build configuration issue that is specific to OS X, perhaps only 10.7, or MacPorts. Am I doing something wrong, and is there a way to fix it before I compile? I could find any references to this problem as a known issue. Thanks, Derek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ints not overflowing into longs?
Apparently Macports is still using a buggy compiler. I reported a similar issue before and got this reply from Ned Delly: """ Thanks for the pointer. That looks like a duplicate of Issue11149 (and Issue12701). Another manifestation of this was reported in Issue13061 which also originated from MacPorts. I'll remind them that the configure change is likely needed for all Pythons. It's still safest to stick with good old gcc-4.2 on OS X at the moment. """ (Those issues are on bugs.python.org.) --Guido On Wed, Nov 2, 2011 at 7:32 PM, Derek Shockey wrote: > I just found an unexpected behavior and I'm wondering if it is a bug. > In my 2.7.2 interpreter on OS X, built and installed via MacPorts, it > appears that integers are not correctly overflowing into longs and > instead are yielding bizarre results. I can only reproduce this when > using the exponent operator with two ints (declaring either operand > explicitly as long prevents the behavior). > 2**100 > 0 2**100L > 1267650600228229401496703205376L > 20**20 > -2101438300051996672 20L**20 > 1048576L > 10**20 > 7766279631452241920 10L**20L > 1L > > To confirm I'm not crazy, I tried in the 2.7.1 and 2.6.7 installations > included in OS X 10.7, and also a 2.7.2+ (not sure what the + is) on > an Ubuntu machine and didn't see this behavior. This looks like some > kind of truncation error, but I don't know much about the internals of > Python and have no idea what's going on. I assume since it's only in > my MacPorts installation, it must be build configuration issue that is > specific to OS X, perhaps only 10.7, or MacPorts. > > Am I doing something wrong, and is there a way to fix it before I > compile? I could find any references to this problem as a known issue. > > Thanks, > Derek > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ints not overflowing into longs?
Thank you, I narrowed it down from there and got a properly working build. I gather the problem is that in Xcode 4.2 the default compiler was changed to clang, but the version of clang bundled with it has a bug that breaks overflows in intobject.c. In case anyone else hits this, I fixed this in MacPorts by forcing it to use gcc. Edit the portfile (port edit python27) and add this anywhere after the 5th or so line: configure.compiler llvm-gcc-4 -Derek On Wed, Nov 2, 2011 at 7:41 PM, Guido van Rossum wrote: > Apparently Macports is still using a buggy compiler. I reported a > similar issue before and got this reply from Ned Delly: > > """ > Thanks for the pointer. That looks like a duplicate of Issue11149 (and > Issue12701). Another manifestation of this was reported in Issue13061 > which also originated from MacPorts. I'll remind them that the > configure change is likely needed for all Pythons. It's still safest to > stick with good old gcc-4.2 on OS X at the moment. > """ > > (Those issues are on bugs.python.org.) > > --Guido > > On Wed, Nov 2, 2011 at 7:32 PM, Derek Shockey wrote: >> I just found an unexpected behavior and I'm wondering if it is a bug. >> In my 2.7.2 interpreter on OS X, built and installed via MacPorts, it >> appears that integers are not correctly overflowing into longs and >> instead are yielding bizarre results. I can only reproduce this when >> using the exponent operator with two ints (declaring either operand >> explicitly as long prevents the behavior). >> > 2**100 >> 0 > 2**100L >> 1267650600228229401496703205376L >> > 20**20 >> -2101438300051996672 > 20L**20 >> 1048576L >> > 10**20 >> 7766279631452241920 > 10L**20L >> 1L >> >> To confirm I'm not crazy, I tried in the 2.7.1 and 2.6.7 installations >> included in OS X 10.7, and also a 2.7.2+ (not sure what the + is) on >> an Ubuntu machine and didn't see this behavior. This looks like some >> kind of truncation error, but I don't know much about the internals of >> Python and have no idea what's going on. I assume since it's only in >> my MacPorts installation, it must be build configuration issue that is >> specific to OS X, perhaps only 10.7, or MacPorts. >> >> Am I doing something wrong, and is there a way to fix it before I >> compile? I could find any references to this problem as a known issue. >> >> Thanks, >> Derek >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
