summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* Fix unused variable and signed/unsigned warnings (GH-15537)Raymond Hettinger2019-08-271-0/+6
|
* Make PyXXX_Fini() functions private (GH-15531)Victor Stinner2019-08-2612-12/+13
| | | | | For example, rename PyTuple_Fini() to _PyTuple_Fini(). These functions are only declared in the internal C API.
* bpo-27575: port set intersection logic into dictview intersection (GH-7696)Forest Gregg2019-08-261-4/+77
|
* bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15131)Nick Coghlan2019-08-251-9/+0
| | | | | | | | | | | | | | | - drop TargetScopeError in favour of raising SyntaxError directly as per the updated PEP 572 - comprehension iteration variables are explicitly local, but named expression targets in comprehensions are nonlocal or global. Raise SyntaxError as specified in PEP 572 - named expression targets in the outermost iterable of a comprehension have an ambiguous target scope. Avoid resolving that question now by raising SyntaxError. PEP 572 originally required this only for cases where the bound name conflicts with the iteration variable in the comprehension, but CPython can't easily restrict the exception to that case (as it doesn't know the target variable names when visiting the outermost iterator expression)
* bpo-19072: Make @classmethod support chained decorators (GH-8405)Berker Peksag2019-08-241-0/+4
|
* bpo-37812: Convert CHECK_SMALL_INT macro to a function so the return is ↵Greg Price2019-08-241-11/+25
| | | | explicit. (GH-15216)
* bpo-37830: Fix compilation of break and continue in finally. (GH-15320)Serhiy Storchaka2019-08-241-7/+16
| | | | | | Fix compilation of "break" and "continue" in the "finally" block when the corresponding "try" block contains "return" with a non-constant value.
* bpo-36311: Fixes decoding multibyte characters around chunk boundaries and ↵Steve Dower2019-08-211-6/+10
| | | | improves decoding performance (GH-15083)
* abstract.c should not be executable. (GH-15348)Benjamin Peterson2019-08-211-0/+0
|
* bpo-15913: Implement PyBuffer_SizeFromFormat() (GH-13873)Joannah Nanjekye2019-08-201-0/+42
| | | | Implement PyBuffer_SizeFromFormat() function (previously documented but not implemented): call struct.calcsize().
* bpo-37732: Fix GCC warning in _PyObject_Malloc() (GH-15333)Victor Stinner2019-08-201-21/+16
| | | | | | | pymalloc_alloc() now returns directly the pointer, return NULL on memory allocation error. allocate_from_new_pool() already uses NULL as marker for "allocation failed".
* bpo-37540: vectorcall: keyword names must be strings (GH-14682)Jeroen Demeyer2019-08-161-6/+19
| | | | | | | | The fact that keyword names are strings is now part of the vectorcall and `METH_FASTCALL` protocols. The biggest concrete change is that `_PyStack_UnpackDict` now checks that and raises `TypeError` if not. CC @markshannon @vstinner https://bugs.python.org/issue37540
* bpo-37207: enable vectorcall for type.__call__ (GH-14588)Jeroen Demeyer2019-08-151-2/+3
| | | | | | | | | | | | Base PR for other PRs that want to play with `type.__call__` such as #13930 and #14589. The author is really @markshannon I just made the PR. https://bugs.python.org/issue37207 Automerge-Triggered-By: @encukou
* bpo-36030: Improve performance of some tuple operations (GH-12052)Sergey Fedoseev2019-08-141-32/+71
|
* bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096)Hai Shi2019-08-141-2/+2
| | | | Fix the following warning with GCC 4.8.5: Objects/obmalloc.c: warning: ‘no_sanitize_thread’ attribute directive ignored
* bpo-37337: Fix a GCC 9 warning in Objects/descrobject.c (GH-14814)Zackery Spytz2019-08-141-1/+1
| | | | Commit b1263d5a60d3f7ab02dd28409fff59b3815a3f67 causes GCC 9.1.0 to give a warning in Objects/descrobject.c.
* bpo-37648: Fixed minor inconsistency in some __contains__. (GH-14904)Serhiy Storchaka2019-08-044-6/+4
| | | | | The collection's item is now always at the left and the needle is on the right of ==.
* Fix typos in comments, docs and test names (#15018)Min ho Kim2019-07-304-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | * Fix typos in comments, docs and test names * Update test_pyparse.py account for change in string length * Apply suggestion: splitable -> splittable Co-Authored-By: Terry Jan Reedy <tjreedy@udel.edu> * Apply suggestion: splitable -> splittable Co-Authored-By: Terry Jan Reedy <tjreedy@udel.edu> * Apply suggestion: Dealloccte -> Deallocate Co-Authored-By: Terry Jan Reedy <tjreedy@udel.edu> * Update posixmodule checksum. * Reverse idlelib changes.
* bpo-37340: remove free_list for bound method objects (GH-14232)Inada Naoki2019-07-263-96/+11
|
* bpo-37543: optimize pymalloc (#14674)Inada Naoki2019-07-171-218/+226
| | | | | | PyObject_Malloc() and PyObject_Free() inlines pymalloc_alloc and pymalloc_free partially. But when PGO is not used, compiler don't know where is the hot part in pymalloc_alloc and pymalloc_free.
* bpo-29548: no longer use PyEval_Call* functions (GH-14683)Jeroen Demeyer2019-07-111-1/+10
|
* bpo-37547: add _PyObject_CallMethodOneArg (GH-14685)Jeroen Demeyer2019-07-112-6/+6
|
* Fix compiler warning in new code. (#14690)Tim Peters2019-07-101-1/+1
| | | uintptr_t is an integer type, and can't be compared to NULL directly.
* bpo-37537: Compute allocated blocks in _Py_GetAllocatedBlocks() (#14680)Neil Schemenauer2019-07-101-7/+22
| | | | | | Keeping an account of allocated blocks slows down _PyObject_Malloc() and _PyObject_Free() by a measureable amount. Have _Py_GetAllocatedBlocks() iterate over the arenas to sum up the allocated blocks for pymalloc.
* bpo-37337: Add _PyObject_CallMethodNoArgs() (GH-14267)Jeroen Demeyer2019-07-086-11/+11
|
* bpo-37151: remove _PyMethodDef_RawFastCall* functions (GH-14603)Jeroen Demeyer2019-07-051-259/+0
|
* bpo-36974: separate vectorcall functions for each calling convention (GH-13781)Jeroen Demeyer2019-07-053-79/+354
|
* bpo-37483: add _PyObject_CallOneArg() function (#14558)Jeroen Demeyer2019-07-0415-40/+29
|
* bpo-37233: optimize method_vectorcall in case of totalargs == 0 (GH-14550)Jeroen Demeyer2019-07-031-6/+10
|
* bpo-36904: Optimize _PyStack_UnpackDict (GH-14517)Jeroen Demeyer2019-07-021-63/+85
|
* bpo-37221: Add PyCode_NewWithPosOnlyArgs to be used internally and set ↵Pablo Galindo2019-07-011-15/+31
| | | | | | PyCode_New as a compatibility wrapper (GH-13959) Add PyCode_NewEx to be used internally and set PyCode_New as a compatibility wrapper
* bpo-37337: Add _PyObject_VectorcallMethod() (GH-14228)Jeroen Demeyer2019-06-282-7/+46
|
* bpo-37417: Fix error handling in bytearray.extend. (GH-14407)Brandt Bucher2019-06-261-0/+4
|
* bpo-37388: Add PyUnicode_Decode(str, 0) fast-path (GH-14385)Victor Stinner2019-06-251-0/+4
| | | Add a fast-path to PyUnicode_Decode() for size equals to 0.
* bpo-37388: Development mode check encoding and errors (GH-14341)Victor Stinner2019-06-251-5/+63
| | | | | | | | | In development mode and in debug build, encoding and errors arguments are now checked on string encoding and decoding operations. Examples: open(), str.encode() and bytes.decode(). By default, for best performances, the errors argument is only checked at the first encoding/decoding error, and the encoding argument is sometimes ignored for empty strings.
* bpo-24214: Fixed the UTF-8 and UTF-16 incremental decoders. (GH-14304)Serhiy Storchaka2019-06-252-6/+10
| | | | | | | * The UTF-8 incremental decoders fails now fast if encounter a sequence that can't be handled by the error handler. * The UTF-16 incremental decoders with the surrogatepass error handler decodes now a lone low surrogate with final=False.
* bpo-36974: inherit tp_vectorcall_offset unconditionally (GH-13858)Jeroen Demeyer2019-06-242-7/+7
|
* bpo-37348: optimize decoding ASCII string (GH-14283)Inada Naoki2019-06-241-34/+51
| | | `_PyUnicode_Writer` is a relatively complex structure. Initializing it is significant overhead when decoding short ASCII string.
* bpo-37151: remove _PyCFunction_FastCallDict (GH-14269)Jeroen Demeyer2019-06-201-18/+0
|
* bpo-36710: Use tstate in pylifecycle.c (GH-14249)Victor Stinner2019-06-191-1/+3
| | | | In pylifecycle.c: pass tstate argument, rather than interp argument, to functions.
* bpo-37151: remove _PyFunction_FastCallDict (GH-13864)Jeroen Demeyer2019-06-182-100/+1
|
* bpo-37233: use _PY_FASTCALL_SMALL_STACK in method_vectorcall (GH-13974)Jeroen Demeyer2019-06-181-5/+13
|
* bpo-37151: use PyVectorcall_Call for all calls of "method" (GH-13972)Jeroen Demeyer2019-06-181-12/+1
|
* bpo-37194: Add a new public PyObject_CallNoArgs() function (GH-13890)Victor Stinner2019-06-171-0/+8
| | | | | | | | | | | | | | | Add a new public PyObject_CallNoArgs() function to the C API: call a callable Python object without any arguments. It is the most efficient way to call a callback without any argument. On x86-64, for example, PyObject_CallFunctionObjArgs(func, NULL) allocates 960 bytes on the stack per call, whereas PyObject_CallNoArgs(func) only allocates 624 bytes per call. It is excluded from stable ABI 3.8. Replace private _PyObject_CallNoArg() with public PyObject_CallNoArgs() in C extensions: _asyncio, _datetime, _elementtree, _pickle, _tkinter and readline.
* bpo-36922: use Py_TPFLAGS_METHOD_DESCRIPTOR in lookup_maybe_method() (GH-13865)Jeroen Demeyer2019-06-171-1/+1
|
* bpo-37231: remove _PyObject_FastCall_Prepend (GH-14153)Jeroen Demeyer2019-06-171-36/+0
|
* closes bpo-37300: Remove unnecessary Py_XINCREF in classobject.c. (GH-14120)Hai Shi2019-06-161-1/+1
|
* bpo-37249: add declaration of _PyObject_GetMethod (GH-14015)Jeroen Demeyer2019-06-141-3/+0
|
* bpo-37231: optimize calls of special methods (GH-13973)Jeroen Demeyer2019-06-131-72/+86
|
* bpo-37257: obmalloc: stop simple arena thrashing (#14039)Tim Peters2019-06-131-2/+7
| | | | | GH-14039: allow (no more than) one wholly empty arena on the usable_arenas list. This prevents thrashing in some easily-provoked simple cases that could end up creating and destroying an arena on each loop iteration in client code. Intuitively, if the only arena on the list becomes empty, it makes scant sense to give it back to the system unless we know we'll never need another free pool again before another arena frees a pool. If the latter obtains, then - yes - this will "waste" an arena.
generated by cgit v0.12 at 2025-02-02 12:56:14 (GMT)