Am 26.08.2011 um 20:25 schrieb Jim Bosch:
> - … the rvalue converters in particular don't seem to have been intended as
part of the public API originally, and I think they're an important part of
the library.
Correct, great!
> - Automatic conversions for newer boost libraries (Fusion, Pointer
On 08/26/2011 08:21 PM, Jim Bosch wrote:
> On 08/26/2011 04:47 PM, Neal Becker wrote:
>> The top of my list is improved interface to numpy. I know there is
>> work going
>> on in the form of ndarray, which seems promising.
>
> I'm still hesitant to consider ndarray part of Boost.Python; it's
> rea
On 08/26/2011 04:09 PM, Dave Abrahams wrote:
> on Thu Aug 25 2011, Stefan Seefeld wrote:
>> Jim,
>>
>> this is an interesting idea. There has been lots of general (dare I
>> say generic ?) discussion concerning process improvements (which
>> unfortunately most of the time diverted into tool discus
On 08/26/2011 04:47 PM, Neal Becker wrote:
The top of my list is improved interface to numpy. I know there is work going
on in the form of ndarray, which seems promising.
I'm still hesitant to consider ndarray part of Boost.Python; it's really
a separate library, and I think providing a full
The top of my list is improved interface to numpy. I know there is work going
on in the form of ndarray, which seems promising.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Trying to catch up here, so responding to everything all at once.
on Thu Aug 25 2011, Jim Bosch wrote:
Just how tall are you, Jimbo?
> I'd like to start work on a new major release of Boost.Python.
That certainly is welcome news.
> While the library is currently well-maintained in terms of
On 08/25/2011 04:26 PM, Ralf Grosse-Kunstleve wrote:
Hi Jim,
CC to Dave.
This is great news.
My main interests have been stability and not increasing the memory
footprint of boost.python extensions. I'm not in a position to further
develop boost.python.
Troy and Ravi have done a significant amo
On 08/26/2011 04:17 AM, Neal Becker wrote:
What sort of improvements did you have in mind?
My list includes:
- Propagating constness to Python (essentially already done as an
extension, but it could have a much nicer interface if I could mess with
class_ itself).
- Make custom registry and
On 08/26/2011 01:28 PM, Niall Douglas wrote:
> BTW, how has the Python3k port worked out? I'm not sure if it's been
> mainlined yet has it? Best of luck! Niall
I'm not using Python 3k myself, so I can't comment, but the P3K port
most definitely went into trunk and has been part of the last couple
On 25 Aug 2011 at 13:59, Jim Bosch wrote:
> - For other Boost.Python experts on this list: do you have existing code
> or development time you'd like to contribute?
Firstly, I must commend you as you're a better man than I for
initiating this. I mostly chase money these past few years, and I
d
On 08/26/2011 07:17 AM, Neal Becker wrote:
> What sort of improvements did you have in mind?
Two things on my list that are likely going to be somewhat disruptive are:
* Support for subclassing boost.python's own metaclass.
* A per-module type registry, to avoid conflicting converters in
multi-mo
What sort of improvements did you have in mind?
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Hi Jim,
CC to Dave.
This is great news.
My main interests have been stability and not increasing the memory
footprint of boost.python extensions. I'm not in a position to further
develop boost.python.
Troy and Ravi have done a significant amount of work. I hope they will
comment for themselves.
I
On 08/25/2011 04:59 PM, Jim Bosch wrote:
>
> To that end, I'm inclined to copy the library to somewhere else
> (possibly the boost sandbox, but more likely a separate site), work on
> it, produce some minor releases, and re-submit it to Boost for review.
> Perhaps the external site would continue o
I'd like to start work on a new major release of Boost.Python. While
the library is currently well-maintained in terms of bugfixes, I get the
sense that neither the original developers nor the current maintainer
have the time or inclination to work on new features. I'd also like to
propose so
15 matches
Mail list logo
