On 2016-08-08 6:53 PM, Victor Stinner wrote:
2016-08-09 0:40 GMT+02:00 Guido van Rossum :
tl;dr I found a way to make CPython 3.6 faster and I validated that
there is no performance regression.
But is there a performance improvement?
Sure.
On micro-benchmarks, you can see nice improvements:
2016-08-09 1:36 GMT+02:00 Brett Cannon :
> I just wanted to say I'm excited about this and I'm glad someone is taking
> advantage of what Argument Clinic allows for and what I know Larry had
> initially hoped AC would make happen!
To make "Python" faster, not only a few specific functions, "all" C
I just wanted to say I'm excited about this and I'm glad someone is taking
advantage of what Argument Clinic allows for and what I know Larry had
initially hoped AC would make happen!
I should also point out that Serhiy has a patch for faster keyword argument
parsing thanks to AC: http://bugs.pyth
2016-08-09 0:40 GMT+02:00 Guido van Rossum :
> Hm, I agree that those tuples are probably expensive. I recall that
> IronPython boasted faster Python calls by doing something closer to the
> platform (in their case I'm guessing C# or the CLR :-).
To be honest, I didn't expect *any* speedup just by
2016-08-09 0:40 GMT+02:00 Guido van Rossum :
>> tl;dr I found a way to make CPython 3.6 faster and I validated that
>> there is no performance regression.
>
> But is there a performance improvement?
Sure.
On micro-benchmarks, you can see nice improvements:
* getattr(1, "real") becomes 44% faste
On Mon, Aug 8, 2016 at 3:25 PM, Victor Stinner
wrote:
> tl;dr I found a way to make CPython 3.6 faster and I validated that
> there is no performance regression.
But is there a performance improvement?
> I'm requesting approval of core
> developers to start pushing changes.
>
> In 2014 during
Hi,
tl;dr I found a way to make CPython 3.6 faster and I validated that
there is no performance regression. I'm requesting approval of core
developers to start pushing changes.
In 2014 during a lunch at Pycon, Larry Hasting told me that he would
like to get rid of temporary tuples to call functio
On Tue, Aug 9, 2016 at 7:14 AM, Wolfgang Maier
wrote:
> Right, I think a fairer comparison would be to:
>
> class ctx2:
> def __enter__(self):
> self.it = iter(self)
> return next(self.it)
>
> def __exit__(self, *args):
> try:
> next(self.it)
> e
On 8/8/2016 22:38, Yury Selivanov wrote:
On 2016-08-08 4:18 PM, Guido van Rossum wrote:
I think Nick would be interested in understanding why this is the
case. What does the decorator do that could be so expensive?
From the looks of it it doesn't do anything special. Although with
@contextl
On 2016-08-08 4:18 PM, Guido van Rossum wrote:
I think Nick would be interested in understanding why this is the
case. What does the decorator do that could be so expensive?
From the looks of it it doesn't do anything special. Although with
@contextlib.contextmanager we have to instantiate
On Mon, Aug 8, 2016 at 10:07 PM, Yury Selivanov
wrote:
>
>
> On 2016-08-08 3:33 PM, Giampaolo Rodola' wrote:
>
>> I wanted to give it a try rewriting this in C but since @contextmanager
>> has a lot of magic I wanted to ask first whether this 1) is technically
>> possible 2) is desirable.
>>
>
>
I think Nick would be interested in understanding why this is the case.
What does the decorator do that could be so expensive?
On Mon, Aug 8, 2016 at 1:07 PM, Yury Selivanov
wrote:
>
>
> On 2016-08-08 3:33 PM, Giampaolo Rodola' wrote:
>
>> I wanted to give it a try rewriting this in C but since
On 2016-08-08 3:33 PM, Giampaolo Rodola' wrote:
I wanted to give it a try rewriting this in C but since
@contextmanager has a lot of magic I wanted to ask first whether this
1) is technically possible 2) is desirable.
It is definitely technologically possible. However, the C
implementation
import timeit
import contextlib
@contextlib.contextmanager
def ctx1():
yield
class ctx2:
def __enter__(self):
pass
def __exit__(self, *args):
pass
t1 = timeit.timeit("with ctx1(): pass", setup="from __main__ import ctx1")
t2 = timeit.timeit("with ctx2(): pass", setup=
On Mon, Aug 8, 2016 at 8:59 AM, Ned Deily wrote:
> On Aug 8, 2016, at 02:45, Steven D'Aprano wrote:
>>
>> Could not find platform dependent libraries
>> Consider setting $PYTHONHOME to [:]
>> Could not find platform dependent libraries
>> Consider setting $PYTHONHOME to [:]
>
> On Aug 8, 2016,
On Mon, 8 Aug 2016 at 08:10 tdsmith wrote:
> Hi python-dev! I'm a maintainer for Homebrew, a third-party package
> manager for OS X, where I'm the resident parseltongue.
>
> Issue 10910 is related to problems building CPython extension modules
> with C++ code on BSDs. As I understand it, pyport.h
On Aug 8, 2016, at 02:45, Steven D'Aprano wrote:
> On Mon, Aug 08, 2016 at 12:17:21AM -0400, Ned Deily wrote:
>> Also, try without setting PYTHONHOME. I'm not sure what you're trying to do
>> by setting that but you shouldn't need to.
> I didn't think I needed to either, but when I try without i
Hi python-dev! I'm a maintainer for Homebrew, a third-party package
manager for OS X, where I'm the resident parseltongue.
Issue 10910 is related to problems building CPython extension modules
with C++ code on BSDs. As I understand it, pyport.h has some code
specific to BSD and friends, including
Ned Deily writes:
> But the point I was trying to make is that, by changing the
> language requirement, we will likely have an effect on what
> platforms (across the board) and versions we support and we should
> take that into account when making this decision. It may be the
> right decisio
19 matches
Mail list logo
