i've got a couple observations for this change to ParseTuple.
for my personal extension code, i actually benefit from the features of
automatic float-to-int conversion. if this is going to change i'll
indeed be updating my libraries. unfortunately it seems to workaround
this requires a lot of extra code. simple parsing must now become a set
of blocks and cases. (no error handling in these examples...)
PyArg_ParseTuple("is", &x, &text);
becomes
PyArg_ParseTuple("os", &objx, &text);
if((tmp=PyNumber_Int(objx))
{
x = PyInt_AsLong(tmp);
Py_DECREF(tmp);
}
naturally i'll be reducing that block to some function i can call, but
it adds an extra step of typechecking and error reporting for each
integer argument in my function. I'd really prefer a method to get the
current behavior, perhaps "I" in the format string would be a logical
choice?
in the same context, i'm wondering if the "s" formatting should change
also? currently you can pass unicode or string objects and they get
properly converted. i use so little of unicode my input may be totally
invalid, but it seems float->int is approximate to unicode->string ?
i'm not sure what (if anything) should be done about this, but didn't
see it mentioned in the thread.
lastly, as a contrived example. to insert an item in the middle of a
list is pretty simple,
mylist.insert(len(mylist)/2, myval)
with the new integer division, this would pass a float into an integer
argment(?). just food for thought, wondering what the expected behaviour
of this would be?
my coming from a C background makes this float to int conversion pretty
natural to my mind. but i can see how that doesn't always make it a good
idea. sorry if my post is not desired, it's my first to python-dev, but
i've been lurking for a few weeks.
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