ObjectListView overload type errors

wxPython Users
#1

I have been using python 2.7 and classic wxPython for years but a recent upgrade forced me to move to python 3.10 and wxPython 4.1. The following code in OLV 1.3.1 is generating an error:

def _HandleSize(self, evt):
“”"
The ListView is being resized
“”"
self._PossibleFinishCellEdit()
evt.Skip()
self._ResizeSpaceFillingColumns()
# Make sure our empty msg is reasonably positioned
sz = self.GetClientSize()
if ‘phoenix’ in wx.PlatformInfo:
self.stEmptyListMsg.SetSize(0, sz.GetHeight() / 3,
sz.GetWidth(),
sz.GetHeight())
else:
self.stEmptyListMsg.SetDimensions(0, sz.GetHeight() / 3,
sz.GetWidth(),
sz.GetHeight())
# self.stEmptyListMsg.Wrap(sz.GetWidth())

The error message:

Traceback (most recent call last):
File “/home/mb/.local/lib/python3.10/site-packages/ObjectListView/ObjectListView.py”, line 1752, in _HandleSize
self.stEmptyListMsg.SetSize(0, sz.GetHeight() / 3,
TypeError: Window.SetSize(): arguments did not match any overloaded call:
overload 1: argument 2 has unexpected type ‘float’
overload 2: argument 1 has unexpected type ‘int’
overload 3: argument 1 has unexpected type ‘int’
overload 4: argument 2 has unexpected type ‘float’

Is OLV 1.3 compatible with Phoenix 4.1? I saw the part in the migration guide about overloaded functions, but that does not suggest I can fix this error with a couple small changes to the OLV code.

Thanks,
Mike Barron

#2

This is a backwards incompatible change in the Python C API. Python 3.10 made a change where floating point values passed to extension module functions expecting an integer parameter are no longer automatically truncated. Instead they raise a TypeError, and the wxPython wrapper code moves on to the next C++ overload looking for a match.

In the case that you show the sz.GetHeight() / 3 should be changed to int(sz.GetHeight() / 3) or sz.GetHeight() // 3 to just use integer division.

#3

using ‘//’ may not be a lasting idea according to the docu Note 1 I think :face_with_hand_over_mouth:

#4

Thanks very much. The // worked fine.

#5

I think where it says “The resultant value is a whole integer, though the result’s type is not necessarily int” doesn’t mean that the usage for integers might change, but is referring to the fact that any class can use the '//' operator if it defines a __floordiv__() method and that method could feasibly return anything type of object the designer wanted it to.

Here is a highly contrived example:

class C:
    def __init__(self, a):
        self.a = a

    def __floordiv__(self, other):
        return "blue"


c1 = C(1)
c2 = C(2)

res = c1 // c2
print(res, type(res))

when run it will output:

blue <class 'str'>

Obviously that example is silly, but perhaps there could be a real case where a floor division operation might reasonably return a non-integer?

#6

Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug 1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.

print(type(1.0//1))
<class ‘float’>

print(type(1//2))
<class ‘int’>

well, I think the ‘Sturm & Drang’ times (even of python) are over and the consolidation cycle is in full blow and that’s very good for its survival !!

Type checking seems to be an agreed way of improving quality (have a look at pylint with their AST astroid, I personally don’t believe in annotations etc), and that foremost on the signature level (crossing languages)

so, I would suggest to stay afloat one has to bow to the system even if young at heart (I get lost into something more interesting than programming, two valued logics from times when the first ape realized there are mor than one tree) :love_you_gesture: