I am surprised to see how quickly the change has been decided.
I think it needs more thinkings.
My points
o Python is a dynamically typed language, but Python is also
a strongly typed language. If GvR has introduced the
"Deprecation warning for floats", there is a good reason.
o Floats in dc.Methods.
I think wxPython should not "compensate" the lazyness of the
programmers. Using floats sounds very appealing. Using ints
*forces the user to think correctly*, this is especially true, when
drawing on the screen.
Let's take an example. Drawing two rectangles side by side
in an area delimited by the (p1x, p1y), upper left - (p2x, p2y), lower right
points.
With p* as floats I can do this
dc.DrawRectangleXY(p1x, p1y, (p2x - p1x) / 2, p2y - p1y)
dc.DrawRectangleXY((p2x - p1x) / 2 + 1, p1y, (p2x - p1x) / 2, p2y - p1y)
Now if p* are integers and if I am a good programmer working
with pixels, I will do something like this
pmx = (p2x - p1x) / 2.0
pmx = int(pmx)
dc.DrawRectangleXY(p1x, p1y, pmx, p2y - p1y)
dc.DrawRectangleXY(pmx + 1, p1y, pmx, p2y - p1y)
Both variants lead to the same result. The message here
is the following. If I am a clean programmer and I want to be
sure I controll everything, I define my variables and their types
*before* I pass them to the dc methods. It does not matter, if the
dc.Methods() are accepting only integers.
(For ka, this is a clear case where truncating is better over
rounding)
o Other possible issues
Font size in dc. It is usual in prining and previewing to set a
font size proportional to the dc.size. Will a user realise,
that his calculated size will be truncated?
What is the impact of these change to LayoutConstraints
and Sizers ?
Will something like this be allowed
lc.left.SameAs(self, wxLeft, 2.5)
Hope you understand what I mean. My English is not
very good this morning. 
jmf