[C++-sig] Re: Refactoring, Compilation Speed, Pyste, Lua/Ruby/JavaScript...

Brett Calcott brett.calcott at paradise.net.nz
Thu Jun 19 13:53:34 CEST 2003


"David Abrahams" <dave at boost-consulting.com> wrote :
>
> Please know that I take my own response with a grain of salt; if
> potential contributors really think they want the presentation you
> describe, who am I to argue?
>

Hmm. maybe finding the 'right way' might take time. You say you don't
know the right questions to ask, but I don't think I do yet either.

> >
> > Deal. It be a bit slow at first as I am relocating to another
> > country in the next 10 days (NZ -> Aussie)
>
> Interesting change.  How come?
>

I'm giving up my paying job (programming) to go and do a PhD in
Philosophy at the Australian National University. I'll be using
boost.python to do some stuff for my thesis :)

>
> > I'd like to approach it as though we are trying to write a
> > simplified version of boost.python, ignoring compiler workarounds,
> > and not using the preproc. We'll show a coded python C extension, an
> > equivalent in boost.python syntax, then go through the structures
> > needed for the boost.python code to generate the equivalently
> > operating C extension code that we initially showed.
>
> I think that sounds like it will cover a lot of details that nobody
> needs to see, and in particular there are many things supported by
> Boost.Python (derived<->base conversions, overloading, even simple
> stuff like classes and static method support) that we don't know how
> to do in 'C' without replicating large swaths of Boost.Python
> functionality so the document would end up being as much about 'C'
> extension writing as about Boost.Python internals.

Right, but we can simply not do this stuff (at first anyway).

>
> I'm hoping that this document will be useful to other people who want
> to be involved with the project (and *me* as well), and I worry that
> by starting from the top level, what you're describing will fail to
> illuminate the architecture of Boost.Python, which IMO is the real
> obstacle to understanding the implementation.
>
> a. I think you need to understand much of the detail.
>
> b. The code generated by Boost.Python isn't equivalent to the above in
>    any trivial sense. Almost everything in traditional 'C' extension
>    building is geared towards initializing arrays of (function)
>    pointers and constants which the Python core treats almost as a
>    program, interpreting elements of the array and generating Python
>    objects (e.g. callables) from them.  Boost.Python doesn't/can't
>    take advantage of these mechanisms, so it builds the Python objects
>    directly.  I guess what I'm saying is that the mapping is not very
>    direct so I don't see a comparison with the 'C' API extension is
>    going to help.
>

Well ok. But looking at class.cpp I can see the standard python structs
that you see in a C extension. So you must start with these, right?

> If you are convinced this is the right way to go, I'm still happy to
> help and answer questions.  I would prefer to do a bottom-up
> description, starting with the core and working outward... especially
> because it would help the luabind people who are interested in
> integration with Boost.Python.  A top-down description will always be
> describing new things in terms of their components which are concepts
> nobody understands yet.  I'm not going to argue too strongly with
> anyone who's volunteering, though!
>

And the advantage to starting top-down is that it gives a motivation to
what you are trying to achieve. The architecture of Boost.Python comes
from the motivation to use a simple syntax to generate a complex
interface. 'How' makes a lot more sense when you know 'why'.

Perhaps we should just start in a corner and work our way around in the
most interesting direction.  Why not try the following: We start a
conversation here directed at exposing the architecture (rather than
getting my code compiling) - I copy abstracts from the conversation into
Structured Text onto a Wiki page where they can be edited and added to.
Using a Wiki means we can head off on tangents, leave terms or whole
sections to be defined later on, and easily include active links to
code, Python C extensions, and template tutorials. All of which will be
needed I think.

Where is a Wiki we can use?
Where shall we start :)

Cheers,
Brett









More information about the Cplusplus-sig mailing list