[C++-sig] [Boost.Python v3] Conversions and Registries

[Jim Bosch]

On 10/05/2011 03:28 PM, Niall Douglas wrote:
> On 5 Oct 2011 at 9:18, Jim Bosch wrote:
>
>> I think this might turn into something that approaches the same mass of
>> complexity Niall describes, because a Python module can be imported into
>> several places in a hierarchy at once, and it seems we'd have to track
>> which instance of the module is active in order to resolve those scopes
>> correctly.
>>
>> I do hope that most people won't mind if I don't implement something as
>> completely general as what Niall has described - there is a lot of
>> complexity there I think most users don't need, and I hope he'd be
>> willing to help with that if he does need to deal with e.g. passing
>> callbacks between multiple interpreters.  But I'm also afraid he might
>> be onto something in pointing out that fixing the more standard cases
>> might already be more complicated than it seems.
>
> It's really not that complex when implemented, honestly. It's just
> complex creating that simple design to cover all the possible use
> cases. Once the design is down, you'd be amazed at how little code it
> turns into.
>
> Obviously Jim, you're the one who's implementing it, so you do what
> you like. However, I would suggest that you might consider setting up
> a wiki page on Boost's trac (https://svn.boost.org/trac/boost/ ?)
> describing the proposed design in detail.
>
> I'm also happy to offer a full project management host for your
> efforts on ned Productions' Redmine site
> (http://www.nedproductions.biz/redmine/) if you'd prefer. You'd get
> your own full self-contained project there.
>

Thanks for the suggestion and the offer.  I should probably just go with 
getting a boost trac account; there are some aspects of trac I dislike, 
but it's also what I know, and I very much doubt my needs will exceed 
its abilities in this case.

But this is indeed approaching the point where we need a concrete 
straw-man to pummel.

> In either case, I'm sure people from the list here would be happy to
> comment and/or contribute to the design document even if they are
> unable to contribute code.

Good to hear!

Jim