sized_controls - no SizedScrolledPanel

wxPython Users
1

Kevin,

Is there a particular reason that you didn't do a SizedScrolledPanel?

I guess I can just put a SizedPanel into a ScrolledPanel, but I am getting allergic to have to work directly with sizers;-) .

Would you consider accepting a patch for this?

Werner

2

Hi Werner,

Kevin,

Is there a particular reason that you didn't do a SizedScrolledPanel?

I guess I can just put a SizedPanel into a ScrolledPanel, but I am getting allergic to have to work directly with sizers;-) .

Would you consider accepting a patch for this?

I don't do it because with the current SWIG bindings, it is not possible. :frowning: For each Panel / StaticBox / etc. class for which we would like to add SizedControls support, we need a version of that class that can override the virtuals. For wx.Panel, we have wx.PyPanel, which allows this, but it must be done by hand for each class we want to support, and wx.StaticBox, wx.ScrolledWindow / wx.ScrolledPanel, etc. have not yet had this done.

The Phoenix bindings actually do not have this problem, though, as you can override any virtual for any class (along with a host of other nice benefits), so this is the direction I'm going in myself to get support for these. I'm hoping to have a little time this weekend to finish getting a Windows build bot going for Phoenix and have successful builds spit out a wx package that people can download and test.

Thanks,

Kevin

···

On Oct 11, 2011, at 5:45 AM, werner wrote:

Werner

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

3

Hi Kevin,

Hi Werner,

Kevin,

Is there a particular reason that you didn't do a SizedScrolledPanel?

I guess I can just put a SizedPanel into a ScrolledPanel, but I am getting allergic to have to work directly with sizers;-) .

Would you consider accepting a patch for this?

I don't do it because with the current SWIG bindings, it is not possible. :frowning: For each Panel / StaticBox / etc. class for which we would like to add SizedControls support, we need a version of that class that can override the virtuals. For wx.Panel, we have wx.PyPanel, which allows this, but it must be done by hand for each class we want to support, and wx.StaticBox, wx.ScrolledWindow / wx.ScrolledPanel, etc. have not yet had this done.

Thanks for the explanation.

The Phoenix bindings actually do not have this problem, though, as you can override any virtual for any class (along with a host of other nice benefits), so this is the direction I'm going in myself to get support for these. I'm hoping to have a little time this weekend to finish getting a Windows build bot going for Phoenix and have successful builds spit out a wx package that people can download and test.

Wow - looking forward to it!

Werner

···

On 10/11/2011 08:02 PM, Kevin Ollivier wrote:

On Oct 11, 2011, at 5:45 AM, werner wrote:

4

There is a wx.PyScrolledWindow.

···

On 10/11/11 11:02 AM, Kevin Ollivier wrote:

Hi Werner,

On Oct 11, 2011, at 5:45 AM, werner wrote:

Kevin,

Is there a particular reason that you didn't do a
SizedScrolledPanel?

I guess I can just put a SizedPanel into a ScrolledPanel, but I am
getting allergic to have to work directly with sizers;-) .

Would you consider accepting a patch for this?

I don't do it because with the current SWIG bindings, it is not
possible. :frowning: For each Panel / StaticBox / etc. class for which we
would like to add SizedControls support, we need a version of that
class that can override the virtuals. For wx.Panel, we have
wx.PyPanel, which allows this, but it must be done by hand for each
class we want to support, and wx.StaticBox, wx.ScrolledWindow /
wx.ScrolledPanel, etc. have not yet had this done.

--
Robin Dunn
Software Craftsman

5

And there is a wx.lib.scrolledpanel which is based on above.

As a hack I copied the sc.sizedpanel code to a module and changed it to inherit from wx.lib.scrolledpanel and in its __init__ method called self.SetupScrolling().

Should probably also do:
self.SetSizerProps(expand=True, proportion=1)

Currently have this in my code but without it the scrolledPanel is not showing all the controls one adds to it.

To do this correctly I would have to move the methods "AddChild", "GetSizerType" and "SetSizerType" into "something" and have both the sizedcontrol.SizedPanel and sizedcontrols.SizedScrolledPanel inherit from "something". What is the correct way of doing this? A mixin with these three and change everything to use "super", e.g.

change:
sp.ScrolledPanel.base_AddChild(self, child)

to:
super(SizedScrolledPanel, self).base_AddChild(self, child)

Or can't this be done with a mixin, any pointers on how it could be done would be appreciated.

Werner

···

On 10/11/2011 08:53 PM, Robin Dunn wrote:

On 10/11/11 11:02 AM, Kevin Ollivier wrote:

Hi Werner,

On Oct 11, 2011, at 5:45 AM, werner wrote:

Kevin,

Is there a particular reason that you didn't do a
SizedScrolledPanel?

I guess I can just put a SizedPanel into a ScrolledPanel, but I am
getting allergic to have to work directly with sizers;-) .

Would you consider accepting a patch for this?

I don't do it because with the current SWIG bindings, it is not
possible. :frowning: For each Panel / StaticBox / etc. class for which we
would like to add SizedControls support, we need a version of that
class that can override the virtuals. For wx.Panel, we have
wx.PyPanel, which allows this, but it must be done by hand for each
class we want to support, and wx.StaticBox, wx.ScrolledWindow /
wx.ScrolledPanel, etc. have not yet had this done.

There is a wx.PyScrolledWindow.

6

Hi Werner,

Hi Werner,

Kevin,

Is there a particular reason that you didn't do a
SizedScrolledPanel?

I guess I can just put a SizedPanel into a ScrolledPanel, but I am
getting allergic to have to work directly with sizers;-) .

Would you consider accepting a patch for this?

I don't do it because with the current SWIG bindings, it is not
possible. :frowning: For each Panel / StaticBox / etc. class for which we
would like to add SizedControls support, we need a version of that
class that can override the virtuals. For wx.Panel, we have
wx.PyPanel, which allows this, but it must be done by hand for each
class we want to support, and wx.StaticBox, wx.ScrolledWindow /
wx.ScrolledPanel, etc. have not yet had this done.

There is a wx.PyScrolledWindow.

And there is a wx.lib.scrolledpanel which is based on above.

As a hack I copied the sc.sizedpanel code to a module and changed it to inherit from wx.lib.scrolledpanel and in its __init__ method called self.SetupScrolling().

Should probably also do:
self.SetSizerProps(expand=True, proportion=1)

Currently have this in my code but without it the scrolledPanel is not showing all the controls one adds to it.

To do this correctly I would have to move the methods "AddChild", "GetSizerType" and "SetSizerType" into "something" and have both the sizedcontrol.SizedPanel and sizedcontrols.SizedScrolledPanel inherit from "something". What is the correct way of doing this? A mixin with these three and change everything to use "super", e.g.

change:
sp.ScrolledPanel.base_AddChild(self, child)

to:
super(SizedScrolledPanel, self).base_AddChild(self, child)

Or can't this be done with a mixin, any pointers on how it could be done would be appreciated.

Thanks for checking into this! I forgot about wx.lib.scrolledpanel, and obviously also wx.PyScrolledWindow. :wink:

Yeah, as you were thinking, what I'd suggest is to abstract the sc.SizedPanel code out into a SizedParent mixin class, and have SizedPanel, a new SizedScrolledWindow derived from wx.PyScrolledWindow, and a new SizedScrolledPanel derived from wx.lib.scrolledpanel's ScrolledPanel, all inherit from SizedParent. I'd be happy to look at a patch for this. :slight_smile:

Thanks,

Kevin

···

On Oct 12, 2011, at 2:21 AM, werner wrote:

On 10/11/2011 08:53 PM, Robin Dunn wrote:

On 10/11/11 11:02 AM, Kevin Ollivier wrote:

On Oct 11, 2011, at 5:45 AM, werner wrote:

Werner

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

7

Hi Kevin,

...

And there is a wx.lib.scrolledpanel which is based on above.

As a hack I copied the sc.sizedpanel code to a module and changed it to inherit from wx.lib.scrolledpanel and in its __init__ method called self.SetupScrolling().

Should probably also do:
self.SetSizerProps(expand=True, proportion=1)

Currently have this in my code but without it the scrolledPanel is not showing all the controls one adds to it.

To do this correctly I would have to move the methods "AddChild", "GetSizerType" and "SetSizerType" into "something" and have both the sizedcontrol.SizedPanel and sizedcontrols.SizedScrolledPanel inherit from "something". What is the correct way of doing this? A mixin with these three and change everything to use "super", e.g.

change:
sp.ScrolledPanel.base_AddChild(self, child)

to:
super(SizedScrolledPanel, self).base_AddChild(self, child)

Or can't this be done with a mixin, any pointers on how it could be done would be appreciated.

Thanks for checking into this! I forgot about wx.lib.scrolledpanel, and obviously also wx.PyScrolledWindow. :wink:

Yeah, as you were thinking, what I'd suggest is to abstract the sc.SizedPanel code out into a SizedParent mixin class, and have SizedPanel, a new SizedScrolledWindow derived from wx.PyScrolledWindow, and a new SizedScrolledPanel derived from wx.lib.scrolledpanel's ScrolledPanel, all inherit from SizedParent. I'd be happy to look at a patch for this. :slight_smile:

O.k. I slowly getting there - not sure it meets approval but so far it works for me and I like to check before going further with it (definitely needs more testing and might try the ScrolledWindow one, also I don't need this at this point).

My initial go was to basically rename existing sc.SizedPanel to sc.SizedParent and get rid of the __init__ code, however I couldn't make the new sc.SizedPanel (which was basically just the old __init__ code to see the AddChild, SetSizerType and GetSizerType methods.

Anyhow even if above worked I am not aware of a way to handle the following type of code "sp.ScrolledPanel.SetSizer(self, sizer)" in SizedParent that always the correct base class would be called.

If anyone can point me to some documentation/sample code on how this can be done I have another look.

In the mean time attached is a proposed patch using a different way which still has a minimal amount of duplicated code in the different sub-classes.

I am putting the helmet on - so please comment on this;-)

Werner

P.S. Am I really the only one who uses "Auto trim whitespace on save" in his editor? I get caught each time (o.k. not that often - at least not yet;-) ) when I a do a patch, I end up with tons of non relevant changes and have to go back and redo things.

sizedcontrol1.patch (3.18 KB)

···

On 10/12/2011 06:05 PM, Kevin Ollivier wrote:

8

Hi Werner,

Hi Kevin,

...

And there is a wx.lib.scrolledpanel which is based on above.

As a hack I copied the sc.sizedpanel code to a module and changed it to inherit from wx.lib.scrolledpanel and in its __init__ method called self.SetupScrolling().

Should probably also do:
self.SetSizerProps(expand=True, proportion=1)

Currently have this in my code but without it the scrolledPanel is not showing all the controls one adds to it.

To do this correctly I would have to move the methods "AddChild", "GetSizerType" and "SetSizerType" into "something" and have both the sizedcontrol.SizedPanel and sizedcontrols.SizedScrolledPanel inherit from "something". What is the correct way of doing this? A mixin with these three and change everything to use "super", e.g.

change:
sp.ScrolledPanel.base_AddChild(self, child)

to:
super(SizedScrolledPanel, self).base_AddChild(self, child)

Or can't this be done with a mixin, any pointers on how it could be done would be appreciated.

Thanks for checking into this! I forgot about wx.lib.scrolledpanel, and obviously also wx.PyScrolledWindow. :wink:

Yeah, as you were thinking, what I'd suggest is to abstract the sc.SizedPanel code out into a SizedParent mixin class, and have SizedPanel, a new SizedScrolledWindow derived from wx.PyScrolledWindow, and a new SizedScrolledPanel derived from wx.lib.scrolledpanel's ScrolledPanel, all inherit from SizedParent. I'd be happy to look at a patch for this. :slight_smile:

O.k. I slowly getting there - not sure it meets approval but so far it works for me and I like to check before going further with it (definitely needs more testing and might try the ScrolledWindow one, also I don't need this at this point).

Cool, thanks! :slight_smile:

My initial go was to basically rename existing sc.SizedPanel to sc.SizedParent and get rid of the __init__ code, however I couldn't make the new sc.SizedPanel (which was basically just the old __init__ code to see the AddChild, SetSizerType and GetSizerType methods.

Anyhow even if above worked I am not aware of a way to handle the following type of code "sp.ScrolledPanel.SetSizer(self, sizer)" in SizedParent that always the correct base class would be called.

Yeah, if the mixin isn't working, it is most likely something to do with how the SWIG bindings override the virtuals. Robin may know more about this, but I sort of suspect we'll need to do it this way for now.

If anyone can point me to some documentation/sample code on how this can be done I have another look.

In the mean time attached is a proposed patch using a different way which still has a minimal amount of duplicated code in the different sub-classes.

I am putting the helmet on - so please comment on this;-)

I'll try to play with this patch sometime this weekend, but just checking the code, it looks good. One thing I noticed, though, is that your patch seems to have mixed Windows / Unix line endings.

Werner

P.S. Am I really the only one who uses "Auto trim whitespace on save" in his editor? I get caught each time (o.k. not that often - at least not yet;-) ) when I a do a patch, I end up with tons of non relevant changes and have to go back and redo things.

In my experience, yes, you are. :wink: The problem is, as you say, that when you start using it, anytime you start working with someone else's code who doesn't use it, you get a lot of whitespace change noise in your patches. Then that makes patches hard to review. :frowning:

What I think would make such a switch more feasible is a script that goes through a source tree and strips whitespace. This way you can get all the whitespace changes out of the way in one commit, and then have everyone switch to that option if everyone's editors support it.

Thanks,

Kevin

···

On Oct 13, 2011, at 7:26 AM, werner wrote:

On 10/12/2011 06:05 PM, Kevin Ollivier wrote:

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en<sizedcontrol1\.patch>

9

Hi Kevin,

Hi Werner,

Hi Kevin,

...

And there is a wx.lib.scrolledpanel which is based on above.

As a hack I copied the sc.sizedpanel code to a module and changed it to inherit from wx.lib.scrolledpanel and in its __init__ method called self.SetupScrolling().

Should probably also do:
self.SetSizerProps(expand=True, proportion=1)

Currently have this in my code but without it the scrolledPanel is not showing all the controls one adds to it.

To do this correctly I would have to move the methods "AddChild", "GetSizerType" and "SetSizerType" into "something" and have both the sizedcontrol.SizedPanel and sizedcontrols.SizedScrolledPanel inherit from "something". What is the correct way of doing this? A mixin with these three and change everything to use "super", e.g.

change:
sp.ScrolledPanel.base_AddChild(self, child)

to:
super(SizedScrolledPanel, self).base_AddChild(self, child)

Or can't this be done with a mixin, any pointers on how it could be done would be appreciated.

Thanks for checking into this! I forgot about wx.lib.scrolledpanel, and obviously also wx.PyScrolledWindow. :wink:

Yeah, as you were thinking, what I'd suggest is to abstract the sc.SizedPanel code out into a SizedParent mixin class, and have SizedPanel, a new SizedScrolledWindow derived from wx.PyScrolledWindow, and a new SizedScrolledPanel derived from wx.lib.scrolledpanel's ScrolledPanel, all inherit from SizedParent. I'd be happy to look at a patch for this. :slight_smile:

O.k. I slowly getting there - not sure it meets approval but so far it works for me and I like to check before going further with it (definitely needs more testing and might try the ScrolledWindow one, also I don't need this at this point).

Cool, thanks! :slight_smile:

My initial go was to basically rename existing sc.SizedPanel to sc.SizedParent and get rid of the __init__ code, however I couldn't make the new sc.SizedPanel (which was basically just the old __init__ code to see the AddChild, SetSizerType and GetSizerType methods.

Anyhow even if above worked I am not aware of a way to handle the following type of code "sp.ScrolledPanel.SetSizer(self, sizer)" in SizedParent that always the correct base class would be called.

Yeah, if the mixin isn't working, it is most likely something to do with how the SWIG bindings override the virtuals. Robin may know more about this, but I sort of suspect we'll need to do it this way for now.

If anyone can point me to some documentation/sample code on how this can be done I have another look.

In the mean time attached is a proposed patch using a different way which still has a minimal amount of duplicated code in the different sub-classes.

I am putting the helmet on - so please comment on this;-)

I'll try to play with this patch sometime this weekend, but just checking the code, it looks good.

Me too will do more testing with this and will update the patch should I find an issue before the weekend.

  One thing I noticed, though, is that your patch seems to have mixed Windows / Unix line endings.

No idea - I just pulled the code from SVN yesterday on Windows 7 (also it is a VirtualBox VM) and I am editing with Editra which I just checked has the "Default EOL Mode" set to "Windows \r\n".

Checking the .py file I have all CRLF endings, but the patch as you say has mixed. I use TortoiseSVN to generate the patch and while it is set to "native" it must get confused a long the lines.

Werner

P.S. Am I really the only one who uses "Auto trim whitespace on save" in his editor? I get caught each time (o.k. not that often - at least not yet;-) ) when I a do a patch, I end up with tons of non relevant changes and have to go back and redo things.

In my experience, yes, you are. :wink: The problem is, as you say, that when you start using it, anytime you start working with someone else's code who doesn't use it, you get a lot of whitespace change noise in your patches. Then that makes patches hard to review. :frowning:

What I think would make such a switch more feasible is a script that goes through a source tree and strips whitespace. This way you can get all the whitespace changes out of the way in one commit, and then have everyone switch to that option if everyone's editors support it.

Agree, will just have to live with it I guess.

Werner

···

On 10/13/2011 05:52 PM, Kevin Ollivier wrote:

On Oct 13, 2011, at 7:26 AM, werner wrote:

On 10/12/2011 06:05 PM, Kevin Ollivier wrote:

10

Yep, I wouldn't be surprised if there is a problem finding the overridden methods if they are coming from a mixin.

···

On 10/13/11 8:52 AM, Kevin Ollivier wrote:

Yeah, if the mixin isn't working, it is most likely something to do
with how the SWIG bindings override the virtuals. Robin may know more
about this, but I sort of suspect we'll need to do it this way for
now.

--
Robin Dunn
Software Craftsman

11

O.O

Did you say a Phoenix wx package (I know alpha/beta) might be available?
Well, I'll wait for release, but that sounds exciting !

···

On Tue, Oct 11, 2011 at 2:02 PM, Kevin Ollivier <kevin-lists@theolliviers.com> wrote:

Hi Werner,

The Phoenix bindings .... I'm hoping to have a little time this weekend to finish getting a Windows build bot going for Phoenix and have successful builds spit out a wx package that people can download and test.
Kevin

12

More like pre-pre-pre-pre-alpha :wink:

Basically what we're thinking is that in addition to building the code and running tests that the buildbots will also copy the binaries to a place where they can be downloaded. To begin with they will not even be installers, just a zip/tgz file and a set of instructions telling you to set your PYTHONPATH, and will be just the core modules without any library modules, etc.

···

On 10/15/11 3:44 PM, Dev Player wrote:

On Tue, Oct 11, 2011 at 2:02 PM, Kevin Ollivier > <kevin-lists@theolliviers.com> wrote:

Hi Werner,

The Phoenix bindings .... I'm hoping to have a little time this weekend to finish getting a Windows build bot going for Phoenix and have successful builds spit out a wx package that people can download and test.
Kevin

O.O

Did you say a Phoenix wx package (I know alpha/beta) might be available?

--
Robin Dunn
Software Craftsman

13

Hi All,

Hi Werner,

The Phoenix bindings … I’m hoping to have a little time this weekend to finish getting a Windows build bot going for Phoenix and have successful builds spit out a wx package that people can download and test.

Kevin

O.O

Did you say a Phoenix wx package (I know alpha/beta) might be available?

More like pre-pre-pre-pre-alpha :wink:

Basically what we’re thinking is that in addition to building the code and running tests that the buildbots will also copy the binaries to a place where they can be downloaded. To begin with they will not even be installers, just a zip/tgz file and a set of instructions telling you to set your PYTHONPATH, and will be just the core modules without any library modules, etc.

The tool (screenshots below-based on an idea from Robin) I am about to finish may possibly help spotting missing implementations/methods/classes in the new Phoenix framework. The tool is termed Namespace Diff Tool (NDT) and the only thing still to be implemented is the comparison between two versions of the same package (so far it works on all the libraries I have tried: wx, numpy, matplotlib, sphinx, VTK, dateutil, comtypes, etc…).

I am having a hard time trying to think about how to visually present the diff between two methods/classes/modules (and this is not a code diff, is a diff between signatures, changes in parameter names, changes in docs, missing/new implementations between 2 versions etc…), so any suggestion is more than welcome.

Screenshots:

http://imageshack.us/f/811/ndt1.png/

http://imageshack.us/f/706/ndt2.png/

http://imageshack.us/f/560/ndtfilter.png/

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”

http://xoomer.alice.it/infinity77/

import PyQt4.QtGui

Traceback (most recent call last):

File “”, line 1, in

ImportError: No module named PyQt4.QtGui

import pygtk

Traceback (most recent call last):

File “”, line 1, in

ImportError: No module named pygtk

···

On 16 October 2011 02:13, Robin Dunn wrote:

On 10/15/11 3:44 PM, Dev Player wrote:

On Tue, Oct 11, 2011 at 2:02 PM, Kevin Ollivier > > > > kevin-lists@theolliviers.com wrote:

import wx

14

Hi All,

            Hi Werner,

            The Phoenix bindings .... I'm hoping to have a little time
            this weekend to finish getting a Windows build bot going for
            Phoenix and have successful builds spit out a wx package
            that people can download and test.
            Kevin

        O.O

        Did you say a Phoenix wx package (I know alpha/beta) might be
        available?

    More like pre-pre-pre-pre-alpha :wink:

    Basically what we're thinking is that in addition to building the
    code and running tests that the buildbots will also copy the
    binaries to a place where they can be downloaded. To begin with
    they will not even be installers, just a zip/tgz file and a set of
    instructions telling you to set your PYTHONPATH, and will be just
    the core modules without any library modules, etc.

The tool (screenshots below-based on an idea from Robin) I am about to
finish may possibly help spotting missing
implementations/methods/classes in the new Phoenix framework. The tool
is termed Namespace Diff Tool (NDT) and the only thing still to be
implemented is the comparison between two versions of the same package
(so far it works on all the libraries I have tried: wx, numpy,
matplotlib, sphinx, VTK, dateutil, comtypes, etc...).

I am having a hard time trying to think about how to visually present
the diff between two methods/classes/modules (and this is *not* a code
diff, is a diff between signatures, changes in parameter names, changes
in docs, missing/new implementations between 2 versions etc...), so any
suggestion is more than welcome.

Most visual diff tools will shade the background with different colors for things that are only in one version, or only in the other version, etc. Perhaps that principle will fit here too.

Screenshots:

ImageShack - Best place for all of your image hosting and image sharing needs
ImageShack - Best place for all of your image hosting and image sharing needs
ImageShack - Best place for all of your image hosting and image sharing needs

The screenshots are looking good! I was still thinking of it as a text-based tool that just listed high-level differences based on command line options. Being able to have all the extra details and control in the GUI will be very nice.

···

On 10/16/11 12:39 AM, Andrea Gavana wrote:

On 16 October 2011 02:13, Robin Dunn wrote:
    On 10/15/11 3:44 PM, Dev Player wrote:
        On Tue, Oct 11, 2011 at 2:02 PM, Kevin Ollivier > <kevin-lists@theolliviers.com > <mailto:kevin-lists@theolliviers.com>> wrote:

--
Robin Dunn
Software Craftsman

15

How about using one of the UML diagram tools with some colouring to
highlight the differences?

Gadget/Steve

···

On 17/10/2011 5:42 PM, Robin Dunn wrote:

On 10/16/11 12:39 AM, Andrea Gavana wrote:

Hi All,

On 16 October 2011 02:13, Robin Dunn wrote:

    On 10/15/11 3:44 PM, Dev Player wrote:

        On Tue, Oct 11, 2011 at 2:02 PM, Kevin Ollivier >> <kevin-lists@theolliviers.com >> <mailto:kevin-lists@theolliviers.com>> wrote:

            Hi Werner,

            The Phoenix bindings .... I'm hoping to have a little time
            this weekend to finish getting a Windows build bot going for
            Phoenix and have successful builds spit out a wx package
            that people can download and test.
            Kevin

        O.O

        Did you say a Phoenix wx package (I know alpha/beta) might be
        available?

    More like pre-pre-pre-pre-alpha :wink:

    Basically what we're thinking is that in addition to building the
    code and running tests that the buildbots will also copy the
    binaries to a place where they can be downloaded. To begin with
    they will not even be installers, just a zip/tgz file and a set of
    instructions telling you to set your PYTHONPATH, and will be just
    the core modules without any library modules, etc.

The tool (screenshots below-based on an idea from Robin) I am about to
finish may possibly help spotting missing
implementations/methods/classes in the new Phoenix framework. The tool
is termed Namespace Diff Tool (NDT) and the only thing still to be
implemented is the comparison between two versions of the same package
(so far it works on all the libraries I have tried: wx, numpy,
matplotlib, sphinx, VTK, dateutil, comtypes, etc...).

I am having a hard time trying to think about how to visually present
the diff between two methods/classes/modules (and this is *not* a code
diff, is a diff between signatures, changes in parameter names, changes
in docs, missing/new implementations between 2 versions etc...), so any
suggestion is more than welcome.

Most visual diff tools will shade the background with different colors
for things that are only in one version, or only in the other version,
etc. Perhaps that principle will fit here too.

Screenshots:

ImageShack - Best place for all of your image hosting and image sharing needs
ImageShack - Best place for all of your image hosting and image sharing needs
ImageShack - Best place for all of your image hosting and image sharing needs

The screenshots are looking good! I was still thinking of it as a
text-based tool that just listed high-level differences based on
command line options. Being able to have all the extra details and
control in the GUI will be very nice.