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
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
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
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 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,
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 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
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 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.
>>
>
>
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 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 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
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 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
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
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
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 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
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:
19 matches
Mail list logo
