Introducing Project Phoenix

wxPython Dev
1

Hi all,

As promised I've published some information about what I am calling Project Phoenix, also known as the new way to produce the wxPython wrappers that myself and others have been hinting about for a couple years now. I've moved a few of my local documents about it up to the wiki, which list some goals of the project and also a very high level view of the methodology that I think will be the way to move forward. I've done some work already on the tools and I will commit them to the repository once I get an end-to-end test working, hopefully in the next few days. For now you can read these pages to get a better feel for what I have in mind.

  http://wiki.wxpython.org/ProjectPhoenix

Comments on those pages are welcome, but I think I would prefer to have discussions here in the mail list for detailed questions, suggestions or answers.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org

2

Hi,

Quite nice to see this work planned!
I’ve spent some time binding C++ code in Python, and used both SWIG, SIP and Boost::Python, and I must say I found Boost::Python to be the cleanest and easiest to use. You can link statically against the library, so wrapped types don’t bleed out.

Nokia is currently using it for their own version of PyQt (PySide: http://www.pyside.org ), and Py++ uses it as well to generate bindings automatically ( http://www.language-binding.net/pyplusplus/pyplusplus.html )

Good luck with the transition!

Cheers,

Aloys

···

On Wed, Oct 27, 2010 at 11:37 AM, Robin Dunn robin@alldunn.com wrote:

Hi all,

As promised I’ve published some information about what I am calling Project Phoenix, also known as the new way to produce the wxPython wrappers that myself and others have been hinting about for a couple years now. I’ve moved a few of my local documents about it up to the wiki, which list some goals of the project and also a very high level view of the methodology that I think will be the way to move forward. I’ve done some work already on the tools and I will commit them to the repository once I get an end-to-end test working, hopefully in the next few days. For now you can read these pages to get a better feel for what I have in mind.

    [http://wiki.wxpython.org/ProjectPhoenix](http://wiki.wxpython.org/ProjectPhoenix)

Comments on those pages are welcome, but I think I would prefer to have discussions here in the mail list for detailed questions, suggestions or answers.

–

Robin Dunn

Software Craftsman

http://wxPython.org

–

To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-dev?hl=en

–
Aloys Baillet
Lead Software Developer
Research & Development - Animal Logic

3

Hi,

Quite nice to see this work planned!
I've spent some time binding C++ code in Python, and used both SWIG, SIP
and Boost::Python, and I must say I found Boost::Python to be the
cleanest and easiest to use. You can link statically against the
library, so wrapped types don't bleed out.
Nokia is currently using it for their own version of PyQt (PySide:
http://www.pyside.org ), and Py++ uses it as well to generate bindings
automatically ( NameBright - Coming Soon )

I've looked at Boost::Python and Py++ a little in the past, but I was a bit put off by the heavy use of templates, and gcc-xml/pygccxml were still fairly new and seemed a little flaky at the time. I'll take another look however.

Good luck with the transition!

Thanks.

···

On 10/26/10 6:13 PM, Aloys Baillet wrote:

--
Robin Dunn
Software Craftsman

4

Fair enough, boost::python can give you some funky compilation errors thanks to templates, but usually you don’t have to use them very much while writing the bindings.
It also seems that Nokia gave up on Boost Python and wrote their own binding generator: http://developer.qt.nokia.com/wiki/PySide_Binding_Generator

Not sure why they did that, but maybe worth checking as well…

Cheers,

Aloys

···

On Wed, Oct 27, 2010 at 12:29 PM, Robin Dunn robin@alldunn.com wrote:

On 10/26/10 6:13 PM, Aloys Baillet wrote:

Hi,

Quite nice to see this work planned!

I’ve spent some time binding C++ code in Python, and used both SWIG, SIP

and Boost::Python, and I must say I found Boost::Python to be the

cleanest and easiest to use. You can link statically against the

library, so wrapped types don’t bleed out.

Nokia is currently using it for their own version of PyQt (PySide:

http://www.pyside.org ), and Py++ uses it as well to generate bindings

automatically ( http://www.language-binding.net/pyplusplus/pyplusplus.html )

I’ve looked at Boost::Python and Py++ a little in the past, but I was a bit put off by the heavy use of templates, and gcc-xml/pygccxml were still fairly new and seemed a little flaky at the time. I’ll take another look however.

Good luck with the transition!

Thanks.

–

Robin Dunn

Software Craftsman

http://wxPython.org

–

To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-dev?hl=en

–
Aloys Baillet
Lead Software Developer
Research & Development - Animal Logic

5

cool -- good stuff!

Some thoughts about Cython (which I am a big fan of):

1) There has been work done on auto-generating Cython code from header files and/or XML. I don't think it's very mature, but may be worth a look-see:

(and there may be other efforts as well).

2) The C++ support seems to be under active development, and certainly of interest to the core developers.

3) Cython does provide built-in support for the new buffer interface and py3k, which should help.

What I like about Cython (and Pyrex) is that it was designed to write C extensions, rather than specifically as a wrapping tool. What this means is that it is easy to write interface code when that is required. wx has a lot of special code in SWIG to handle the C++/Python conversions, that sort of stuff should be a lot easier in Cython. With SWIG (or Ctypes), if there is a direct map from Python to C, it works great, but when you need some real code in the interface, it gets a lot harder to write that so that it's efficient.

Of course, I'm really pushing Cython because a major wrapping project like wx would really help move Cython forward to be a more mature wrapping tool, and I's like that because I think it is already hands-down the best way to write custom extensions.

-Chris

···

On 10/26/10 5:37 PM, Robin Dunn wrote:

As promised I've published some information about what I am calling
Project Phoenix, also known as the new way to produce the wxPython
wrappers that myself and others have been hinting about for a couple
years now.

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

6

Hi,

As promised I've published some information about what I am calling
Project Phoenix, also known as the new way to produce the wxPython
wrappers that myself and others have been hinting about for a couple
years now.

About replacing SWIG, do the other wrapping tools support the
features that I like in wxPython:

1 - cross-language polymorphism:
the ability to inherit from a C++ class in Python, and implement
virtual methods in Python code.

2 - Original Object Return:
For example, in event callbacks, event.GetWindow() returns the same python
object I created earlier in my code; not a copy, not a structure containing the
same handle. All the custom attributes are still there - very important
in a derived class!

These two features allow the programmer to use objects, not IDs like with
other toolkits.

3 - separate compilation:
Sometimes it's not possible to use Python code and you need to
customize a wxWidget class in C++: for example some time ago I
subclassed wxComboBox at the time there was no owner-drawn option.
With SWIG it's possible to wrap this customized class, compile a new
extension module and obtain a new (Python) subclass of wx.ComboBox,
that you can use everywhere a combo box is expected to work.
We also implemented a complex wx.Sizer which was initially slow
in Python, and that we rewrote in C++ for performance. Of course from
Python code it was accessible and usable just like a wx.GridSizer.

I remember that this last feature was the reason why we chose the
wxPython framework - even if wxWidgets does not have some control
or some event handler, with little work you can extend the system
and have it in wxPython -- without asking Robin!

Cheers,

···

On 10/26/10 5:37 PM, Robin Dunn wrote:

--
Amaury Forgeot d'Arc

7

Hi,

As promised I've published some information about what I am calling
Project Phoenix, also known as the new way to produce the wxPython
wrappers that myself and others have been hinting about for a couple
years now.

About replacing SWIG, do the other wrapping tools support the
features that I like in wxPython:

I'll answer just for SIP since that is the non-SWIG tool that I'm most familiar with at the moment.

1 - cross-language polymorphism:
the ability to inherit from a C++ class in Python, and implement
virtual methods in Python code.

SIP: Yes.

When I first started making it possible to do that with wxPython, SWIG either didn't have the "directors" feature yet, or it was still brand new and had a bad reputation for causing more problems than it solved. So I implemented my own hand-written code to do it, and it grew into an ugly, wart-infested mess that is difficult to use and to maintain. With SIP it looks like it was designed from the start to support reflecting virtual method calls down to the Python class (if it was overridden there) and to be efficient about it. To be fair it looks like the directors feature in the newest SWIG is better than the last time I looked at it and so if I stay with SWIG I will switch to using directors in Phoenix instead of my old kludges.

2 - Original Object Return:
For example, in event callbacks, event.GetWindow() returns the same python
object I created earlier in my code; not a copy, not a structure containing the
same handle. All the custom attributes are still there - very important
in a derived class!

SIP: Yes

I still need to do some verification of this but it looks like it is a built-in feature of SIP's runtime library and won't have to be a hack that I add on myself like I did with SWIG. And since it's built-in we should be able to make it work for every wrapped type and not just windows, sizers and a few others that have a user data pointer that I'm able to hijack.

These two features allow the programmer to use objects, not IDs like with
other toolkits.

3 - separate compilation:
Sometimes it's not possible to use Python code and you need to
customize a wxWidget class in C++: for example some time ago I
subclassed wxComboBox at the time there was no owner-drawn option.
With SWIG it's possible to wrap this customized class, compile a new
extension module and obtain a new (Python) subclass of wx.ComboBox,
that you can use everywhere a combo box is expected to work.
We also implemented a complex wx.Sizer which was initially slow
in Python, and that we rewrote in C++ for performance. Of course from
Python code it was accessible and usable just like a wx.GridSizer.

Yes, this ability is not something that I would be willing to lose, so no matter what is chosen it will still be possible to add other extension modules that are able to fully integrate with the wxPython extension modules. You may have to change how you implement the wrappers for your C++ class, but it will be possible to do.

···

On 10/28/10 1:48 PM, Amaury Forgeot d'Arc wrote:

On 10/26/10 5:37 PM, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman

8

My biggest gripe with the current wxPython is how it deals with
deleted C++ objects. If I subclass wx.Window and the C++ object for
the window is deleted, accessing any Python attributes raises
PyDeadObjectError, even though the Python object still exists. I would
prefer it if PyDeadObjectError is only raised when calling a C++
method.

9

I disagree - this is an essential sanity check. You should not be calling Destroy() for GUI objects that you still need to reference, and you should not be trying to access objects that have been deleted. In every instance where I’ve encountered this error, it was always due to a bug in my code, and easily avoided by calling methods in the proper order, or handling wx.EVT_CLOSE and/or wx.EVT_WINDOW_DESTROY properly.

-Nat

···

On Sat, Oct 30, 2010 at 4:32 PM, Luke McCarthy luke.mccarthy@gmail.com wrote:

My biggest gripe with the current wxPython is how it deals with

deleted C++ objects. If I subclass wx.Window and the C++ object for

the window is deleted, accessing any Python attributes raises

PyDeadObjectError, even though the Python object still exists. I would

prefer it if PyDeadObjectError is only raised when calling a C++

method.

10

I use wx.CallAfter a lot, and it can be annoying when the window is
destroyed after CallAfter is called, but before the CallAfter event is
handled by the event loop. If the method does not call any wxWidgets
methods, I don't see why it shouldn't work...

···

On Oct 31, 12:29 am, Nat Echols <nathaniel.ech...@gmail.com> wrote:

I disagree - this is an essential sanity check. You should not be calling
Destroy() for GUI objects that you still need to reference, and you should
not be trying to access objects that have been deleted. In every instance
where I've encountered this error, it was always due to a bug in my code,
and easily avoided by calling methods in the proper order, or handling
wx.EVT_CLOSE and/or wx.EVT_WINDOW_DESTROY properly.

-Nat

11

One workaround I use in a few places where I’ve had this crop up and haven’t been able to fix it is:

 if control:
      control.Method()

Of course, you can only do this at places where you know there is an error (I don’t want to do it everywhere).

Jon

···

On Sun, Oct 31, 2010 at 12:41 PM, Luke McCarthy luke.mccarthy@gmail.com wrote:

I use wx.CallAfter a lot, and it can be annoying when the window is

destroyed after CallAfter is called, but before the CallAfter event is

handled by the event loop. If the method does not call any wxWidgets

methods, I don’t see why it shouldn’t work…

On Oct 31, 12:29 am, Nat Echols nathaniel.ech...@gmail.com wrote:

I disagree - this is an essential sanity check. You should not be calling

Destroy() for GUI objects that you still need to reference, and you should

not be trying to access objects that have been deleted. In every instance

where I’ve encountered this error, it was always due to a bug in my code,

and easily avoided by calling methods in the proper order, or handling

wx.EVT_CLOSE and/or wx.EVT_WINDOW_DESTROY properly.

-Nat

–

To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-dev?hl=en

12

I'm all for a rebirth and a new generation of wxPython hopefully much
"better, stronger, faster" ... and lighter.

This may not be the most important issue for wxPython, but currently
creating a very simple app (using Py2App on OS X) generates a very
large application (> 40 MB as an app bundle, > 14 MB when distributed
in a dmg !!).
It seems the main culprits are:
21M ./myapp/Contents/Frameworks/libwx_macud-2.8.0.dylib
11M ./myapp/Contents/Resources/lib/python2.5/lib-dynload/wx/

It would be great if the libraries can be split so that only the
necessary libraries are included in py2app (and others such as py2exe,
etc).

Can Phoenix help produce lighter bundles ?? Maybe this is more a
wxWidgets or py2* issue ??

Cheers, Brendan.

···

On Oct 27, 11:37 am, Robin Dunn <ro...@alldunn.com> wrote:

Hi all,

As promised I've published some information about what I am calling
Project Phoenix, also known as the new way to produce the wxPython
wrappers that myself and others have been hinting about for a couple
years now. I've moved a few of my local documents about it up to the
wiki, which list some goals of the project and also a very high level
view of the methodology that I think will be the way to move forward.
I've done some work already on the tools and I will commit them to the
repository once I get an end-to-end test working, hopefully in the next
few days. For now you can read these pages to get a better feel for
what I have in mind.

   http://wiki.wxpython.org/ProjectPhoenix

Comments on those pages are welcome, but I think I would prefer to have
discussions here in the mail list for detailed questions, suggestions or
answers.

--
Robin Dunn
Software Craftsmanhttp://wxPython.org

13

Hi Brendan,

···

On Sun, Oct 31, 2010 at 5:40 PM, Brendan brendanjsimon@gmail.com wrote:

I’m all for a rebirth and a new generation of wxPython hopefully much

“better, stronger, faster” … and lighter.

This may not be the most important issue for wxPython, but currently

creating a very simple app (using Py2App on OS X) generates a very

large application (> 40 MB as an app bundle, > 14 MB when distributed

in a dmg !!).

It seems the main culprits are:

21M ./myapp/Contents/Frameworks/libwx_macud-2.8.0.dylib

11M ./myapp/Contents/Resources/lib/python2.5/lib-dynload/wx/

It would be great if the libraries can be split so that only the

necessary libraries are included in py2app (and others such as py2exe,

etc).

Can Phoenix help produce lighter bundles ?? Maybe this is more a

wxWidgets or py2* issue ??

Cheers, Brendan.

Maybe it’s just a py2app thing. My py2exe programs are never 40 MB or greater. I usually get around 14-18 MB. I wrote an article about it here: http://www.blog.pythonlibrary.org/2010/07/31/a-py2exe-tutorial-build-a-binary-series/

Mike Driscoll

Blog: http://blog.pythonlibrary.org

14

Well, yes and no -- The current standard builds of Python and wxPython are "universal", so they have essentially completely duplicate binaries -- PPC and Intel (there is also the possibility of 32 and 64 bit, for 4 total!). That explains much of why py2app binaries are bigger than Windows binaries.

But even on Windows, 14-18MB is pretty big.

This has been discussed a lot in the past, and the short version is: it could probably be done, but it would take a fair bit of work, the "core" parts are still pretty big, and disk space is cheap these days (bandwidth less cheap, but still cheap), so it hasn't been worth the work to do it.

A good idea to keep in mind while developing a new binding system thought. Perhaps "import wx" could really call a bunch of imports of difference sub-parts of the library, and users building bundles could choose to import only what they are using instead.

-Chris

···

On 10/31/10 6:13 PM, Mike Driscoll wrote:

On Sun, Oct 31, 2010 at 5:40 PM, Brendan <brendanjsimon@gmail.com > <mailto:brendanjsimon@gmail.com>> wrote:
    It would be great if the libraries can be split so that only the
    necessary libraries are included in py2app (and others such as py2exe,
    etc).

    Can Phoenix help produce lighter bundles ?? Maybe this is more a
    wxWidgets or py2* issue ??

Maybe it's just a py2app thing. My py2exe programs are never 40 MB or
greater. I usually get around 14-18 MB.

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

15

It would be great if the libraries can be split so that only the
necessary libraries are included in py2app (and others such as py2exe,
etc).

Can Phoenix help produce lighter bundles ?? Maybe this is more a
wxWidgets or py2* issue ??

Maybe it's just a py2app thing. My py2exe programs are never 40 MB or
greater. I usually get around 14-18 MB.

Well, yes and no -- The current standard builds of Python and wxPython
are "universal", so they have essentially completely duplicate binaries
-- PPC and Intel (there is also the possibility of 32 and 64 bit, for 4
total!). That explains much of why py2app binaries are bigger than
Windows binaries.

I'm not sure that adding in the 64-bit PPC architecture is worth it as the potential users of that combination seems to be dwindling fast. So that would make it 3 architectures in the fat binaries, which is what is in the current 2.9.1.1 cocoa build. That includes the wx shared library and all the wxPython extension modules, so for comparable numbers take the size of the DLLs and PYDs on Windows and multiply by three and that add on some an additional percentage due to gcc creating somewhat less efficient code (size as well as speed) than MSVC. You end up with about the same numbers.

But even on Windows, 14-18MB is pretty big.

Agreed.

This has been discussed a lot in the past, and the short version is: it
could probably be done, but it would take a fair bit of work, the "core"
parts are still pretty big, and disk space is cheap these days
(bandwidth less cheap, but still cheap), so it hasn't been worth the
work to do it.

A good idea to keep in mind while developing a new binding system
thought. Perhaps "import wx" could really call a bunch of imports of
difference sub-parts of the library, and users building bundles could
choose to import only what they are using instead.

This thought has crossed my mind as well, although I haven't yet devoted much brain cycles to it. Ideally it would be nice to have some sort of on-demand import system where the module containing a class or function is not imported until the application code tries to use that class or function. For example, there is a class like wx.Point that uses floating point values instead of integers, but it is very seldom used so it is just wasting space in the current wx._core. With an on-demand import that code could be in a separate extension module (say geometry.[pyd|so] to match the C++ header file) and then when the application tries to use wx.Point2D then the equivalent of "from geometry import *" is done in the wx namespace.

I don't know if this is possible without adding too much overhead, or if some other project as done something like this already that we could borrow code from. If somebody wants to spend some time researching this and experimenting with implementations I would open to trying to use it in Phoenix.

···

On 11/1/10 9:45 AM, Christopher Barker wrote:

On 10/31/10 6:13 PM, Mike Driscoll wrote:

On Sun, Oct 31, 2010 at 5:40 PM, Brendan <brendanjsimon@gmail.com >> <mailto:brendanjsimon@gmail.com>> wrote:

--
Robin Dunn
Software Craftsman

16

I should have Googled first: Lazy module imports « Python recipes « ActiveState Code

It would still be nice however to have some research and evaluation done on this or other implementations to determine overhead and feasibility.

···

On 11/1/10 10:36 AM, Robin Dunn wrote:

This thought has crossed my mind as well, although I haven't yet devoted
much brain cycles to it. Ideally it would be nice to have some sort of
on-demand import system where the module containing a class or function
is not imported until the application code tries to use that class or
function. For example, there is a class like wx.Point that uses floating
point values instead of integers, but it is very seldom used so it is
just wasting space in the current wx._core. With an on-demand import
that code could be in a separate extension module (say geometry.[pyd|so]
to match the C++ header file) and then when the application tries to use
wx.Point2D then the equivalent of "from geometry import *" is done in
the wx namespace.

I don't know if this is possible without adding too much overhead, or if
some other project as done something like this already that we could
borrow code from. If somebody wants to spend some time researching this
and experimenting with implementations I would open to trying to use it
in Phoenix.

--
Robin Dunn
Software Craftsman

17

Here's another: Importing - The PEAK Developers' Center

···

On 11/1/10 10:40 AM, Robin Dunn wrote:

On 11/1/10 10:36 AM, Robin Dunn wrote:

This thought has crossed my mind as well, although I haven't yet devoted
much brain cycles to it. Ideally it would be nice to have some sort of
on-demand import system where the module containing a class or function
is not imported until the application code tries to use that class or
function. For example, there is a class like wx.Point that uses floating
point values instead of integers, but it is very seldom used so it is
just wasting space in the current wx._core. With an on-demand import
that code could be in a separate extension module (say geometry.[pyd|so]
to match the C++ header file) and then when the application tries to use
wx.Point2D then the equivalent of "from geometry import *" is done in
the wx namespace.

I don't know if this is possible without adding too much overhead, or if
some other project as done something like this already that we could
borrow code from. If somebody wants to spend some time researching this
and experimenting with implementations I would open to trying to use it
in Phoenix.

I should have Googled first:
Lazy module imports « Python recipes « ActiveState Code

It would still be nice however to have some research and evaluation done
on this or other implementations to determine overhead and feasibility.

--
Robin Dunn
Software Craftsman

18

The two implementations are both intended to improve startup time (which I think would also be valuable), not reduce distributable size. Would these kinds of dynamic import confuse py2exe and similar tools and make it miss imports? (I’ve certainly had py2exe miss imports that were done in C rather than Python, which means the app just crashes when it hits the import). Would you actually be able to reduce distributable size? How would you know which bits to include and which bits to exclude? (if it were fine grained enough, I’m not sure you would have enough information to know easily).

Jon

···

On Tue, Nov 2, 2010 at 4:36 AM, Robin Dunn robin@alldunn.com wrote:

On 11/1/10 9:45 AM, Christopher Barker wrote:

On 10/31/10 6:13 PM, Mike Driscoll wrote:

On Sun, Oct 31, 2010 at 5:40 PM, Brendan <brendanjsimon@gmail.com > > > > > > mailto:brendanjsimon@gmail.com> wrote:

It would be great if the libraries can be split so that only the

necessary libraries are included in py2app (and others such as py2exe,

etc).

Can Phoenix help produce lighter bundles ?? Maybe this is more a

wxWidgets or py2* issue ??

Maybe it’s just a py2app thing. My py2exe programs are never 40 MB or

greater. I usually get around 14-18 MB.

Well, yes and no – The current standard builds of Python and wxPython

are “universal”, so they have essentially completely duplicate binaries

– PPC and Intel (there is also the possibility of 32 and 64 bit, for 4

total!). That explains much of why py2app binaries are bigger than

Windows binaries.

I’m not sure that adding in the 64-bit PPC architecture is worth it as the potential users of that combination seems to be dwindling fast. So that would make it 3 architectures in the fat binaries, which is what is in the current 2.9.1.1 cocoa build. That includes the wx shared library and all the wxPython extension modules, so for comparable numbers take the size of the DLLs and PYDs on Windows and multiply by three and that add on some an additional percentage due to gcc creating somewhat less efficient code (size as well as speed) than MSVC. You end up with about the same numbers.

But even on Windows, 14-18MB is pretty big.

Agreed.

This has been discussed a lot in the past, and the short version is: it

could probably be done, but it would take a fair bit of work, the “core”

parts are still pretty big, and disk space is cheap these days

(bandwidth less cheap, but still cheap), so it hasn’t been worth the

work to do it.

A good idea to keep in mind while developing a new binding system

thought. Perhaps “import wx” could really call a bunch of imports of

difference sub-parts of the library, and users building bundles could

choose to import only what they are using instead.

This thought has crossed my mind as well, although I haven’t yet devoted much brain cycles to it. Ideally it would be nice to have some sort of on-demand import system where the module containing a class or function is not imported until the application code tries to use that class or function. For example, there is a class like wx.Point that uses floating point values instead of integers, but it is very seldom used so it is just wasting space in the current wx._core. With an on-demand import that code could be in a separate extension module (say geometry.[pyd|so] to match the C++ header file) and then when the application tries to use wx.Point2D then the equivalent of “from geometry import *” is done in the wx namespace.

I don’t know if this is possible without adding too much overhead, or if some other project as done something like this already that we could borrow code from. If somebody wants to spend some time researching this and experimenting with implementations I would open to trying to use it in Phoenix.

19

Nokia's PySide (PyQt like bindings for Qt) no longer uses
Boost::Python. They have since switched to there own tool called
Shiboken.

http://developer.qt.nokia.com/wiki/PySide_Binding_Generator/

Maybe their work should be considered for Phoenix.

Const

···

On Oct 26, 10:13 pm, Aloys Baillet <aloys.bail...@gmail.com> wrote:

Quite nice to see this work planned!
I've spent some time binding C++ code in Python, and used both SWIG, SIP and
Boost::Python, and I must say I found Boost::Python to be the cleanest and
easiest to use. You can link statically against the library, so wrapped
types don't bleed out.
Nokia is currently using it for their own version of PyQt (PySide:http://www.pyside.org), and Py++ uses it as well to generate bindings
automatically (NameBright - Coming Soon)

20

The phrases "Robin Dunn" and "a handwritten XML document" have a hard time coexisting in the same universe and have a tendency to be mutually exclusive on the same project. :wink:

···

On 11/13/10 7:56 AM, Const wrote:

On Oct 26, 10:13 pm, Aloys Baillet<aloys.bail...@gmail.com> wrote:

Quite nice to see this work planned!
I've spent some time binding C++ code in Python, and used both SWIG, SIP and
Boost::Python, and I must say I found Boost::Python to be the cleanest and
easiest to use. You can link statically against the library, so wrapped
types don't bleed out.
Nokia is currently using it for their own version of PyQt (PySide:http://www.pyside.org), and Py++ uses it as well to generate bindings
automatically (NameBright - Coming Soon)

Nokia's PySide (PyQt like bindings for Qt) no longer uses
Boost::Python. They have since switched to there own tool called
Shiboken.

http://developer.qt.nokia.com/wiki/PySide_Binding_Generator/

Maybe their work should be considered for Phoenix.

--
Robin Dunn
Software Craftsman