Python-Dev November 2011

python-dev@python.org

73 participants
75 discussions

by Derek Shockey

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 104857600000000000000000000L >>> 10**20 7766279631452241920 >>> 10L**20L 100000000000000000000L 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

9 years, 5 months

Buildbot failures

by Antoine Pitrou

Hello, There are currently a bunch of various buildbot failures on all 3 branches. I would remind committers to regularly take a look at the buildbots, so that these failures get solved reasonably fast. Regards Antoine.

9 years, 5 months

Unexpected behaviour in compileall

by 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 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

9 years, 5 months

PEP 397 and idle

by David Bailey

python-dev I am being forced to support multiple versions of python on Windows platforms. I have been using PEP 397 and the execution of *.py files works great. Thank you!! My problem is idle. The various versions of idle have the same problem as the various versions of python. We were using an editor that allowed python selection, however, they stopped supporting python and we are back using idle. Any suggestions on switching versions of idle would be appreciated. Thanks Dave Bailey

9 years, 5 months

Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit

by Eric V. Smith

What's the logic for adding some braces, but removing others? On 10/19/2011 4:58 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9c79a25f4a8b > changeset: 73010:9c79a25f4a8b > branch: 3.2 > parent: 72998:99a9f0251924 > user: Benjamin Peterson <benjamin(a)python.org> > date: Wed Oct 19 16:57:40 2011 -0400 > summary: > adjust braces a bit > > files: > Objects/genobject.c | 9 ++++----- > 1 files changed, 4 insertions(+), 5 deletions(-) > > > diff --git a/Objects/genobject.c b/Objects/genobject.c > --- a/Objects/genobject.c > +++ b/Objects/genobject.c > @@ -232,8 +232,9 @@ > > /* First, check the traceback argument, replacing None with > NULL. */ > - if (tb == Py_None) > + if (tb == Py_None) { > tb = NULL; > + } > else if (tb != NULL && !PyTraceBack_Check(tb)) { > PyErr_SetString(PyExc_TypeError, > "throw() third argument must be a traceback object"); > @@ -244,9 +245,8 @@ > Py_XINCREF(val); > Py_XINCREF(tb); > > - if (PyExceptionClass_Check(typ)) { > + if (PyExceptionClass_Check(typ)) > PyErr_NormalizeException(&typ, &val, &tb); > - } > > else if (PyExceptionInstance_Check(typ)) { > /* Raising an instance. The value should be a dummy. */ > @@ -262,10 +262,9 @@ > typ = PyExceptionInstance_Class(typ); > Py_INCREF(typ); > > - if (tb == NULL) { > + if (tb == NULL) > /* Returns NULL if there's no traceback */ > tb = PyException_GetTraceback(val); > - } > } > } > else { > > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins

9 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev November 2011