Just van Rossum wrote: > ... > which I'm mostly to blame) in which there are lots of calls to Mac > toolbox functions that take geometric values (coordinates, rectangles) > where the units are pixels. There are plenty of cases where the > intermediates for these values have to be floats and it's simply darned > convenient they are chopped to ints. I'm not saying this is good in > ... coincidentally, this is nearly the same reason i am using the automatic truncation. converting arbitrary object positions into 'pixel' positions. it is convenient to not worry about your coordinate types, just passing them in and getting 'the right thing'. assuming the current behavior is 'the right thing', which is the issue in question. i am not opposed to the stricter handling of integer arguments, but cannot see any similar alternatives to what we have now.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4