CVS, DrPython and wxPython
Brought to you by:
drpython
Menu
▾
▴
So here is the deal.
I have updated to the new namespace, and removed drBoolean. This restricts use to at least Python 2.2.1 or higher (ideally 2.3.x), and wxPython 2.4.1 or higher.
However I ran into an interesting little bug.
Now, making a library not backwards compatible is not that big of a deal when you merely compile against it. You can always ship binaries using the old library. When the library is runtime, however, this can cause some hiccups.
Turns out wxPython 2.4.x expects two arguments for wxTreeCtrl.GetFirstChild(), and wxPython 2.5.x expects one.
If I use two arguments, DrPython works with 2.4.x, and bookmarks do not work with 2.5.x.
If I use one, DrPython works with 2.5.x, and bookmarks cause a segfault with 2.4.x (at least on linux).
Given that 2.4.x on linux also segfaults if you click the find and replace popup, and 2.5.x (GTK1 version) is fine, I am tempted to make wxPython 2.5.x a requirement for the 3.0.x version of DrPython.
If I do this, I can also use the new event model 2.5.x provides.
What thoughts?
I can leave it as it is now.
I just changed the cvs version so that
it checks the wxpython version number,
and based on that decides which function call to use.
If I leave this as is, the bug is squashed.
Hmm. Tough one this.
I tend to always download and use the latest stable version of libraries as long as I don't have a specific reason not to. I do however know that a lot of people, especially those running Linux installed from a standard distribution, will tend to stick to what they have "out of the box" and only upgrade if there is a good reason. Very much the reverse of my approach.
It all depends upon how important the product is to the intended audience. If it is a vital part of an individuals software arsenal, then they are unlikely to even think twice about upgrading to the required libraries as long as there is no conflict with their other software. The casual first-time user however, will most likely not even get as far as running the software as it involves upgrading their system.
Prior to finding and evaluation DrPython, I always used IDLE. I was quite content with it, and if it wasn't for the fact the DrPython "just worked" on my system when I installed it from a magazine coverdisk, I may never have seen it, and that is despite my tending to upgrade by default.
Enforcing more recent version numbers will result in a better more maintainable DrPython, and therefore gets my backing, but I would suggest keeping a publicly available version 2 using theolder libraries to which any necessary bug fixes are applied. That way casual users can try it without needing to upgrade first. It will be more work, but quite important in terms of getting new users to adopt DrPython.
As far as Python itself goes, anyone using it for current development will probably be using the latest version anyway, so I can't see it being a problem. Version 2.3 has been out for quite some time now and is very widespread.
DrPython was in a magazine coverdisk? What magazine?
Anyway, at the moment, detecting the version and using the correct function call seems to work, and I am inclined to be as backwards compatible as possible.
So while I did pop drBoolean, that restricts usage to python 2.2.1 or later. Using the new namespace requres wxPython 2.4.1 or later.
However I will hold off on using the "Bind()" syntax until later on in DrPython's development.
So while this does require recent versions, it does not require the very latest (Python 2.3.3, wxPython 2.5.1)
Even I don't like always update the software version, but I think make DrPython maintainments easily is more important. And the update will be taken at the lastest as along with the software growing. Furthermore, I hope DrPython keeping the step with the python and wxPython. These can make DrPython more actively.
It was on the Linux Format March 2004 DVD (publised in the UK mid-February) under the development section. They have the main featured software on both the CD and DVD editions of the magazine, but the DVD usually has a load of extra packages under various different headings and this particular issue had Python 2.3.3, PyPE and DrPython under development. As far as the magazine is concerned, like all of the DVD extras, DrPython just got a half dozen word description in the contents section at the back.
I bought the magazine at the time, but only got around to looking at the coverdisk a month or so ago. Thinking on, I actually downloaded the latest version from sourceforge rather than installaing the copy on the DVD, as I was doing quite a bit of work on Windows at the time, and wanted to try it on there.