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

[Jelmer Vernooij]

On Wed, Mar 04, 2015 at 11:18:08AM +1300, Andrew Bartlett wrote:
> On Tue, 2015-03-03 at 22:09 +0100, Jelmer Vernooij wrote:
> > On Mon, Mar 02, 2015 at 12:09:25PM +0100, Petr Viktorin wrote:
> > > On 02/26/2015 11:36 PM, Andrew Bartlett wrote:
> > > >On Thu, 2015-02-26 at 12:23 +0100, Petr Viktorin wrote:
> > > >>On 02/25/2015 07:53 PM, Andrew Bartlett wrote:
> > As for the Samba Python modules, the balance is different there. Samba
> > has *a lot* more Python code and C Python bindings. There are fewer
> > unit tests for that code but many more integration tests for Samba
> > overall. We don't want "make test" to run the entire testsuite twice,
> > once with each Python version, and on top of that we are less
> > likely to catch Python compatibility issues just by running the Python
> > module unit tests.
> > 
> > There are also fewer external users of the Samba Python modules; at
> > this point I'm only aware of OpenChange and FreeIPA.
> > 
> > It would require a non-trivial extra amount of effort on part of the Samba
> > developers to maintain support for two Python versions; see the
> > earlier thread for a more detailed of why I think supporting two
> > Python versions would require extra resources and why I think this is
> > not worth it.
> > 
> > That said, if somebody wants to put the effort in to port Samba to
> > another major Python version (e.g.: 3), I would like to accomodate
> > them if possible. However, such an effort should minimize the burden
> > on the rest of Samba development. I would suggest the following
> > constraints on support for additional major Python versions:
> > 
> >  * It shouldn't clutter the code with lots of compatibility wrappers
> >    that make the code unreadable.
> 
> I'm sorry to hear earlier in the thread that there are no efforts to
> have a compatibility API for the C interface, because it seems that in
> Samba, we already do have a good separation between bytes and unicode,
> because we care to be null-termination safe.  
> 
> That is, length-limited strings are byte arrays, null terminated strings
> are utf8 strings.  Within those rules, and within Jelmer's stipulation
> above, I would like to see a library that implements the Python3 C API
> in terms of python2.  Then we could port Samba to that, one module at a
> time.  It wouldn't make the code unreadable, because it would be the
> Python3 API.  I might permit a small number of #ifdefs, but these too
> make the code unreadable. 
FWIW I am very skeptical that such a (python3 on top of python2 API) wrapper
would be possible, especially in a way that makes it less painful than #ifdefs.

It might have been possible if the Python3 API had been designed with such
a compatibility layer in mind, but it hasn't.

Cheers,

Jelmer