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

[Petr Viktorin]

On 03/12/2015 02:09 PM, Jelmer Vernooij wrote:
> On Thu, Mar 12, 2015 at 12:08:48PM +0100, Petr Viktorin wrote:
>> On 03/05/2015 10:08 PM, Andrew Bartlett wrote:
>>> On Wed, 2015-03-04 at 15:53 +0100, Jelmer Vernooij wrote:
>>>> 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:
>>> Petr,
>>>
>>> The reason I'm being so awkward is that I don't like any of the options.
>>>   - waiting forever means we:
>>>    - push aside your valuable contributions
>>>    - may never make the move
>>
>> I don't think the second point is true; you'd be forced to make the move
>> eventually, most likely when Python 2 support ends in 5 years. It's good not
>> to rush things, but waiting forever is hardly an option -- it would just
>> make us rush things later.
>
> If we move later, it saves us from a couple of years of juggling support
> for two different Python versions. In fact, if we move late enough, we might
> be able to just drop Python2 support altogether and just port to Python3 rather
> than supporting both versions.

If there were no dependencies, there might be a chance of that working.
However, if you want to coordinate with FreeIPA or distros, it becomes 
somewhat harder.
Also, allowing more time for the port would improve chances to do thigs 
right, rather than rushing them all at once to avoid "juggling".
I liked Andrew's suggestion to support only Python 2, but start putting 
unsupported py3 bits in "unofficially", so dependent projects can start 
preparing their own py3 support before the big switch.

>>>   - waiting for things to improve:
>>>    - you suggest is foolish, there is no indication that the python community will
>>>    - and we don't know that someone else will be keen to do the work in the future
>>
>> Also, there's a non-trivial chance that my work on Samba could drive these
>> improvements.
>> It's been suggested a CPython list that I write a porting guide for C code.
>> I'm quite tempted to share what I write for Samba.
>
> Thanks! Upstream improvements to make it easier to support both versions
> would be great.

Just note I wrote *porting guide*, not upstream code.

> I think defines to make it easier to compile 2.6 C code with Python3 belong
> in an upstream header (perhaps hidden behind and #ifdef _COMPAT_PYTHON26 or
> with a deprecation warning), rather than in every Python projects' source
> tree.

I don't think that is going to happen in Python itself. I can however 
make a library in the spirit of six/future for C extensions. And I 
probably could get it to be mentioned in Python docs as a best practice 
(along with Cython/cffi).

>>>    - risks restricting developers to the cumbersome common subset - yet another language, essentially
>>
>> That mostly applies to Python source. In the C extensions, alternatives to
>> the removed things have usually been ported to Python 2.6, so not even an
>> #ifdef is necesary. The main problem is deciding between bytes and unicode.
>
> There are already quite a number of ifdefs in the current set of patches, and
> this is a fairly simple module..

The ifdefs are all* in one header file, which works for tdb & ldb as 
well. The header would be much smaller if it was just for pytalloc.

-- 
Petr Viktorin

-- 

* well, except one for pytalloc_CObject_FromTallocPtr