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

Andrew Bartlett abartlet at samba.org
Sat Mar 14 03:17:36 MDT 2015

On Fri, 2015-03-13 at 14:00 +0100, Petr Viktorin wrote:
> 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)

Can't we code to the Python3 API, and have it map both to python2
strings, either as raw bytes or pushing (presumed internal mapping) UTF8
to UTF8?  (Yes, we really should use the unix charset, but these parts
of samba without unix charset == utf8 is just broken). 

> * 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.

Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

More information about the samba-technical mailing list