Fw: [PROPOSAL] To retire autoconf for 4.1

[Alexander Bokovoy]

On Fri, May 24, 2013 at 07:49:10PM +0200, Jelmer Vernooij wrote:
> > We use the python binding for dcerpc and related stuff in FreeIPA
> > for example.
> > I'll let Alexander give a list, as he was the one that did the
> > research and started using the bindings.
> Assuming that's all you need, I suspect supporting those for both versions
> is a lot more achievable than blanket support of all our Python code on
> both 2.x and 3.x.
Majority of what we use is indeed autogenerated. However, we rely on
security and param, and few others which are manually coded. So there is
still amount of work to port to any changed module API.

> To manage expectations, I still think it would be good if we clarified what
> we do and don't plan on doing with regard to the external use of various Python
> APIs.
I think actual issue is to find out what we use in our Python bindings
willingfully from Python module APIs and Python language features that
would change between 2 and 3. Strings are one part but most of other
APIs are hardly influencing complexity of maintaining the ports.
After all, we are not using CObject API so we don't need to migrate to
Capsule, and module initialization part is easy to rewrite.

Also, at Python level (as opposed to currently discussed Python C API) we
also don't need many of specific Python language features. We hardly are
beyond exceptions, iterators and dicts. Majority of new syntax is
backported as back as Python 2.6 which is what we rely on right now.

So I think the issue of maintaining support for both 2.6+ and 3.2+ is
rather question of having someone to come up and do actual work. 

> > True, so my question is, given most of the bindings are partially
> > autogenerated, is there a way we can reduce the developer pain by
> > using some abstraction perhaps ?
> The DCE/RPC bindings are almost entirely generated. There are a lot of other
> bindings written in C that are not, but it sounds like you guys don't actually
> need those?

Some of those we need like smb.conf management and security.

> So in summary, if there is a small subset you need to be available for both
> Python 2.x and 3.x then that is a lot more achievable than making everything
> available for both - and considering the code you are using is probably more stable
> and less prone to changes, there will probably also be less friction in keeping
> it working with both.
I think what we need to proactively come up with is a research how to
perform bytes/strings management that is compliant to both Python 2.6+
and 3.2+. That should be a first step and it will show how large is the
overall task.

-- 
/ Alexander Bokovoy