[PATCHES] Build pytalloc for two Python versions at once, port to py3
pviktori at redhat.com
Fri Mar 13 07:00:18 MDT 2015
On 03/12/2015 11:59 PM, Jelmer Vernooij wrote:
> On Thu, Mar 12, 2015 at 06:53:56PM +0100, Petr Viktorin wrote:
>> On 03/12/2015 03:41 PM, Jelmer Vernooij wrote:
>>> The onus for adding support of Python3 is on those who care about it, and should
>>> not inconvenience the rest of us.
>> Alright, then we agree about this bit at least.
>> What in the patches proposed here would inconvenience you? Note that with
>> these patches I *am* looking specifically at the stand-alone libraries.
> I would prefer inlining the ifdefs in the standalone libraries, since
> that would be more readable IMHO (not having to switch back and forth
> to the wrapper header to see what each define does). Andrew and I seem
> to disagree on that though.
For what it's worth, I agree with Anderw here. Inlining the ifdefs makes
it hard to get – to use your words – proper documentation and wider
testing for the macros. With a library the testing wouldn't be as wide
as if it was in Python itself, but as wide as it can get.
It does add a dependency to pytalloc, though.
>> I believe the resulting code is quite readable, do you disagree here?
> These patches create yet another Python C API for us to use in Samba,
> one which is not used by anybody else. This makes it harder for new
> and existing contributors to come in and see what is going on,
> contribute code or find documentation. There are analoguous problems
> for the pure-Python side.
> These sorts of compatibility wrappers really belong in upstream Python,
> not in every single individual project. Barring that, I guess we'll
> have to make due with what we do have...
> An nice alternative would be, as Andrew suggested, if we could just include
> an extra header that reimplemented the standard Python2 API and called
> out to the matching Python3 functions as necessary, or vice versa.
> (Similar to what we do in Samba for libreplace). I think this is
> pretty hard though.
I believe that it's impossible to do while still keeping things clear.
I did try, however, to keep the deviations from Python 3 minimal. Here
* PyStr (to use either PyUnicode or PyBytes depending on the version)
* MODULE_INIT_FUNC (with a single clear use in boilerplate code)
* PY_RICHCMP (purely a convenience macro – should I get rid of it?)
* Some holdouts from Python 2 are allowed: PyLong_*,
* Things that aren't in Python 2 are not added (unless necessary)
The list will grow a bit, but throughout the porting phase (where
volunteers maintain the Python 3 port without getting in the way), it
should be clear what the ported parts do when you read them – even if
you know Python 2 only; if you also know py3 it should be also clear
when you write them.
After the switch, it should be clear what the transitional parts do,
even if you know Python 3 only.
If you need a bigger module than talloc to get a feel for what
reading/modifying the transitional C code would look like, see the WIP
patches I posted for ldb/tdb. It will be worse (to reduce the "b" prefix
in Python code), but not by that much.
More information about the samba-technical