I have some functions in C++ that take a void *, for example hexdump(). The main use of this, obviously, is to pass a buffer and get the hex dump as a return value - without having to worry about the type passed, eg: std::string str("This is a test"); hexdump(str.data(), str.length()); std::wstring wstr(L"This is a test") hexdump(str.data(), str.length() * sizeof(wchar_t)); I want to know the best way of exposing such a function to python without being too 'string specific' (theres no reason I couldn't do hexdump(&some_int, sizeof(int)) in C++, so I want something similar in python, if I can get it). Now hexdump is only an example, I have a few other functions that do the same (for example, recv() and send() in a socket class). Any ideas would be appreciated. Right now, the best thing I can think of is to create a wrapper function (for use in the python interface only) that accepts a std::string/std::wstring and calls hexdump, however this hamstrings me when I want to do things like integers, or complex structures. Also, on another note, is there somewhere that has all of boost already pythonized? I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)
Preston, The best place for Boost.Python questions is the C++-sig: http://www.boost.org/more/mailing_lists.htm#cplussig "Preston A. Elder" <prez@neuromancy.net> writes:
I have some functions in C++ that take a void *, for example hexdump(). The main use of this, obviously, is to pass a buffer and get the hex dump as a return value - without having to worry about the type passed, eg:
std::string str("This is a test"); hexdump(str.data(), str.length());
std::wstring wstr(L"This is a test") hexdump(str.data(), str.length() * sizeof(wchar_t));
I want to know the best way of exposing such a function to python without being too 'string specific' (theres no reason I couldn't do hexdump(&some_int, sizeof(int)) in C++, so I want something similar in python, if I can get it).
You have to decide what kind of interface you want in Python; nobody can tell you what that should be. Write down some examples of Python code showing what you'd like to be able to do with hexdump.
Now hexdump is only an example, I have a few other functions that do the same (for example, recv() and send() in a socket class).
Any ideas would be appreciated. Right now, the best thing I can think of is to create a wrapper function (for use in the python interface only) that accepts a std::string/std::wstring and calls hexdump, however this hamstrings me when I want to do things like integers, or complex structures.
Unless you can come up with some code that can take an arbitrary complex structure and magically produce a contiguous array of bytes for hexdump to work on, I think you're out of luck.
Also, on another note, is there somewhere that has all of boost already pythonized?
No.
I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;)
It seems unlikely to me. Because so much of Boost is heavily templated generic code, a great deal of it would make no sense as Python wrappers. Can you imagine Pythonizing the Boost.Python library? ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
Somewhere in the E.U., le 11/02/2005 Bonjour In article <uy8ekakyq.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
Preston,
The best place for Boost.Python questions is the C++-sig: http://www.boost.org/more/mailing_lists.htm#cplussig
"Preston A. Elder" <prez@neuromancy.net> writes:
[SNIP]
Also, on another note, is there somewhere that has all of boost already pythonized?
No.
I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;)
It seems unlikely to me. Because so much of Boost is heavily templated generic code, a great deal of it would make no sense as Python wrappers. Can you imagine Pythonizing the Boost.Python library? ;-)
As an organizational note, what would be best, when we add more conversions to Python? Various pieces bundled with the lib's doc, or in a centralized location TBD? Hubert Holin
On Fri, 11 Feb 2005 16:09:58 +0100, Hubert Holin wrote:
As an organizational note, what would be best, when we add more conversions to Python? Various pieces bundled with the lib's doc, or in a centralized location TBD?
Not really sure what you mean? I've centralized the python conversions for my own project, which you can see here: http://www.neuromancy.net/viewcvs/Mantra-I/python/?root=mantra You will note that in the 'boost' directory I have added some conversions for things like boost::format, boost::date_time, and boost::logic::tribool. Basically just the things I needed boost conversions for :) Oh, and as a side-note, my void * problem, for now, I've got around with VoidBuf in core/utils.cpp (with the C++ class defined in my python.h). Its a poxy solution, but it works. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)
Somewhere in the E.U., le 14/02/2005 Bonjour In article <pan.2005.02.11.22.41.31.665443@neuromancy.net>, "Preston A. Elder" <prez@neuromancy.net> wrote:
On Fri, 11 Feb 2005 16:09:58 +0100, Hubert Holin wrote:
As an organizational note, what would be best, when we add more conversions to Python? Various pieces bundled with the lib's doc, or in a centralized location TBD?
Not really sure what you mean?
I've centralized the python conversions for my own project, which you can see here:
http://www.neuromancy.net/viewcvs/Mantra-I/python/?root=mantra
You will note that in the 'boost' directory I have added some conversions for things like boost::format, boost::date_time, and boost::logic::tribool.
Basically just the things I needed boost conversions for :)
[SNIP] My question was regarding wether or not we had specified a way to put any existing conversion within the Boost directory structure. We could upload these to a site such as yours, but perhaps proximity to the libraries they are based on would be desirable... Merci Hubert Holin
Hubert Holin <Hubert.Holin@meteo.fr> writes:
Somewhere in the E.U., le 14/02/2005
Bonjour
In article <pan.2005.02.11.22.41.31.665443@neuromancy.net>, "Preston A. Elder" <prez@neuromancy.net> wrote:
On Fri, 11 Feb 2005 16:09:58 +0100, Hubert Holin wrote:
As an organizational note, what would be best, when we add more conversions to Python? Various pieces bundled with the lib's doc, or in a centralized location TBD?
Not really sure what you mean?
I've centralized the python conversions for my own project, which you can see here:
http://www.neuromancy.net/viewcvs/Mantra-I/python/?root=mantra
You will note that in the 'boost' directory I have added some conversions for things like boost::format, boost::date_time, and boost::logic::tribool.
Basically just the things I needed boost conversions for :)
[SNIP]
My question was regarding wether or not we had specified a way to put any existing conversion within the Boost directory structure. We could upload these to a site such as yours, but perhaps proximity to the libraries they are based on would be desirable...
I'd put it under the Boost.Python library, but I think some people would be upset at Boost.Python's resulting apparent dependency on all the wrapped libraries. To get around that problem, I think we need a separate boost library called python-bindings. Or is it a non-problem? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Somewhere in the E.U., le 15/02/2005 Bonjour In article <ur7jj9not.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
Hubert Holin <Hubert.Holin@meteo.fr> writes:
[SNIP]
My question was regarding wether or not we had specified a way to put any existing conversion within the Boost directory structure. We could upload these to a site such as yours, but perhaps proximity to the libraries they are based on would be desirable...
I'd put it under the Boost.Python library, but I think some people would be upset at Boost.Python's resulting apparent dependency on all the wrapped libraries.
To get around that problem, I think we need a separate boost library called python-bindings. Or is it a non-problem?
Well, a separate library has at least one problem: the need for someone in charge of its maintenance. But it also has huge advantages: it is a central gathering point and quality can be insured via regression tests (perhaps part of the general regression tests carried out before a new version of Boost is released). Furthermore, Boost.Python is likely to be the first place people will be looking for these bindings, so perhaps an intermediary solution is in order, if a maintainer for a separate library can't be found: a page within Boost.Python's documentation linking to these bindings which can be clearly marked as not being prerequisites for B.P, and the maintenance of which (the binding's) is under the responsibility of somebody else (the bound library's author or someone else). Or perhaps, putting even less burden on B.P, a Wiki page with that info, referenced from within B.P's documentation. Under this scenario, quality (of the bindings) is not ensured, but perhaps bindings per se lie beyond the purview of Boost, so this point does not matter much. Merci Hubert Holin
somebody else (the bound library's author or someone else). Or perhaps, putting even less burden on B.P, a Wiki page with that info, referenced from within B.P's documentation. Under this scenario, quality (of the bindings) is not ensured, but perhaps bindings per se lie beyond the purview of Boost, so this point does not matter much. I'm not sure I like this. If this module, whether part of Boost.Python or a separate library (or collection of libraries), it would have a
On Tue, 15 Feb 2005 10:20:08 +0100, Hubert Holin wrote: maintainer, and thus have two distinct advantages. 1) someone who will ensure as major updates happen, these modules are kept up to date (at least at release time). and 2) someone who is intimate, at least with boost.python, but probably at least passingly with the ported functions. Not to mention that someone who is a maintainer is more likely to ensure a good job is done, including things like exposing boost exceptions, etc. After all, as maintainer, its their name on the code/module :) As for library dependencies, there is no need for this to be one big python object (in .so or .dll form). In fact, it should probably take on a similar role to what I've created, with a different python object for each boost module ported (ie. boost::format is separate from boost::date_time, etc). If this is kept to, the only dependencies for each python object would be the boost module it converts (and boost.python, of course). I'm assuming if this was done right, a 'boost' directory would be created under python's object scan path (often /usr/lib/pythonX.X/site-packages or something), inside that directory would be all the boost interface modules (one for each boost module, or more if finer granularity is required). I'm not seeing the issue with library dependencies then. Though obviously the python objects would have to be built after boost has completed building, and not built at all if boost.python was not supported. This said, it sounds like its a better idea to have as a separate module to boost.python - even if only for compile-order simplicity and documentation (which will be interesting, since for the most part, the documentation would be 'interface is the same as X module, with the following differences ...'). Thats my not-so-humble opinion :) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)
Somewhere in the E.U., le 16/02/2005
Bonjour
In article <pan.2005.02.15.10.35.57.65278@neuromancy.net>,
"Preston A. Elder" <prez@neuromancy.net> wrote:
> On Tue, 15 Feb 2005 10:20:08 +0100, Hubert Holin wrote:
>
> > somebody else (the bound library's author or someone else). Or perhaps,
> > putting even less burden on B.P, a Wiki page with that info, referenced
> > from within B.P's documentation. Under this scenario, quality (of the
> > bindings) is not ensured, but perhaps bindings per se lie beyond the
> > purview of Boost, so this point does not matter much.
> I'm not sure I like this. If this module, whether part of Boost.Python or
> a separate library (or collection of libraries), it would have a
> maintainer, and thus have two distinct advantages.
> 1) someone who will ensure as major updates happen, these modules are kept
> up to date (at least at release time).
> and 2) someone who is intimate, at least with boost.python, but probably
> at least passingly with the ported functions.
I agree that a full-fledged library would be the best solution.
> Not to mention that someone who is a maintainer is more likely to ensure a
> good job is done, including things like exposing boost exceptions, etc.
> After all, as maintainer, its their name on the code/module :)
The biggest stumbling block, however, is that we would need a
volunteer for that new library (wink wink, nudge nudge)!
> As for library dependencies, there is no need for this to be one big
> python object (in .so or .dll form). In fact, it should probably take on
> a similar role to what I've created, with a different python object for
> each boost module ported (ie. boost::format is separate from
> boost::date_time, etc). If this is kept to, the only dependencies for
> each python object would be the boost module it converts (and
> boost.python, of course).
>
> I'm assuming if this was done right, a 'boost' directory would be created
> under python's object scan path (often /usr/lib/pythonX.X/site-packages or
> something), inside that directory would be all the boost interface modules
> (one for each boost module, or more if finer granularity is required).
>
> I'm not seeing the issue with library dependencies then. Though obviously
> the python objects would have to be built after boost has completed
> building, and not built at all if boost.python was not supported.
>
> This said, it sounds like its a better idea to have as a separate module
> to boost.python - even if only for compile-order simplicity and
> documentation (which will be interesting, since for the most part, the
> documentation would be 'interface is the same as X module, with the
> following differences ...').
>
> Thats my not-so-humble opinion :)
A secondary point is that, even though it would be a project based
upon Boost libraries, it has an "unusual" dependency: a language other
than C++ (well, so does Boost.Python, so this is definitely not a
show-stopper). I do not know if the same format as for the other
libraries could be used for the review that library in light of that
fact (I was not around for the review of B.P).
Merci
Hubert Holin
participants (3)
-
David Abrahams -
Hubert Holin -
Preston A. Elder