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

[Petr Viktorin]

On 03/19/2015 02:26 PM, Jelmer Vernooij wrote:
> On 19 March 2015 9:10:38 am GMT+00:00, Petr Viktorin <pviktori at redhat.com> wrote:
>>
>> Are you now saying that supporting Python 3 in thestand-alone libraries
>>
>> is a bad idea?
> I don't think that is a bad idea for the standalone libraries. We're concerned
> about the longevity of dual-python support though, especially in Samba itself.
>
>> Can you tell me what hoops are a burden, so I can try removing them?
> Supporting two python versions at the same time and all the issues that
> come with that. I think the specifics have been well covered in this thread.

Somehow, the discussions always turns to potential Python3 support in 
Samba itself. Unless I misunderstood, most of the specifics mentioned in 
the thread are about that.
Not that it's not a good discussion -- I'm not saying I don't want Samba 
ported eventually, and I'm starting to put into action some ideas to 
make the ecosystem better for Samba when it does decide to port -- but 
the main thing I'm asking for in this thread is patch review. It's hard 
to separate comments on eventual porting of Samba from comments on the 
porting stand-alone libraries. If it looks like I'm stubbornly ignoring 
some issues raised on the patches, this might be what I misunderstood.

Is there anything I can do to make the build system and talloc patches 
better?
Should I first complete porting the other stand-alone libraries, and 
present a giant set of patches then? In other words, is having talloc 
ported useless without the other stand-alone libraries being ported as 
well? I know the other libraries will have issues with unicode/bytes; 
pytalloc does not.
I think a giant patchset would complicate things for reviewers as well 
as for me, but if you'd prefer it, I can go hack on it. Even then, if 
you have any comments on the changes at hand, I'd like to hear them so I 
don't have to rebase so much down the road.

If the extra header is too much, I can move the macros into the c files. 
(I'd personally prefer not to do that, so that it's easier to re-use 
them consistently across all standalone libraries. But I can move them 
if you wish.)

-- 
Petr Viktorin