On Wed, Sep 21, 2016, at 03:42, Victor Stinner wrote:
> I see that the old macro is now an alias to va_copy(). A similar change
> was
> done for Py_MEMCPY(). Would it make sense to put these old macros in a
> new
> backward_compat.h header, so maybe one day we can remove them? :-)
That's fine wi
On Wed, Sep 21, 2016, at 02:06, Christian Heimes wrote:
> On 2016-09-21 05:39, benjamin.peterson wrote:
> > https://hg.python.org/cpython/rev/278b21d8e86e
> > changeset: 103977:278b21d8e86e
> > branch: 3.6
> > parent: 103975:d31b4de433b7
> > user:Benjamin Peterson
> > date:
Hello,
C99 has shown slow adoption by microsoft compilers on windows. On this
platform, the support of va_copy() is recent and started with Visual Studio
2013. Therefore, starting from Python 3.5, PY_VA_COPY can now be mapped
directly to the native implementation of va_copy(). Hence, the propo
2016-09-20 21:01 GMT+02:00 Maciej Fijalkowski :
> How about we just make timeit show average and not disable the GC then
> (two of the complaints that will not change the execution time)?
Thanks for the reminder.
The first part of my plan was to write a new module to experiment
changes. This part
I see that the old macro is now an alias to va_copy(). A similar change was
done for Py_MEMCPY(). Would it make sense to put these old macros in a new
backward_compat.h header, so maybe one day we can remove them? :-)
Maybe we need at least a comment mentionning when (python version) the
macro bec
I guess what `lru_cache` needs is atomic push-pop:
on hit: pop(this) + push_back(this)
on miss: pop_front() + push_back(this)
I reckon, if flat array is lazy (i.e. can grow larger than no. of
keys), then *amortised* push-pop performance is not hard to achieve.
Overall, it sounds more like heap q
On 2016-09-21 05:39, benjamin.peterson wrote:
> https://hg.python.org/cpython/rev/278b21d8e86e
> changeset: 103977:278b21d8e86e
> branch: 3.6
> parent: 103975:d31b4de433b7
> user:Benjamin Peterson
> date:Tue Sep 20 20:39:33 2016 -0700
> summary:
> replace usage of Py_
