Anthony Tuininga wrote:
> The Python development team has decided (and I think with good reason)
> that if you are calling PyArg_ParseTuple() and specifying that you are
> expecting an integer, then you really ought to be passing an integer
> through from your Python code.
>
> So there are two options, and I'm not sure which one makes the most
> sense.
>
> 1) modify the wxPython C extension to specify that it allows floating
> point, not integer
To do that would mean that even if you do pass integers that
PyArg_ParseTuple would convert it to a float and then it would then get
truncated back to an integer to be passed to the API.
> 2) modify your code so that you don't pass floats to routines expecting
> integers
>
> I suspect the latter is what is needed but I'll let someone with better
> knowledge answer that question.
Yep.
This was from over a month ago and I am now in the process of updating
wxPyPlot to get rid of the deprecation warnings for floats as arguments in
DC.DrawText, .DrawRotatedText, .DrawLine, .SetClippingRegion ... and so on.
For most plotting the values to be plotted will be real not intergers and
likewise all the math to determine the placement (scaling and offsets) on
the screen will also be real. This means that all these real numbers need
to be truncated, or slightly better, rounded to integers. This makes the
code very ugly and difficult to read if instead of
DrawLine( x1,y1,x2,y2)
we now (as I understand it) have to write
DrawLine( int(x1), int(y1), int(x2), int(y2))
From the previous posts it appears the depreciation warning is coming from a
change in python 2.3. One of the nice thing about python is that for most
cases you don't need to worry about object type and things work as expected.
This is not the case here. I was wondering if wxPython could test for float
arguments in these drawing methods and truncate or round to integers if
required. What would the performance hit be if this test was implemented.
A side note - I didn't get a deprecation warning for DrawLines. I would
have thought this would have suffered from the same problem.
From the previous posts it appears the depreciation warning is coming from a
change in python 2.3. One of the nice thing about python is that for most
cases you don't need to worry about object type and things work as expected.
This is not the case here. I was wondering if wxPython could test for float
arguments in these drawing methods and truncate or round to integers if
required.
It could be done, but it would create somewhat of a maintenance headache.
What would the performance hit be if this test was implemented.
Probably about the same as if you called int() everywhere, except that it would have to be done all the time even if the args were already ints.
A side note - I didn't get a deprecation warning for DrawLines. I would
have thought this would have suffered from the same problem.
Because it doesn't use one of the PyArg_Parse API functions to process the list.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
> Anthony Tuininga wrote:
> > The Python development team has decided (and I think with good reason)
> > that if you are calling PyArg_ParseTuple() and specifying that you are
> > expecting an integer, then you really ought to be passing an integer
> > through from your Python code.
This makes the
code very ugly and difficult to read if instead of
DrawLine( x1,y1,x2,y2)
we now (as I understand it) have to write
DrawLine( int(x1), int(y1), int(x2), int(y2))
Well, I'll have to trust Antony and the Python development team that the
change is a good one, but it's been a bit of a pain for me as well.
HOwever, as you pointed out the above code migth be better as:
Gordon Williams wrote:
> > Anthony Tuininga wrote:
> > > The Python development team has decided (and I think with good
> > > reason)
> > > that if you are calling PyArg_ParseTuple() and specifying that
> > > you are
> > > expecting an integer, then you really ought to be passing an
> > > integer
> > > through from your Python code.
> This makes the
> code very ugly and difficult to read if instead of
>
> DrawLine( x1,y1,x2,y2)
>
> we now (as I understand it) have to write
>
> DrawLine( int(x1), int(y1), int(x2), int(y2))
Well, I'll have to trust Antony and the Python development team that the
change is a good one, but it's been a bit of a pain for me as well.
HOwever, as you pointed out the above code migth be better as:
