[issue11165] Document PyEval_Call* functions

2019-08-08 Thread Inada Naoki
Change by Inada Naoki : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue11165] Document PyEval_Call* functions

2019-08-07 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: These functions are now officially deprecated, see PR 14804. So I think that this issue can be closed. -- nosy: +jdemeyer ___ Python tracker

[issue11165] Document PyEval_Call* functions

2017-02-15 Thread INADA Naoki
INADA Naoki added the comment: In PR 75, I added a comment in Include/ceval.h, right before PyEval_Call* APIs. https://github.com/python/cpython/pull/75/files#diff-da3df9def5eca3595399b0a5a7698eac -- ___ Python tracker

[issue11165] Document PyEval_Call* functions

2017-02-15 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: While they are undocumented there is no a place for adding the recommendation of using corresponding PyObject_Call* functions and describing the way of porting from PyEval_Call* functions to PyObject_Call* functions. -- nosy: +serhiy.storchaka

[issue11165] Document PyEval_Call* functions

2017-02-15 Thread INADA Naoki
INADA Naoki added the comment: I think PyObject_Call* APIs should be preferred. As discussed in #29548, we can't remove or deprecate PyEval_Call*. But I don't think it's worth enough to document them. How about keep them undocumented? -- nosy: +inada.naoki

[issue11165] Document PyEval_Call* functions

2017-02-14 Thread Mark Lawrence
Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue11165] Document PyEval_Call* functions

2017-02-14 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: The PyEval_Call*() APIs indeed predate the PyObject_Call*() ones. The PyObject_Call*() APIs came into existence when the abstract layer was added in Python 1.3. The PyObject_Call*() APIs lacked a way to call an object with keyword arguments for a long

[issue11165] Document PyEval_Call* functions

2014-06-27 Thread Mark Lawrence
Mark Lawrence added the comment: @Nick I assume that this still needs doing. msg128249 says you've removed the easy tag but it still shows in the keywords list. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org

[issue11165] Document PyEval_Call* functions

2011-03-15 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: There may be some legitimate use cases when embedding Python and you *know* that the checks performed by the PyObject_* versions aren't needed. It may also be historical - the PyEval versions may predate the PyObject ones. --

[issue11165] Document PyEval_Call* functions

2011-03-14 Thread Robbie Clemons
Changes by Robbie Clemons robclem...@gmail.com: -- nosy: +robquad ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11165 ___ ___ Python-bugs-list

[issue11165] Document PyEval_Call* functions

2011-03-14 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr added the comment: IMO, it would probably have been better if these APIs had been private from the start. Is there any use case for calling them from 3rd-party code? -- nosy: +pitrou ___ Python tracker

[issue11165] Document PyEval_Call* functions

2011-02-09 Thread Nick Coghlan
New submission from Nick Coghlan ncogh...@gmail.com: There are currently undocumented PyEval_Call* equivalents to a number of the PyObject_Call* functions. Since there are resources out there on the web that direct people to use the currently undocumented PyEval functions, it would be good to

[issue11165] Document PyEval_Call* functions

2011-02-09 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: Removed the easy tag, since this may involve some python-dev discussion as to where to put them in C API docs (they don't really fit in any of the current sections). Perhaps an advanced APIs section, for things that most C extensions or