Make call_function_tail() less weird: don't decrement args reference counter,
the caller is now responsible to do that. The caller now also checks if args is
NULL.
Issue #27128.
Issue #27128: Modify call_function_tail() to use _PyObject_FastCall() when args
is not a tuple to avoid the creation of a temporary tuple.
call_function_tail() is used by:
* PyObject_CallFunction()
* PyObject_CallMethod()
* _PyObject_CallMethodId()
Issue #27128: Add _PyObject_FastCall(), a new calling convention avoiding a
temporary tuple to pass positional parameters in most cases, but create a
temporary tuple if needed (ex: for the tp_call slot).
The API is prepared to support keyword parameters, but the full implementation
will come later (_PyFunction_FastCall() doesn't support keyword parameters
yet).
Add also:
* _PyStack_AsTuple() helper function: convert a "stack" of parameters to
a tuple.
* _PyCFunction_FastCall(): fast call implementation for C functions
* _PyFunction_FastCall(): fast call implementation for Python functions
The deprecation warning is emitted if __float__ returns an instance of
a strict subclass of float. In a future versions of Python this can
be an error.
This avoids possible buffer overreads when int(), float(), compile(), exec()
and eval() are passed bytes-like objects. Similar code is removed from the
complex() constructor, where it was not reachable.
Patch by John Leitch, Serhiy Storchaka and Martin Panter.
This changes the main documentation, doc strings, source code comments, and a
couple error messages in the test suite. In some cases the word was removed
or edited some other way to fix the grammar.
Too bad, sometimes Py_FatalError() is unable to write the exception into
sys.stderr (on "AMD64 OpenIndiana 3.x" buildbot, the buildbot was probably out
of memory).
Call Py_FatalError() with a different message for the two cases (result+error,
or no result and no error).
Py_FatalError() instead of using an assertion in debug mode. Py_FatalError()
displays the current exception and the traceback which contain more information
than just the assertion error.
which returned an invalid result (result+error or no result without error) in
the exception message.
Add also unit test to check that the exception contains the name of the
function.
Special case: the final _PyEval_EvalFrameEx() check doesn't mention the
function since it didn't execute a single function but a whole frame.
raise a SystemError if a function returns a result and raises an exception.
The SystemError is chained to the previous exception.
Refactor also PyObject_Call() and PyCFunction_Call() to make them more readable.
Remove some checks which became useless (duplicate checks).
Change reviewed by Serhiy Storchaka.
Some time ago we changed the docs to consistently use the term 'bytes-like
object' in all the contexts where bytes, bytearray, memoryview, etc are used.
This patch (by Ezio Melotti) completes that work by changing the error
messages that previously reported that certain types did "not support the
buffer interface" to instead say that a bytes-like object is required. (The
glossary entry for bytes-like object references the discussion of the buffer
protocol in the docs.)
Victor Stinner
Martin Panter
Serhiy Storchaka
Raymond Hettinger
Stefan Krah
Ethan Furman
R David Murray
Georg Brandl
Benjamin Peterson