| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(GH-140128)
Update `bytearray` to contain a `bytes` and provide a zero-copy path to
"extract" the `bytes`. This allows making several code paths more efficient.
This does not move any codepaths to make use of this new API. The documentation
changes include common code patterns which can be made more efficient with
this API.
---
When just changing `bytearray` to contain `bytes` I ran pyperformance on a
`--with-lto --enable-optimizations --with-static-libpython` build and don't see
any major speedups or slowdowns with this; all seems to be in the noise of
my machine (Generally changes under 5% or benchmarks that don't touch
bytes/bytearray).
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Maurycy Pawłowski-Wieroński <5383+maurycy@users.noreply.github.com>
|
| |
|
|
|
|
|
| |
Replace PyBytes_FromStringAndSize() and _PyBytes_Resize() with the
PyBytesWriter API.
Add _PyBytesWriter_GetSize() and _PyBytesWriter_GetData() static
inline functions.
|
| |
|
| |
It is now replaced with the new public PyBytesWriter API (PEP 782).
|
| |
|
| |
Disable overallocation in _PyBytes_FormatEx() at the last write.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
handler (GH-129648)
If the error handler is used, a new bytes object is created to set as
the object attribute of UnicodeDecodeError, and that bytes object then
replaces the original data. A pointer to the decoded data will became invalid
after destroying that temporary bytes object. So we need other way to return
the first invalid escape from _PyUnicode_DecodeUnicodeEscapeInternal().
_PyBytes_DecodeEscape() does not have such issue, because it does not
use the error handlers registry, but it should be changed for compatibility
with _PyUnicode_DecodeUnicodeEscapeInternal().
|
| | |
|
| |
|
|
|
|
| |
No longer export _PyCompile_AstOptimize() internal C API function.
Change comment style to "// comment" and add comment explaining why
other functions have to be exported.
|
| |
|
|
|
|
|
|
|
|
|
| |
Move private _PyBytes functions to the internal C API
(pycore_bytesobject.h):
* _PyBytes_DecodeEscape()
* _PyBytes_FormatEx()
* _PyBytes_FromHex()
* _PyBytes_Join()
No longer export these functions.
|
| |
|
|
| |
Remove the _PyBytesWriter C API: move it to the internal C API
(pycore_bytesobject.h).
|
| |
|
| |
There were cases where we do unnecessary work for builtin static types. This also simplifies some work necessary for a per-interpreter GIL.
|
| |
|
| |
Use it where appropriate: the repeat functions of `array.array`, `bytes`, `bytearray`, and `str`.
|
| | |
|
| |
|
|
|
|
| |
Move _PyBytes_Find() and _PyBytes_ReverseFind() functions to the
internal C API.
bytesobject.c now includes pycore_bytesobject.h.
|
| |
|
|
|
| |
The empty bytes object (b'') and the 256 one-character bytes objects were allocated at runtime init. Now we statically allocate and initialize them.
https://bugs.python.org/issue45953
|
|
|
consistent. (gh-29998)
This change is strictly renames and moving code around. It helps in the following ways:
* ensures type-related init functions focus strictly on one of the three aspects (state, objects, types)
* passes in PyInterpreterState * to all those functions, simplifying work on moving types/objects/state to the interpreter
* consistent naming conventions help make what's going on more clear
* keeping API related to a type in the corresponding header file makes it more obvious where to look for it
https://bugs.python.org/issue46008
|
