[PATCHES] Port pytalloc to Python 3

[José A. Rivera]

I'll chime in as a general Python user that has no immediate interest in
using Python3. I've seen no real need/interest among my personal network of
fellow Pythonistas to undertake the transition, either. It is a rather
divisive topic, but in general I favor a more inclusive solution should we
have the resources to maintain it.

--Jose

On Mon, Dec 8, 2014 at 10:30 AM, Alexander Bokovoy <ab at samba.org> wrote:

> On Mon, Dec 8, 2014 at 5:44 PM, Jelmer Vernooij <jelmer at samba.org> wrote:
> > On Mon, Dec 08, 2014 at 10:12:08AM -0500, Simo wrote:
> >> On Mon, 2014-12-08 at 14:22 +0100, Petr Viktorin wrote:
> >> > On 12/05/2014 02:50 PM, Alexander Bokovoy wrote:
> >> > > On Fri, Dec 5, 2014 at 2:27 PM, Petr Viktorin <pviktori at redhat.com>
> wrote:
> >> > >>>>> For talloc, tdb and ldb it makes sense to support both python2
> and
> >> > >>>>> python3. For Samba itself, the burden of maintaining support
> for both
> >> > >>>>> is much higher, and the benefits smaller.
> >> > >>>>
> >> > >>>> Yes. However, talloc/tdb/ldb support for both Python2 and Python3
> >> > >>>> means there is need to improve our build system to support both
> Python
> >> > >>>> versions so this task is relevant.
> >> > >>
> >> > >>
> >> > >> Just to clarify: Are you just saying it needs to be possible to
> build Samba
> >> > >> with Python 3?
> >> > >> Or are you proposing that the modules for both Python 2 and 3 be
> built in
> >> > >> the same configure/make run? It seems (to me, currently) that this
> would
> >> > >> require rather big changes in Waf, while a configure-time switch
> for the
> >> > >> Python version is practically free.
> >> > > The latter because how otherwise would you be able to package both
> >> > > python2 and python3 modules when packaging Samba?
> >> > > We are not going to have two more samba packages differing in their
> >> > > python bindings.
> >> >
> >> > Right.
> >> > Since that the stand-alone libraries will need to support both
> versions
> >> > for a longer time, it does make sense to invest in adding this to the
> >> > build system. I'll put some effort into that.
> >> >
> >>
> >> I do not think it is reasonable to drop Python 2 support in the short
> >> term. We have a ton of people still recompiling and installing on older
> >> OSs that do not have Python 3, and I am not talking only about
> >> RHEL/CentOS 6 or older Ubuntu LTS but also other Unix flavors.
> > Python3 was released in 2008. All supported Ubuntu LTS releases (lucid
> and
> > later) ship Python3. Does RHEL 6 not?
> No, it does not, and RHEL7 does not ship Python3 in the base either.
> We (Red Hat) are willing to work on Python 3 support to eventually get
> everything off the Python2 but reality is much different. Python2
> support was extended to 2020 "thanks" to realization that people are
> using this language actively and many of those use cases have no
> incentives to move over to a slightly different language named
> Python3.
>
> So killing Python2 support in Samba would be short-sighted. However,
> Petr's team (Developer Experience) is looking forward to ease Python
> bindings maintenance burden so that both Python2 and Python3 bindings
> can co-exist in Samba.
>
> >> Forcing people to recompile Python 3 on those systems just to get Samba
> >> to run on them seem a little bit excessive. (And please do not propose
> >> to embed a version of python3 in our sources or my head will explode! :)
> > I agree shipping Python3 sources is a terrible idea. :-)
> >
> > This would only affect those people that want a new *major* version of
> Samba
> > and run an OS that ships Python2 but not Python3, in a year from now. Is
> > that really going to affect more than a handful of people?
> >
> > If these users are really an issue, then let's just wait some more time
> until
> > we attempt a migration from Python2 to Python3.
> Maybe. Let's see how large will be the effort to make Python2 and
> Python3 bindings buildable in waf that Petr is looking at now.
> This is something that will be required anyway for libraries and can
> be used as a canary to see how far can we go.
>
> --
> / Alexander Bokovoy
>