[Xcb] Remove Python as a XCB dependency.

[Barton C Massey]

Thanks for the suggestion, but I don't think the current XCB
team has any interest in cutting the bindings loose from the
generator.  I know I don't.

XCB is deliberately built in such a way that the language
bindings are automatically derived from the XML protocol
specifications.  This has several important benefits.

  * Errors in the XML can be fixed in the XML, and the
    binding code can be automatically re-derived for all
    supported programming languages without chance for
    further compounding the errors.  This does still
    occasionally come up.

  * New protocol can be described in XML rather than by
    binding code in a particular programming language; this
    works out a lot better in our experience, especially
    since the default language has been C.

  * The binding APIs are guaranteed by construction to
    reflect the naming and structure of the protocol.  There
    is a clear demarcation between code written manually for
    a particular language, and code that should not be.
    This helps the developers and users understand what is
    happening.
    
For all these reasons, it would be infeasible and unwise to
kill the generation from Python.


While I, unlike some of the other developers, have some
sympathy for the idea that we should ship generated C code
*in addition* to giving the ability to regenerate it, I
freely acknowledge that this approach has its own problems.
In particular:

  * The way the XCB repositories are currently split up
    there is an opportunity for version skew errors.  This
    could be fixed, but it would be a major restructuring.

  * It's 2009.  Python shouldn't be a dependency all that
    hard to satisfy in any reasonable situation.  The
    language was chosen partly because it is cross-platform
    and runs code in a portable way.  So it appears that the
    development team is being asked to do a lot of work so
    that a few corner-case collaborators can avoid some.  If
    we had a larger team, that would be a more reasonable
    thing to ask.


I think it would be great if we can find some solutions to
some key problems with the current setup.  In particular, we
need to find a better way of syncing releases of at least
proto, libxcb and libX11 so that the version skew problems
users experience are minimized.  Note, however, that this
issue is largely orthogonal to Python or code generation.


I don't mean to minimize the substantial problems with the
XCB / Xlib developer and user experience to date.  We
certainly want to help folks succeed and not disrupt their
work.  That said, I think it's been a remarkably smooth
transition so far given its scope and impact.

Again, thanks for your input.

	Bart

In message <cbc95d950903191944h6fb15b04rbdf870afc5a44d34 at mail.gmail.com> you wrote:
> I seen this come up on the list time and time again and its just
> becoming very clear that the python C binding generator is a overkill
> and is more trouble then its worth.
> Here is my reasoning;
> As XCB is a base package for a modern X server build it should have
> little to no dependencies and particular over convoluted ones if they
> can be avoided.
> Further to this, constant changes in python create more development
> (and documentation, such as answer questions 'why my xcb does not
> build with version foo') overhead to the XCB development team just
> taking away time from more pressing matters. Also, the python
> dependency creates unnecessary overhead for package maintainers of XCB
> with no real significant gain for the time spent on it. I there
> believe and would like to request that proto merged back into libxcb
> and the C bindings be delivered as part of the whole sha-bang.
> 
> Thanks for your time,
> Edward O'Callaghan.