summaryrefslogtreecommitdiff
path: root/python/rpmsystem-py.h
Commit message (Collapse)AuthorAgeFilesLines
* Replace all PyInt_* uses with PyLong_* in the codebasePanu Matilainen2019-08-121-10/+0
| | | | | | Up to now we handled this via Python 3 compatibility defines in rpmsystem-py.h but now that Python 2 is no longer supported, actually update the codebase. No functional changes.
* Un-inline utf8FromString() python helper now that we canPanu Matilainen2019-05-271-12/+1
| | | | | | Since commit 73a41da965337aaacabd53924f1b67b967e0476e this doesn't need to be inline with murky linkage across different modules. With this, it'd now be possible to add some central control too if we wanted.
* Return NULL string as None from utf8FromString()Panu Matilainen2019-02-261-2/+8
| | | | | | | Commit 84920f898315d09a57a3f1067433eaeb7de5e830 regressed dnf install to segfault at the end due to some NULL string passed to strlen(). Check for NULL and return it as None, make it an inline function to make this saner.
* In Python 3, return all our string data as surrogate-escaped utf-8 stringsPanu Matilainen2019-02-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the almost ten years of rpm sort of supporting Python 3 bindings, quite obviously nobody has actually tried to use them. There's a major mismatch between what the header API outputs (bytes) and what all the other APIs accept (strings), resulting in hysterical TypeErrors all over the place, including but not limited to labelCompare() (RhBug:1631292). Also a huge number of other places have been returning strings and silently assuming utf-8 through use of Py_BuildValue("s", ...), which will just irrevocably fail when non-utf8 data is encountered. The politically Python 3-correct solution would be declaring all our data as bytes with unspecified encoding - that's exactly what it historically is. However doing so would by definition break every single rpm script people have developed on Python 2. And when 99% of the rpm content in the world actually is utf-8 encoded even if it doesn't say so (and in recent times packages even advertise themselves as utf-8 encoded), the bytes-only route seems a wee bit too draconian, even to this grumpy old fella. Instead, route all our string returns through a single helper macro which on Python 2 just does what we always did, but in Python 3 converts the data to surrogate-escaped utf-8 strings. This makes stuff "just work" out of the box pretty much everywhere even with Python 3 (including our own test-suite!), while still allowing to handle the non-utf8 case. Handling the non-utf8 case is a bit more uglier but still possible, which is exactly how you want corner-cases to be. There might be some uses for retrieving raw byte data from the header, but worrying about such an API is a case for some other rainy day, for now we mostly only care that stuff works again. Also add test-cases for mixed data source labelCompare() and non-utf8 insert to + retrieve from header.
* Bump the minimum Python version requirement to 2.7Panu Matilainen2018-10-041-33/+0
| | | | | | | Older Python versions are long since past their EOL, we don't need to support them either. Python 2.7 is also the least incompatible version compared to Python 3, going forward. Nuke the now unnecessary compat macros.
* Define PY_SSIZE_T_CLEANLubos Kardos2015-09-181-0/+1
| | | | | | | | | | | When PyArg_ParseTupleAndKeywords() is used with format argument "s#" that means get a string and his length then the length is returned as as a Py_ssize_t in python3 but as an int in python2, which casues a problem because rpmfd_write() that uses PyArg_ParseTupleAndKeywords() expects the length as a Py_ssize_t always. This problem affects big endian systems with python2 as default. If PY_SSIZE_T_CLEAN is defined then PyArg_ParseTupleAndKeywords() returns the length as a Py_ssize_t in both python2 and python3.
* Python 2/3 compat define for PyInt_AsSsize_t, used by rpmfilesPanu Matilainen2014-02-131-0/+1
|
* inverse the macro definition condition in c87ad03.Ales Kozumplik2011-11-181-1/+1
| | | | - thanks zpavlas for pointing this out.
* python: use the more modern PyCapsule over PyCObject (RhBug:623864).Ales Kozumplik2011-11-181-0/+10
| | | | | | - rpm.header.new() will still keep accepting PyCObject for now in case a client library depends on this. - involves macro trickery to make rpm buildable against python 2.6 still.
* Fix the PyBytes vs PyString compatibility definesPanu Matilainen2011-03-091-5/+5
| | | | | - Oops. Quite obviously nobody has even tried to build this with python < 2.6. Whether it'd actually work is another question...
* Python 3 fixupsPanu Matilainen2011-03-091-0/+2
| | | | | | - PyString is gone, use PyBytes instead - Add compatibility defines to paper over PyInt/PyLong_JustHowLongFunctionNamesYouCanComeUpWith()
* Cut the remaining ties python bindings have to main rpm sourcesPanu Matilainen2011-03-091-2/+0
| | | | | | - Include what little we need from standard headers instead of relying on rpm source tree system.h for anything. - Remove non-public includes from python binding include paths
* On Python 3, use macros to alias all usage of PyInt_ to PyLong_ equivalentsPanu Matilainen2009-10-211-0/+7
| | | | | - Python 3 unified PyInt with PyLong, the former no longer exists - Based on a patch by David Malcolm
* Replace PyString usage with PyBytes everywherePanu Matilainen2009-10-211-0/+7
| | | | | | | - In Python 2.6 PyBytes is just an alias for PyString, Python 3.0 removed PyString entirely - Add compatibility defines for Python < 2.6 - Based on David Malcolm's Python 3.x efforts
* PyVarObject_HEAD_INIT() compatibility macro for Python < 2.6Panu Matilainen2009-10-191-0/+7
|
* Py_TYPE() compatibility macro for Python < 2.6Panu Matilainen2009-10-191-0/+4
|
* Include structmembers.h centrally from rpmsystem-py.hPanu Matilainen2009-10-011-1/+2
| | | | - pretty much everything might need this...
* Rename python system.h for disambiguationPanu Matilainen2009-09-221-0/+17
View Lorry Controller Status