20070802 test build uploaded

Hi,

A new test build of wxPython has been uploaded.

   Version: 2.8.4.2.20070802
   URL: http://wxPython.wxcommunity.com/preview/20070802
   Changes: http://wxPython.wxcommunity.com/preview/20070802/CHANGES.html

Have fun!
R'bot

R'bot wrote:

Hi,

A new test build of wxPython has been uploaded.

   Version: 2.8.4.2.20070802
   URL: NameBright - Coming Soon
   Changes: NameBright - Coming Soon
  
"Added some SWIG magic that allows wx C++ lists to be exposed to wxPython as sequence-like wrappers around the real list, instead of making a Python list that is a copy of the real list as was done before. These sequence-like objects support indexing, iteration and containment tests ("obj in seq") but not anything that would modify the sequence. If you need to have a real list object like before you can pass the sequence to Python's list() function to convert it."

Nice, I like where this is going! The containment tests are a step up to be sure, but there doesn't appear to be a way to get the index. Is this possible? ( I realize of course that I can loop over it manually and discover it this way).

>>> children = sizer.GetChildren()
>>> sizerItem in children #good!
True
>>> children.index(sizerItem) #oh no, I guess it has to be a list
Traceback (most recent call last):
...
AttributeError: 'SizerItemList' object has no attribute 'index'
>>> sizerItem in list(children) #but then containment fails
False
>>> list(children).index(sizerItem) #and this as well
Traceback (most recent call last):
...
ValueError: list.index(x): x not in list

As you see I can turn it into a Python list to get the index method but then the containment test fails as well as the index then.

Thanks,
- Mike

Mike Rooney wrote:

R'bot wrote:

Hi,

A new test build of wxPython has been uploaded. Version: 2.8.4.2.20070802
   URL: NameBright - Coming Soon
   Changes: NameBright - Coming Soon
  
"Added some SWIG magic that allows wx C++ lists to be exposed to wxPython as sequence-like wrappers around the real list, instead of making a Python list that is a copy of the real list as was done before. These sequence-like objects support indexing, iteration and containment tests ("obj in seq") but not anything that would modify the sequence. If you need to have a real list object like before you can pass the sequence to Python's list() function to convert it."

Nice, I like where this is going! The containment tests are a step up to be sure, but there doesn't appear to be a way to get the index. Is this possible? ( I realize of course that I can loop over it manually and discover it this way).

Adding index() is on my ToDo list. I'll give it a try today or tomorrow. The problem is that while it is probably easy to implement for the typical use of seq.index(obj), there isn't a direct corellation in the C++ list class to be able to do seq.index(obj, start, stop) so it would take a bit of work to make that happen correctly...

>>> children = sizer.GetChildren()
>>> sizerItem in children #good!
True
>>> children.index(sizerItem) #oh no, I guess it has to be a list
Traceback (most recent call last):
...
AttributeError: 'SizerItemList' object has no attribute 'index'
>>> sizerItem in list(children) #but then containment fails
False
>>> list(children).index(sizerItem) #and this as well
Traceback (most recent call last):
...
ValueError: list.index(x): x not in list

As you see I can turn it into a Python list to get the index method but then the containment test fails as well as the index then.

This is actually a different problem related to wx.SizerItems, if you do it with one of the window lists it should work as expected. For example:

  >>> import wx
  >>>
  >>> for x in range(5):
  ... f = wx.Frame(shell, title=str(x))
  ... f.Show()
  ...
  True
  >>> seq = wx.GetTopLevelWindows()
  >>> seq
  wxWindowList: [<wx.py.shell.ShellFrame; proxy of <Swig Object of type 'wxFrame *' at 0x877ae28> >, <wx._windows.Frame; proxy of <Swig Object of type 'wxFrame *' at 0x8b7ed00> >, <wx._windows.Frame; proxy of <Swig Object of type 'wxFrame *' at 0x888d348> >, <wx._windows.Frame; proxy of <Swig Object of type 'wxFrame *' at 0x8b80cd0> >, <wx._windows.Frame; proxy of <Swig Object of type 'wxFrame *' at 0x8b82ce0> >, <wx._windows.Frame; proxy of <Swig Object of type 'wxFrame *' at 0x8b83fe8> >]
  >>> f
  <wx._windows.Frame; proxy of <Swig Object of type 'wxFrame *' at 0x8b83fe8> >
  >>> f in seq
  True
  >>> f in list(seq)
  True
  >>> list(seq).index(f)
  5
  >>>

I think the problem with wx.SizerItem is that it is not OOR sensitive. In other words I'm not saving a reference to the Python proxy object in the C++ object, so when SWIG needs to give you a proxy for the C++ object it creates a new one. So doing Python-level compares results in comparing two different Python objects that happen to be proxies for the same C++ object, and since there is no __cmp__ magic methods it just checks if you are looking at the same object and then fails. I'll give this some more thought and see if there's an easy way to make this work better.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin Dunn wrote:

Adding index() is on my ToDo list. I'll give it a try today or tomorrow.

Awesome!

I think the problem with wx.SizerItem is that it is not OOR sensitive. In other words I'm not saving a reference to the Python proxy object in the C++ object, so when SWIG needs to give you a proxy for the C++ object it creates a new one. So doing Python-level compares results in comparing two different Python objects that happen to be proxies for the same C++ object, and since there is no __cmp__ magic methods it just checks if you are looking at the same object and then fails. I'll give this some more thought and see if there's an easy way to make this work better.

Ahh...thanks for the explanation. That explains the issues I was having with them. Good to know the other lists behave as expected. Now that I understand the underlying issue I will probably run into less problems. Especially if I have an 'index' method on the SizerItemList.

Okay, thanks for all your great work!

- Mike