"Brett Calcott" <brett.calcott@[...].nz>  writes:

>  "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.

I'm willing.

> > >
> > > 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 :)

Nice!

> > > 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).

It's up to you, I guess.  As long as I don't have to write working
'C' API code ;-)

>  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?

Yep.  That's a bottom-up view, though ;-)

> > 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'.

I think the tutorial shows 'why' already, but as I said, I'm willing
to leave it up to you.

>  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?

There is (http://www.python.org/cgi-bin/moinmoin/boost_2epython), but
note that it doesn't do ReST and I much prefer CVS for this sort of
thing.  I hate editing in a webpage, and I like to be able to apply
all the usual revision control tools.  I'd happily give you Boost CVS
access if you wanted to do it that way.  If you have a strong
preference for Wiki it's no problem, since you'll be doing most of the
interaction anyway.

>  Where shall we start :)

What are you interested in?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


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