Re: [Python-Dev] Building a Faster Python
On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: > On Sun, 21 Jul 2013 16:36:35 -0700 > Raymond Hettinger wrote: >> Our current Mac OS X builds use GCC-4.2. >> >> On Python2.7, I ran a comparison of gcc-4.2.1 builds >> versus gcc-4.8.1 and found that the latter makes a much >> faster Python. PyBench2.0 shows the total running time >> dropping from 5653ms to 4571ms. The code is uniformly >> better in just about every category. > > You could try running the benchmarks suite to see what that gives: > http://hg.python.org/benchmarks/ > > Regards > > Antoine. or pypy benchmark suite which is more comprehensive for python 2.7 (http://bitbucket.org/pypy/benchmarks) ___ 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] Building a Faster Python
On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote: > On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: >> On Sun, 21 Jul 2013 16:36:35 -0700 >> Raymond Hettinger wrote: >>> Our current Mac OS X builds use GCC-4.2. >>> >>> On Python2.7, I ran a comparison of gcc-4.2.1 builds >>> versus gcc-4.8.1 and found that the latter makes a much >>> faster Python. PyBench2.0 shows the total running time >>> dropping from 5653ms to 4571ms. The code is uniformly >>> better in just about every category. >> >> You could try running the benchmarks suite to see what that gives: >> http://hg.python.org/benchmarks/ >> >> Regards >> >> Antoine. > > or pypy benchmark suite which is more comprehensive for python 2.7 > (http://bitbucket.org/pypy/benchmarks) Besides, is there any reason not to use clang by default on OS X? ___ 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] dict __contains__ raises TypeError on unhashable input
Thanks for the insights, everyone. -- ~Ethan~ ___ 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] Building a Faster Python
On 22 Jul, 2013, at 9:32, Maciej Fijalkowski wrote: > On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote: >> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: >>> On Sun, 21 Jul 2013 16:36:35 -0700 >>> Raymond Hettinger wrote: Our current Mac OS X builds use GCC-4.2. On Python2.7, I ran a comparison of gcc-4.2.1 builds versus gcc-4.8.1 and found that the latter makes a much faster Python. PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. The code is uniformly better in just about every category. >>> >>> You could try running the benchmarks suite to see what that gives: >>> http://hg.python.org/benchmarks/ >>> >>> Regards >>> >>> Antoine. >> >> or pypy benchmark suite which is more comprehensive for python 2.7 >> (http://bitbucket.org/pypy/benchmarks) > > Besides, is there any reason not to use clang by default on OS X? The 32-bit installer contains binaries that work on PPC, that's why those are built using an older version of Xcode. I'd have to check if that version of Xcode supports clang, and if that version of clang is good enough. The "intel" installer can, and should, be build with clang (and preferably with the most recent Xcode release to ensure that the latest supported compiler is used). Note that the CPython configure script, and distutils, already use clang by default if you a recent Xcode but that's primarily because gcc is llvm-gcc when you use Xcode and llvm-gcc is broken (it miscompiles at least the unicode implementation in Python 3.3), this overrides the default behavior of configure (using gcc whenever it is available unless the user explictly overrides). Ronald ___ 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] Building a Faster Python
Quoting Steve Dower : As a Windows user, it makes me wonder if compiling with the latest version of the Microsoft compiler would improve things similarly? I'd expect to see some improvement, based solely on the bugs fixed recently by the optimizer team. No idea how much, but I know that Martin builds with PGO, and that's also been improved recently. I would not expect to see any improvement, unfortunately. I used to build with PGO, but the recent VS releases miscompiled code, which was very hard to track down. So PGO has lost in my view for at least 3 VS releases :-( (Though updating project files to that is almost certainly a bigger project than the gcc update.) No idea what the gcc update involved, but this is only accurate if it took less than two minutes :-) I've upgraded the CPython projects before and everything worked fine. Still, we couldn't release 2.7 with any other compiler because of the CRT dependency. Regards, Martin ___ 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] Dash
I have opened an issue (http://bugs.python.org/issue18529) for patches. ___ 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] [Python-checkins] cpython (3.3): let's not return NULL from functions that should return ints
Yes, I meant to remove it. This function gnores errors in general. 2013/7/22 Eric V. Smith : > [re-sending to python-dev] > > On 7/21/2013 4:27 PM, benjamin.peterson wrote: > >> @@ -267,7 +267,7 @@ >> Py_DECREF(io); >> Py_DECREF(binary); >> PyMem_FREE(found_encoding); >> -return PyErr_SetFromErrnoWithFilenameObject(PyExc_IOError, >> filename); >> +return 0; >> } >> fob = _PyObject_CallMethodId(io, &PyId_TextIOWrapper, "Os", binary, >> encoding); >> Py_DECREF(io); > > Did you mean to remove the call to PyErr_SetFromErrnoWithFilenameObject? > Or just call it, then ignore its return value and return 0? > > > -- > Eric. > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins > > ___ > 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/benjamin%40python.org -- Regards, Benjamin ___ 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] Building a Faster Python
On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote: > On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote: > > On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: > >> On Sun, 21 Jul 2013 16:36:35 -0700 > >> Raymond Hettinger wrote: > >>> Our current Mac OS X builds use GCC-4.2. > >>> > >>> On Python2.7, I ran a comparison of gcc-4.2.1 builds > >>> versus gcc-4.8.1 and found that the latter makes a much > >>> faster Python. PyBench2.0 shows the total running time > >>> dropping from 5653ms to 4571ms. The code is uniformly > >>> better in just about every category. > >> > >> You could try running the benchmarks suite to see what that gives: > >> http://hg.python.org/benchmarks/ > >> > >> Regards > >> > >> Antoine. > > > > or pypy benchmark suite which is more comprehensive for python 2.7 > > (http://bitbucket.org/pypy/benchmarks) > > Besides, is there any reason not to use clang by default on OS X? How did this thread go from: "for OS X, GCC 4.8.1 gives you significantly faster machine code than the system GCC 4.2.1" to "let's just use clang" ? Presumably if you want the faster possible machine code for the platform the correct approach is to benchmark the available compilers trying various options and to see which does best. Note that the meaning of e.g. "-O3" varies from compiler to compiler (I see someone else already made the Apples-to-Apples pun). (I should declare that I've been hacking on GCC for the last few months, so I have an interest in this) Hope this is constructive Dave ___ 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] Building a Faster Python
On Mon, 2013-07-22 at 17:15 +0200, Antoine Pitrou wrote: > Le Mon, 22 Jul 2013 11:08:32 -0400, > David Malcolm a écrit : > > > > How did this thread go from: > > "for OS X, GCC 4.8.1 gives you significantly faster machine code > >than the system GCC 4.2.1" > > to > > "let's just use clang" > > ? > > > > Presumably if you want the faster possible machine code for the > > platform the correct approach is to benchmark the available compilers > > trying various options and to see which does best. > > Depends whether the goal is to choose the fastest compiler, or to > use the platform's official compiler. Linux distributions don't compile > packages with icc, AFAIK. If Intel put icc under a Free Software/Open Source license, maybe we would ;-) (only my own opinion, of course) Dave ___ 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] Building a Faster Python
On 22 Jul, 2013, at 17:08, David Malcolm wrote: > On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote: >> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote: >>> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: On Sun, 21 Jul 2013 16:36:35 -0700 Raymond Hettinger wrote: > Our current Mac OS X builds use GCC-4.2. > > On Python2.7, I ran a comparison of gcc-4.2.1 builds > versus gcc-4.8.1 and found that the latter makes a much > faster Python. PyBench2.0 shows the total running time > dropping from 5653ms to 4571ms. The code is uniformly > better in just about every category. You could try running the benchmarks suite to see what that gives: http://hg.python.org/benchmarks/ Regards Antoine. >>> >>> or pypy benchmark suite which is more comprehensive for python 2.7 >>> (http://bitbucket.org/pypy/benchmarks) >> >> Besides, is there any reason not to use clang by default on OS X? > > How did this thread go from: > "for OS X, GCC 4.8.1 gives you significantly faster machine code > than the system GCC 4.2.1" > to > "let's just use clang" > ? Because we use the system compiler for building the official binary packages. I'm not looking forward to bootstrapping GCC multiple times[*] just to be able to build a slightly faster python. And more so because you have to be very careful when using a alternative compiler when building the installer, it is very easy to end up with a build that others cannot use to build extension because they don't have /Users/ronald/Tools/Compiler/gcc-4.8/bin/gcc. > > (I should declare that I've been hacking on GCC for the last few months, > so I have an interest in this) It would still be interesting to know which compiler would generate the fastest code for CPython. Apple tends to claim that clang generates better code than GCC, buit AFAIK they compare the latest clang with the latest version of GCC that they used to ship, which is ancient by now. Ronald [*] multiple times due to fat binaries. ___ 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] Building a Faster Python
Le Mon, 22 Jul 2013 11:08:32 -0400, David Malcolm a écrit : > > How did this thread go from: > "for OS X, GCC 4.8.1 gives you significantly faster machine code >than the system GCC 4.2.1" > to > "let's just use clang" > ? > > Presumably if you want the faster possible machine code for the > platform the correct approach is to benchmark the available compilers > trying various options and to see which does best. Depends whether the goal is to choose the fastest compiler, or to use the platform's official compiler. Linux distributions don't compile packages with icc, AFAIK. Regards Antoine. ___ 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] [Python-checkins] cpython (3.3): let's not return NULL from functions that should return ints
[re-sending to python-dev] On 7/21/2013 4:27 PM, benjamin.peterson wrote: > @@ -267,7 +267,7 @@ > Py_DECREF(io); > Py_DECREF(binary); > PyMem_FREE(found_encoding); > -return PyErr_SetFromErrnoWithFilenameObject(PyExc_IOError, filename); > +return 0; > } > fob = _PyObject_CallMethodId(io, &PyId_TextIOWrapper, "Os", binary, > encoding); > Py_DECREF(io); Did you mean to remove the call to PyErr_SetFromErrnoWithFilenameObject? Or just call it, then ignore its return value and return 0? -- Eric. ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins ___ 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] Avoiding error from repr() of recursive dictview
Hi,
A friend of mine, Ruadhan O'Flanagan, came across a bug which turned out
to be the one noted in [http://bugs.python.org/issue18019], i.e.:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d
This issue has been fixed in hg; the behaviour now is that a
RuntimeError is produced for a recursive dictionary view:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d # (output line-broken:)
{42: Traceback (most recent call last):
File "", line 1, in
RuntimeError: maximum recursion depth exceeded
while getting the repr of a list
Before finding this, though, I'd investigated and made a patch which
produces a similar "..." output to a recursive dictionary. Reworking
against current 2.7, the behaviour would be:
>>> x={}
>>> x[42]=x
>>> x # existing behaviour for dictionaries:
{42: {...}}
>>> d={}
>>> d[42]=d.viewvalues()
>>> d # new behaviour:
{42: dict_values([...])}
>>> d[43]=d.viewitems()
>>> d # (output line-broken:)
{42: dict_values([..., dict_items([(42, ...), (43, ...)])]),
43: dict_items([(42, dict_values([..., ...])), (43, ...)])}
Attached is the patch, against current 2.7 branch. If there is interest
in applying this, I will create a proper patch (changelog entry, fix to
Lib/test/test_dictviews.py, etc.).
Thanks,
Ben.
non-error-recursive-dictview.patch
Description: Binary data
___
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] Avoiding error from repr() of recursive dictview
On Mon, Jul 22, 2013 at 2:44 PM, Ben North wrote:
> Hi,
>
> A friend of mine, Ruadhan O'Flanagan, came across a bug which turned out
> to be the one noted in [http://bugs.python.org/issue18019], i.e.:
>
> >>> d={}
> >>> d[42]=d.viewvalues()
> >>> d
>
>
> This issue has been fixed in hg; the behaviour now is that a
> RuntimeError is produced for a recursive dictionary view:
>
> >>> d={}
> >>> d[42]=d.viewvalues()
> >>> d # (output line-broken:)
> {42: Traceback (most recent call last):
> File "", line 1, in
> RuntimeError: maximum recursion depth exceeded
> while getting the repr of a list
>
> Before finding this, though, I'd investigated and made a patch which
> produces a similar "..." output to a recursive dictionary. Reworking
> against current 2.7, the behaviour would be:
>
> >>> x={}
> >>> x[42]=x
> >>> x # existing behaviour for dictionaries:
> {42: {...}}
>
> >>> d={}
> >>> d[42]=d.viewvalues()
> >>> d # new behaviour:
> {42: dict_values([...])}
> >>> d[43]=d.viewitems()
> >>> d # (output line-broken:)
> {42: dict_values([..., dict_items([(42, ...), (43, ...)])]),
> 43: dict_items([(42, dict_values([..., ...])), (43, ...)])}
>
> Attached is the patch, against current 2.7 branch. If there is interest
> in applying this, I will create a proper patch (changelog entry, fix to
> Lib/test/test_dictviews.py, etc.).
>
Mailing lists are where patches go to get lost and die. :) Post it on an
issue on bugs.python.org. Given that the RuntimeError fix has been
released, your proposed ... behavior is arguably a new feature so I'd only
expect this to make sense for consideration in 3.4, not 2.7. (if accepted
at all)
-gps
>
> Thanks,
>
> Ben.
>
> ___
> 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/greg%40krypto.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] Avoiding error from repr() of recursive dictview
23.07.2013 00:01, Gregory P. Smith wrote:
On Mon, Jul 22, 2013 at 2:44 PM, Ben North
wrote:
A friend of mine, Ruadhan O'Flanagan, came across a bug which turned
out
to be the one noted in [http://bugs.python.org/issue18019 [1]],
i.e.:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d
This issue has been fixed in hg; the behaviour now is that a
RuntimeError is produced for a recursive dictionary view:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d # (output line-broken:)
{42: Traceback (most recent call last):
File "", line 1, in
RuntimeError: maximum recursion depth exceeded
while getting the repr of a list
Before finding this, though, I'd investigated and made a patch which
produces a similar "..." output to a recursive dictionary.
Reworking
against current 2.7, the behaviour would be:
>>> x={}
>>> x[42]=x
>>> x # existing behaviour for dictionaries:
{42: {...}}
>>> d={}
>>> d[42]=d.viewvalues()
>>> d # new behaviour:
{42: dict_values([...])}
>>> d[43]=d.viewitems()
>>> d # (output line-broken:)
{42: dict_values([..., dict_items([(42, ...), (43, ...)])]),
43: dict_items([(42, dict_values([..., ...])), (43, ...)])}
Attached is the patch, against current 2.7 branch. If there is
interest
in applying this, I will create a proper patch (changelog entry, fix
to
Lib/test/test_dictviews.py, etc.).
Mailing lists are where patches go to get lost and die. :) Post it
on an issue on bugs.python.org [4]. Given that the RuntimeError fix
has been released, your proposed ... behavior is arguably a new
feature so I'd only expect this to make sense for consideration in
3.4, not 2.7. (if accepted at all)
IMHO it's still a bug (even though not so painful as segfault) that
should also be fixed in 2.7 and 3.2/3.3.
In other cases (such as `d={}; d[42]=d; repr(d)`) Python does its best
to avoid an error -- why in this case (`d={};
d[42]=d.values(); repr(d)`) should it raise an exception?
IMHO it's an obvious oversight in implementation, not a feature that
anybody would expect.
Regards.
*j
___
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] Avoiding error from repr() of recursive dictview
Hi Greg, Thanks for the feedback. On 22 July 2013 23:01, Gregory P. Smith wrote: > On Mon, Jul 22, 2013 at 2:44 PM, Ben North wrote: >> [... proposed change of behaviour such that a recursive >> dictview gives a repr() with "..." rather than a RuntimeError ...] > > [...] Post it on an issue on bugs.python.org. http://bugs.python.org/issue18533 Ben. ___ 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] [Python-checkins] cpython: Fix #18530. Remove extra stat call from posixpath.ismount
Could you please keep the comment "# A symlink can never be a mount point" ? It is useful. (I didn't know that, I'm not a windows developer.) Victor Le 22 juil. 2013 20:08, "brian.curtin" a écrit : > http://hg.python.org/cpython/rev/240adc564539 > changeset: 84791:240adc564539 > parent: 84788:84d6c1c0665e > user:Brian Curtin > date:Mon Jul 22 13:07:52 2013 -0500 > summary: > Fix #18530. Remove extra stat call from posixpath.ismount > > files: > Lib/posixpath.py | 22 ++ > Misc/NEWS| 3 +++ > 2 files changed, 17 insertions(+), 8 deletions(-) > > > diff --git a/Lib/posixpath.py b/Lib/posixpath.py > --- a/Lib/posixpath.py > +++ b/Lib/posixpath.py > @@ -182,18 +182,24 @@ > > def ismount(path): > """Test whether a path is a mount point""" > -if islink(path): > -# A symlink can never be a mount point > -return False > try: > s1 = os.lstat(path) > -if isinstance(path, bytes): > -parent = join(path, b'..') > -else: > -parent = join(path, '..') > +except OSError: > +# It doesn't exist -- so not a mount point. :-) > +return False > +else: > +if stat.S_ISLNK(s1.st_mode): > +return False > + > +if isinstance(path, bytes): > +parent = join(path, b'..') > +else: > +parent = join(path, '..') > +try: > s2 = os.lstat(parent) > except OSError: > -return False # It doesn't exist -- so not a mount point :-) > +return False > + > dev1 = s1.st_dev > dev2 = s2.st_dev > if dev1 != dev2: > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -162,6 +162,9 @@ > Library > --- > > +- Issue #18530: Remove additional stat call from posixpath.ismount. > + Patch by Alex Gaynor. > + > - Issue #18514: Fix unreachable Py_DECREF() call in PyCData_FromBaseObj() > > - Issue #9177: Calling read() or write() now raises ValueError, not > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins > > ___ 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] [Python-checkins] cpython: Issue #18520: Add a new PyStructSequence_InitType2() function, same than
"Add a new PyStructSequence_InitType2()"
I added a new function because I guess that it would break the API (and
ABI) to change the return type of a function in a minor release.
Tell me if you have a better name than PyStructSequence_InitType2() ;-)
"Ex" suffix is usually used when parameters are added. It is not the case
here.
Victor
Le 22 juil. 2013 23:59, "victor.stinner" a
écrit :
> http://hg.python.org/cpython/rev/fc718c177ee6
> changeset: 84793:fc718c177ee6
> user:Victor Stinner
> date:Mon Jul 22 22:24:54 2013 +0200
> summary:
> Issue #18520: Add a new PyStructSequence_InitType2() function, same than
> PyStructSequence_InitType() except that it has a return value (0 on
> success,
> -1 on error).
>
> * PyStructSequence_InitType2() now raises MemoryError on memory
> allocation failure
> * Fix also some calls to PyDict_SetItemString(): handle error
>
> files:
> Include/pythonrun.h| 2 +-
> Include/structseq.h| 2 +
> Misc/NEWS | 4 +++
> Modules/_lsprof.c | 10 ---
> Modules/grpmodule.c| 11 ++--
> Modules/posixmodule.c | 24 --
> Modules/pwdmodule.c| 5 ++-
> Modules/resource.c | 9 --
> Modules/signalmodule.c | 7 +++--
> Modules/spwdmodule.c | 8 --
> Modules/timemodule.c | 5 ++-
> Objects/floatobject.c | 9 --
> Objects/longobject.c | 6 +++-
> Objects/structseq.c| 37 +
> Python/pythonrun.c | 3 +-
> Python/sysmodule.c | 23 -
> Python/thread.c| 6 +++-
> 17 files changed, 117 insertions(+), 54 deletions(-)
>
>
> diff --git a/Include/pythonrun.h b/Include/pythonrun.h
> --- a/Include/pythonrun.h
> +++ b/Include/pythonrun.h
> @@ -197,7 +197,7 @@
> PyAPI_FUNC(void) _PyExc_Init(PyObject * bltinmod);
> PyAPI_FUNC(void) _PyImportHooks_Init(void);
> PyAPI_FUNC(int) _PyFrame_Init(void);
> -PyAPI_FUNC(void) _PyFloat_Init(void);
> +PyAPI_FUNC(int) _PyFloat_Init(void);
> PyAPI_FUNC(int) PyByteArray_Init(void);
> PyAPI_FUNC(void) _PyRandom_Init(void);
> #endif
> diff --git a/Include/structseq.h b/Include/structseq.h
> --- a/Include/structseq.h
> +++ b/Include/structseq.h
> @@ -24,6 +24,8 @@
> #ifndef Py_LIMITED_API
> PyAPI_FUNC(void) PyStructSequence_InitType(PyTypeObject *type,
> PyStructSequence_Desc *desc);
> +PyAPI_FUNC(int) PyStructSequence_InitType2(PyTypeObject *type,
> + PyStructSequence_Desc *desc);
> #endif
> PyAPI_FUNC(PyTypeObject*) PyStructSequence_NewType(PyStructSequence_Desc
> *desc);
>
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -10,6 +10,10 @@
> Core and Builtins
> -
>
> +- Issue #18520: Add a new PyStructSequence_InitType2() function, same than
> + PyStructSequence_InitType() except that it has a return value (0 on
> success,
> + -1 on error).
> +
> - Issue #15905: Fix theoretical buffer overflow in handling of
> sys.argv[0],
>prefix and exec_prefix if the operation system does not obey MAXPATHLEN.
>
> diff --git a/Modules/_lsprof.c b/Modules/_lsprof.c
> --- a/Modules/_lsprof.c
> +++ b/Modules/_lsprof.c
> @@ -884,10 +884,12 @@
> PyDict_SetItemString(d, "Profiler", (PyObject *)&PyProfiler_Type);
>
> if (!initialized) {
> -PyStructSequence_InitType(&StatsEntryType,
> - &profiler_entry_desc);
> -PyStructSequence_InitType(&StatsSubEntryType,
> - &profiler_subentry_desc);
> +if (PyStructSequence_InitType2(&StatsEntryType,
> + &profiler_entry_desc) < 0)
> +return NULL;
> +if (PyStructSequence_InitType2(&StatsSubEntryType,
> + &profiler_subentry_desc) < 0)
> +return NULL;
> }
> Py_INCREF((PyObject*) &StatsEntryType);
> Py_INCREF((PyObject*) &StatsSubEntryType);
> diff --git a/Modules/grpmodule.c b/Modules/grpmodule.c
> --- a/Modules/grpmodule.c
> +++ b/Modules/grpmodule.c
> @@ -210,9 +210,14 @@
> if (m == NULL)
> return NULL;
> d = PyModule_GetDict(m);
> -if (!initialized)
> -PyStructSequence_InitType(&StructGrpType,
> &struct_group_type_desc);
> -PyDict_SetItemString(d, "struct_group", (PyObject *) &StructGrpType);
> +if (!initialized) {
> +if (PyStructSequence_InitType2(&StructGrpType,
> + &struct_group_type_desc) < 0)
> +return NULL;
> +}
> +if (PyDict_SetItemString(d, "struct_group",
> + (PyObject *)&StructGrpType) < 0)
> +return NULL;
> initialized = 1;
> return m;
> }
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -11518,19 +11518,23 @@
> if (!initialized) {
> #if d
Re: [Python-Dev] [Python-checkins] cpython: Issue #18520: Add a new PyStructSequence_InitType2() function, same than
We've cheerfully broken the ABI before on minor releases, though if
it's part of the stable ABI, we can't be cavaliar about that anymore.
2013/7/22 Victor Stinner :
> "Add a new PyStructSequence_InitType2()"
>
> I added a new function because I guess that it would break the API (and ABI)
> to change the return type of a function in a minor release.
>
> Tell me if you have a better name than PyStructSequence_InitType2() ;-)
>
> "Ex" suffix is usually used when parameters are added. It is not the case
> here.
>
> Victor
>
> Le 22 juil. 2013 23:59, "victor.stinner" a
> écrit :
>>
>> http://hg.python.org/cpython/rev/fc718c177ee6
>> changeset: 84793:fc718c177ee6
>> user:Victor Stinner
>> date:Mon Jul 22 22:24:54 2013 +0200
>> summary:
>> Issue #18520: Add a new PyStructSequence_InitType2() function, same than
>> PyStructSequence_InitType() except that it has a return value (0 on
>> success,
>> -1 on error).
>>
>> * PyStructSequence_InitType2() now raises MemoryError on memory
>> allocation failure
>> * Fix also some calls to PyDict_SetItemString(): handle error
>>
>> files:
>> Include/pythonrun.h| 2 +-
>> Include/structseq.h| 2 +
>> Misc/NEWS | 4 +++
>> Modules/_lsprof.c | 10 ---
>> Modules/grpmodule.c| 11 ++--
>> Modules/posixmodule.c | 24 --
>> Modules/pwdmodule.c| 5 ++-
>> Modules/resource.c | 9 --
>> Modules/signalmodule.c | 7 +++--
>> Modules/spwdmodule.c | 8 --
>> Modules/timemodule.c | 5 ++-
>> Objects/floatobject.c | 9 --
>> Objects/longobject.c | 6 +++-
>> Objects/structseq.c| 37 +
>> Python/pythonrun.c | 3 +-
>> Python/sysmodule.c | 23 -
>> Python/thread.c| 6 +++-
>> 17 files changed, 117 insertions(+), 54 deletions(-)
>>
>>
>> diff --git a/Include/pythonrun.h b/Include/pythonrun.h
>> --- a/Include/pythonrun.h
>> +++ b/Include/pythonrun.h
>> @@ -197,7 +197,7 @@
>> PyAPI_FUNC(void) _PyExc_Init(PyObject * bltinmod);
>> PyAPI_FUNC(void) _PyImportHooks_Init(void);
>> PyAPI_FUNC(int) _PyFrame_Init(void);
>> -PyAPI_FUNC(void) _PyFloat_Init(void);
>> +PyAPI_FUNC(int) _PyFloat_Init(void);
>> PyAPI_FUNC(int) PyByteArray_Init(void);
>> PyAPI_FUNC(void) _PyRandom_Init(void);
>> #endif
>> diff --git a/Include/structseq.h b/Include/structseq.h
>> --- a/Include/structseq.h
>> +++ b/Include/structseq.h
>> @@ -24,6 +24,8 @@
>> #ifndef Py_LIMITED_API
>> PyAPI_FUNC(void) PyStructSequence_InitType(PyTypeObject *type,
>> PyStructSequence_Desc *desc);
>> +PyAPI_FUNC(int) PyStructSequence_InitType2(PyTypeObject *type,
>> + PyStructSequence_Desc *desc);
>> #endif
>> PyAPI_FUNC(PyTypeObject*) PyStructSequence_NewType(PyStructSequence_Desc
>> *desc);
>>
>> diff --git a/Misc/NEWS b/Misc/NEWS
>> --- a/Misc/NEWS
>> +++ b/Misc/NEWS
>> @@ -10,6 +10,10 @@
>> Core and Builtins
>> -
>>
>> +- Issue #18520: Add a new PyStructSequence_InitType2() function, same
>> than
>> + PyStructSequence_InitType() except that it has a return value (0 on
>> success,
>> + -1 on error).
>> +
>> - Issue #15905: Fix theoretical buffer overflow in handling of
>> sys.argv[0],
>>prefix and exec_prefix if the operation system does not obey
>> MAXPATHLEN.
>>
>> diff --git a/Modules/_lsprof.c b/Modules/_lsprof.c
>> --- a/Modules/_lsprof.c
>> +++ b/Modules/_lsprof.c
>> @@ -884,10 +884,12 @@
>> PyDict_SetItemString(d, "Profiler", (PyObject *)&PyProfiler_Type);
>>
>> if (!initialized) {
>> -PyStructSequence_InitType(&StatsEntryType,
>> - &profiler_entry_desc);
>> -PyStructSequence_InitType(&StatsSubEntryType,
>> - &profiler_subentry_desc);
>> +if (PyStructSequence_InitType2(&StatsEntryType,
>> + &profiler_entry_desc) < 0)
>> +return NULL;
>> +if (PyStructSequence_InitType2(&StatsSubEntryType,
>> + &profiler_subentry_desc) < 0)
>> +return NULL;
>> }
>> Py_INCREF((PyObject*) &StatsEntryType);
>> Py_INCREF((PyObject*) &StatsSubEntryType);
>> diff --git a/Modules/grpmodule.c b/Modules/grpmodule.c
>> --- a/Modules/grpmodule.c
>> +++ b/Modules/grpmodule.c
>> @@ -210,9 +210,14 @@
>> if (m == NULL)
>> return NULL;
>> d = PyModule_GetDict(m);
>> -if (!initialized)
>> -PyStructSequence_InitType(&StructGrpType,
>> &struct_group_type_desc);
>> -PyDict_SetItemString(d, "struct_group", (PyObject *) &StructGrpType);
>> +if (!initialized) {
>> +if (PyStructSequence_InitType2(&StructGrpType,
>> + &struct_group_type_desc) < 0)
>> +return NULL;
>> +}
>> +if (PyDict_SetItemString(d, "struct_group",
>> +
Re: [Python-Dev] [Python-checkins] cpython: Fix #18530. Remove extra stat call from posixpath.ismount
On Mon, Jul 22, 2013 at 6:36 PM, Victor Stinner wrote: > Could you please keep the comment "# A symlink can never be a mount point" ? > It is useful. (I didn't know that, I'm not a windows developer.) I don't think that's specific to Windows, but I added it back in d6213012d87b. ___ 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] Building a Faster Python
Just a suggestion from working with an assembly language stepper from a while back with Intel x86...lost to an HD crash, but couldn't you disassemble the binary, run through the assembly, and look for specific instructions that you could refine into a simpler, smaller cycling time to improve upon with a stepper that counts cycles? I've seen other assembly steppers after I started mine for electrical engineering of PCB's, but I don't know if they're counting cycles, and suggesting other actions in an editor typ/optimization mode that the compiler might miss. On Mon, Jul 22, 2013 at 12:09 PM, Ronald Oussoren wrote: > > On 22 Jul, 2013, at 17:08, David Malcolm wrote: > > > On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote: > >> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski > wrote: > >>> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou > wrote: > On Sun, 21 Jul 2013 16:36:35 -0700 > Raymond Hettinger wrote: > > Our current Mac OS X builds use GCC-4.2. > > > > On Python2.7, I ran a comparison of gcc-4.2.1 builds > > versus gcc-4.8.1 and found that the latter makes a much > > faster Python. PyBench2.0 shows the total running time > > dropping from 5653ms to 4571ms. The code is uniformly > > better in just about every category. > > You could try running the benchmarks suite to see what that gives: > http://hg.python.org/benchmarks/ > > Regards > > Antoine. > >>> > >>> or pypy benchmark suite which is more comprehensive for python 2.7 > >>> (http://bitbucket.org/pypy/benchmarks) > >> > >> Besides, is there any reason not to use clang by default on OS X? > > > > How did this thread go from: > > "for OS X, GCC 4.8.1 gives you significantly faster machine code > > than the system GCC 4.2.1" > > to > > "let's just use clang" > > ? > > Because we use the system compiler for building the official binary > packages. > > I'm not looking forward to bootstrapping GCC multiple times[*] just to be > able > to build a slightly faster python. And more so because you have to be very > careful when using a alternative compiler when building the installer, it > is > very easy to end up with a build that others cannot use to build extension > because they don't have /Users/ronald/Tools/Compiler/gcc-4.8/bin/gcc. > > > > > (I should declare that I've been hacking on GCC for the last few months, > > so I have an interest in this) > > It would still be interesting to know which compiler would generate the > fastest code for CPython. Apple tends to claim that clang generates better > code than GCC, buit AFAIK they compare the latest clang with the latest > version of GCC that they used to ship, which is ancient by now. > > Ronald > > [*] multiple times due to fat binaries. > > ___ > 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/dwightdhutto%40gmail.com > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com* ___ 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] [Python-checkins] cpython: Issue #18520: Add a new PyStructSequence_InitType2() function, same than
On 23 Jul, 2013, at 2:01, Benjamin Peterson wrote:
> We've cheerfully broken the ABI before on minor releases, though if
> it's part of the stable ABI, we can't be cavaliar about that anymore.
It is not part of the stable ABI. Given that the implementation of
PyStructSequence_InitType() in the patch just calls PyStructSequence_InitType2()
and ignores the return value you could change the return value of ..InitType().
This may or may not break existing extensions using the function (depending on
platform ABI details, AFAIK this is not a problem on x86/x86_64), but reusing
extensions across python feature releases is not supported anyway. There are
no problems when compiling code, most C compilers won't even warn about ignored
return values unless you explicitly ask for it.
Ronald
>
> 2013/7/22 Victor Stinner :
>> "Add a new PyStructSequence_InitType2()"
>>
>> I added a new function because I guess that it would break the API (and ABI)
>> to change the return type of a function in a minor release.
>>
>> Tell me if you have a better name than PyStructSequence_InitType2() ;-)
>>
>> "Ex" suffix is usually used when parameters are added. It is not the case
>> here.
>>
>> Victor
>>
>> Le 22 juil. 2013 23:59, "victor.stinner" a
>> écrit :
>>>
>>> http://hg.python.org/cpython/rev/fc718c177ee6
>>> changeset: 84793:fc718c177ee6
>>> user:Victor Stinner
>>> date:Mon Jul 22 22:24:54 2013 +0200
>>> summary:
>>> Issue #18520: Add a new PyStructSequence_InitType2() function, same than
>>> PyStructSequence_InitType() except that it has a return value (0 on
>>> success,
>>> -1 on error).
>>>
>>> * PyStructSequence_InitType2() now raises MemoryError on memory
>>> allocation failure
>>> * Fix also some calls to PyDict_SetItemString(): handle error
>>>
>>> files:
>>> Include/pythonrun.h| 2 +-
>>> Include/structseq.h| 2 +
>>> Misc/NEWS | 4 +++
>>> Modules/_lsprof.c | 10 ---
>>> Modules/grpmodule.c| 11 ++--
>>> Modules/posixmodule.c | 24 --
>>> Modules/pwdmodule.c| 5 ++-
>>> Modules/resource.c | 9 --
>>> Modules/signalmodule.c | 7 +++--
>>> Modules/spwdmodule.c | 8 --
>>> Modules/timemodule.c | 5 ++-
>>> Objects/floatobject.c | 9 --
>>> Objects/longobject.c | 6 +++-
>>> Objects/structseq.c| 37 +
>>> Python/pythonrun.c | 3 +-
>>> Python/sysmodule.c | 23 -
>>> Python/thread.c| 6 +++-
>>> 17 files changed, 117 insertions(+), 54 deletions(-)
>>>
>>>
>>> diff --git a/Include/pythonrun.h b/Include/pythonrun.h
>>> --- a/Include/pythonrun.h
>>> +++ b/Include/pythonrun.h
>>> @@ -197,7 +197,7 @@
>>> PyAPI_FUNC(void) _PyExc_Init(PyObject * bltinmod);
>>> PyAPI_FUNC(void) _PyImportHooks_Init(void);
>>> PyAPI_FUNC(int) _PyFrame_Init(void);
>>> -PyAPI_FUNC(void) _PyFloat_Init(void);
>>> +PyAPI_FUNC(int) _PyFloat_Init(void);
>>> PyAPI_FUNC(int) PyByteArray_Init(void);
>>> PyAPI_FUNC(void) _PyRandom_Init(void);
>>> #endif
>>> diff --git a/Include/structseq.h b/Include/structseq.h
>>> --- a/Include/structseq.h
>>> +++ b/Include/structseq.h
>>> @@ -24,6 +24,8 @@
>>> #ifndef Py_LIMITED_API
>>> PyAPI_FUNC(void) PyStructSequence_InitType(PyTypeObject *type,
>>>PyStructSequence_Desc *desc);
>>> +PyAPI_FUNC(int) PyStructSequence_InitType2(PyTypeObject *type,
>>> + PyStructSequence_Desc *desc);
>>> #endif
>>> PyAPI_FUNC(PyTypeObject*) PyStructSequence_NewType(PyStructSequence_Desc
>>> *desc);
>>>
>>> diff --git a/Misc/NEWS b/Misc/NEWS
>>> --- a/Misc/NEWS
>>> +++ b/Misc/NEWS
>>> @@ -10,6 +10,10 @@
>>> Core and Builtins
>>> -
>>>
>>> +- Issue #18520: Add a new PyStructSequence_InitType2() function, same
>>> than
>>> + PyStructSequence_InitType() except that it has a return value (0 on
>>> success,
>>> + -1 on error).
>>> +
>>> - Issue #15905: Fix theoretical buffer overflow in handling of
>>> sys.argv[0],
>>> prefix and exec_prefix if the operation system does not obey
>>> MAXPATHLEN.
>>>
>>> diff --git a/Modules/_lsprof.c b/Modules/_lsprof.c
>>> --- a/Modules/_lsprof.c
>>> +++ b/Modules/_lsprof.c
>>> @@ -884,10 +884,12 @@
>>> PyDict_SetItemString(d, "Profiler", (PyObject *)&PyProfiler_Type);
>>>
>>> if (!initialized) {
>>> -PyStructSequence_InitType(&StatsEntryType,
>>> - &profiler_entry_desc);
>>> -PyStructSequence_InitType(&StatsSubEntryType,
>>> - &profiler_subentry_desc);
>>> +if (PyStructSequence_InitType2(&StatsEntryType,
>>> + &profiler_entry_desc) < 0)
>>> +return NULL;
>>> +if (PyStructSequence_InitType2(&StatsSubEntryType,
>>> + &profiler_subentry_desc) < 0)
>>> +return NULL;
>>> }
>>> Py_INCREF((
Re: [Python-Dev] cpython: Add modeling file for Coverity Scan.
On Tue, 23 Jul 2013 01:31:24 +0200 (CEST) christian.heimes wrote: > + > +typedef int sdigit; > +typedef long Py_ssize_t; Can't you write "typedef ssize_t Py_ssize_t" instead? Regards Antoine. ___ 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] cpython: Issue #18520: Add a new PyStructSequence_InitType2() function, same than
On Tue, 23 Jul 2013 08:22:30 +0200 Antoine Pitrou wrote: > On Tue, 23 Jul 2013 08:15:29 +0200 > Ronald Oussoren wrote: > > > > On 23 Jul, 2013, at 2:01, Benjamin Peterson wrote: > > > > > We've cheerfully broken the ABI before on minor releases, though if > > > it's part of the stable ABI, we can't be cavaliar about that anymore. > > > > It is not part of the stable ABI. Given that the implementation of > > PyStructSequence_InitType() in the patch just calls > > PyStructSequence_InitType2() > > and ignores the return value you could change the return value of > > ..InitType(). > > > > This may or may not break existing extensions using the function (depending > > on > > platform ABI details, AFAIK this is not a problem on x86/x86_64), but > > reusing > > extensions across python feature releases is not supported anyway. > > Not supported? It should certainly be supported accross bugfix > versions. Otherwise, installing a new bugfix version would force you to > recompile all independently-installed extension modules. Ah, but I see that "minor release" was used in the sense of "feature release". My bad. (Grrr!) Regards Antoine. ___ 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
