"David Abrahams" <dave@[...].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






_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig