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. 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. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
