I've working on an small wxPython app that works with a set of files
and directories. So I made a class I called Filename, only to discover
that wxWidgets already has a wxFilename object simpler but similar to
my own class.
So I loaded pycrust, imported wx and took a look for a Filename or
wx.wx.Filename class or wx.wxFilename class only to find that wxPython
does not have this class yet.
My question is, is there something I can do, like code something like
a wrapper, that can get that into the wxPython source?
If so what are the steps I need to take to get that process started,
steps including what's a good example to follow in terms of what a
good example wrapper looks like?
So 1., are people other then Robin contributing directly to the source
and are they a select group of people or is it the community at
large?
2. Is the Phoenix Project and doc automation effect what wxWidgets
will be included in future wxPython release? (meaning will the Phoenix
Project be able to automatically wrap a bunch of wxWidgets so less
user coded contributions are needed and hence the difference between
wxPython and wxWidgets versions will be smaller [ie. new classes in wx
not yet in wxPython?]?
I've working on an small wxPython app that works with a set of files
and directories. So I made a class I called Filename, only to discover
that wxWidgets already has a wxFilename object simpler but similar to
my own class.
So I loaded pycrust, imported wx and took a look for a Filename or
wx.wx.Filename class or wx.wxFilename class only to find that wxPython
does not have this class yet.
Because it doesn't need it. The combination of os.path.*, os.stat,
glob.*, shutil.*, tempfile.* and filecmp.* methods (coupled with the
platform-independent behavior of Python) is more than enough to cover
almost any need one can have regarding file/path/directory
manipulation. Not to mention the gazillion of scripts on this subject
you can find by googling (see, for example, the activestate codes).
Normally (and luckily), wxPython doesn't wrap those wxWidgets classes
for which an alternative pure-Python implementation already exists (in
the standard library, for example).
I've working on an small wxPython app that works with a set of files
and directories. So I made a class I called Filename, only to discover
that wxWidgets already has a wxFilename object simpler but similar to
my own class.
So I loaded pycrust, imported wx and took a look for a Filename or
wx.wx.Filename class or wx.wxFilename class only to find that wxPython
does not have this class yet.
My question is, is there something I can do, like code something like
a wrapper, that can get that into the wxPython source?
As others have mentioned, there is no need to wrap wx classes that already have good alternatives in the Python standard library or common 3rd-party libraries. Unless there are special reasons to make an exception I won't accept contributions that do so.
If so what are the steps I need to take to get that process started,
steps including what's a good example to follow in terms of what a
good example wrapper looks like?
There are a couple very out-dated pages in the wiki about adding new swigged modules, but I usually just tell people to look at some of the .i files in the wxPython source tree. Except for the core modules they are all structured pretty much like how additional wrapper modules should be.
So 1., are people other then Robin contributing directly to the source
and are they a select group of people or is it the community at
large?
There are a few people who regularly help out with maintenance, and there have been several over the years that have made a significant code contribution and then vanished. I encourage people who are interested in this to join the wxPython-dev mail list.
2. Is the Phoenix Project and doc automation effect what wxWidgets
will be included in future wxPython release? (meaning will the Phoenix
Project be able to automatically wrap a bunch of wxWidgets so less
user coded contributions are needed and hence the difference between
wxPython and wxWidgets versions will be smaller [ie. new classes in wx
not yet in wxPython?]?
Yes, that is one of the driving goals of the project, however we will still not wrap classes that have a good alternative already available.