Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
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_VA_COPY with the (C99) standard va_copy Thanks! Coverity has been complaining about Py_VA_COPY() for a long time. Your change may cause a memory leak on some platforms. You must va_end() a va_copy() region: Each invocation of va_copy() must be matched by a corresponding invocation of va_end() in the same function. https://linux.die.net/man/3/va_copy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
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 queue;
And it's a great example of feature creep -- once ordered dicts are
builtin, every one and their niece wants to use them, not necessarily
what they were originally envisioned for.
By comparison, **kwargs and **meta are statistically mostly immutable.
Perhaps distinct specialisations are better?
On 20 September 2016 at 13:11, INADA Naoki wrote:
> On Tue, Sep 20, 2016 at 7:02 PM, INADA Naoki wrote:
>> On Tue, Sep 20, 2016 at 6:56 PM, Dima Tisnek wrote:
>>> Totally random thought:
>>>
>>> Can lru_cache be simplified to use an ordered dict instead of dict +
>>> linked list?
>>>
>>
>> I think so.
>> See also: http://bugs.python.org/issue28199#msg276938
>>
>
> FYI, current dict implementation is not optimized for removing first
> item like this:
>
> ```
> // When hit max_size
> Py_ssize_t pos;
> PyObject *key;
> if (PyDict_Next(d, &pos, &key, NULL)) {
> if (PyDict_DelItem(key) < 0) {
> // error.
> }
> }
> ```
>
> So, before changing lru_cache implementation, I (or someone else) should
> rewrite
> OrderedDict which has O(1) "remove first item" method. (At least
> max_size is not None).
>
> But both of OrderedDict and lru_cache improvements can't be in 3.6
> since 3.6 is beta now.
> I'll try it after 3.6rc1.
>
> --
> INADA Naoki
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dimaqq%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
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 became an alias. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
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 is done: it's the new perf module available on PyPI (it works on Python 2.7-3.7). The second part of my plan was to enhance the stdlib, so here you have! "Enhance the timeit module: display average +- std dev instead of minimum" http://bugs.python.org/issue28240 Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
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 proposed change might be justified. Best wishes Thierry On Wed, Sep 21, 2016 at 12:42pm, Victor Stinner < victor.stin...@gmail.com [victor.stin...@gmail.com] > 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? :-) Maybe we need at least a comment mentionning when (python version) the macro became an alias. Victor___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
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:Tue Sep 20 20:39:33 2016 -0700 > > summary: > > replace usage of Py_VA_COPY with the (C99) standard va_copy > > Thanks! Coverity has been complaining about Py_VA_COPY() for a long > time. Your change may cause a memory leak on some platforms. You must > va_end() a va_copy() region: Yep. Thanks for fixing that. I'm not actually aware of any platform where va_end() frees anything, but it's the right thing to do. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
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 with me, though, the maintenance burden of them is precisely one line. Just dump the compat macros in Python 4.0 I think. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
