New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: truncate() takes no keyword arguments #58791
Comments
The Python docs suggest that io.IOBase.truncate' should take a keyword argument of 'size'. Suggest that the docs are changed to 'truncate(size)' or CPython is changed to allow the keyword. http://docs.python.org/py3k/library/io.html?highlight=truncate#io.IOBase.truncate |
The suggested doc change won't work, since that would imply that the size argument was required. We'd have to use the old truncate([size]) notation. Supporting it as a keyword argument is probably to be preferred, but someone will have to write the patch :) |
What ever change is made to the new CPythons the old docs should be updated to prevent confusion, with truncate([size]). On fixing it for the future I would agree that supporting it as a keyword argument is preferred, as it is more pythonic (in my opinion). However this would cause ether backwards incompatibility or ambiguity in the language (ie. truncate(0, size=1) or need the deprecate, warn then removal stages taken three release cycles). Maybe the less perfect but acceptable solution is just to change the docs and wait for Python 4k for the real fix....? |
There wouldn't be serious backward incompatibility. Truncate(0) would still mean the same thing as truncate(size=0). I don't remember if we treat supporting the keyword form when it is doced that as a bug or not, though, so you might be right that it can't be backported. |
@murray The thing I would be worried at in both supporting truncate(0) and truncate(size=0) would be truncate(0, size=1). This could throw an exception but causes the need for extra sanity checks and introduces ambiguity in the otherwise 'only one way to do something' Python style. |
I think you misunderstand the way that python arguments work. If you have a function so: def func(size=None): Then func(0) and func(size=0) are equivalent, and func(0, size=0) is a TypeError because you've provided two arguments instead of just one. The C code *can* emulate this, but often doesn't (it just accepts positional arguments instead). An issue was raised about changing most C functions to support the keyword syntax, but I believe it was decided that while in general doing so is good we'd only do it on a case by case basis as they came up. See bpo-8706 for more details. |
Looking through cpython and trying to form a patch I found several differing interpretations of truncate:
Lib/_pyio.py
def truncate(self, pos=None):
Modules/_io/fileio.c
PyDoc_STRVAR(truncate_doc, "truncate([size: int]) ..."); A first semi-working patch is attached. This will allow: Thoughts? ps. |
Sorry had not refreshed the page to pick up the last comment. After reading more the cpython code I get what you are saying now. Not a fan of that syntax but consistency is best. |
The patch is wrong: PyArg_ParseTupleAndKeywords already handles the correct assignment of positional and keyword args, and raises exceptions accordingly. Did you test that code? The question is also: why only truncate()? There are several other fileio_* methods that take VARARGS only. |
@Brandl truncate() was the issue I ran into, no other reason. I have started on the rest of the IO module tho. I know the patch is not working but I ran into problems with getting cpython to change functions from positional to keyword. @ALL ps. |
Ah, I'm glad someone else chimed in. I was going to say that I was pretty sure we had a macro for doing this, but I don't do much C level coding so I didn't have a reference handy. |
macro, function...something automated, anyway :) |
I agree with Guy’s earlier comments and would prefer this be fixed in the documentation. Otherwise, we would end up with third party IOBase implementations that use the wrong keyword name, or that don’t accept keywords at all. These would no longer be compatible with the new API. Also the new patch competes with bpo-25057, also proposing keyword arguments for seek(). |
Fixed per #91950 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: