[PATCHES] Build pytalloc for two Python versions at once, port to py3

Petr Viktorin 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 
they are:

* 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_*, 
Py_TPFLAGS_HAVE_{WEAKREFS,ITER}
* 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.

-- 
Petr Viktorin



More information about the samba-technical mailing list