Repository navigation
TypeError: truncate() takes no keyword arguments #58791
Description
Activity
TheBiggerGuy commented
on Apr 15, 2012 TheBiggerGuymannequinMannequinAuthorThe Python docs suggest that io.IOBase.truncate' should take a keyword argument of 'size'.
However this causes a 'TypeError':
TypeError: truncate() takes no keyword argumentsSuggest 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
http://docs.python.org/library/io.html?highlight=truncate#io.IOBase.truncateThe 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 :)
TheBiggerGuy commented
on Apr 16, 2012 TheBiggerGuymannequinMannequinAuthorWhat 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.
TheBiggerGuy commented
on Apr 16, 2012 TheBiggerGuymannequinMannequinAuthor@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.
TheBiggerGuy commented
on Apr 16, 2012 TheBiggerGuymannequinMannequinAuthorLooking 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:
truncate()
truncate(x)
truncate(size=x)
and fail on:
truncate(x, size=x)
truncate(x, size=y)Thoughts?
ps.
fileio_truncate is defined as
(PyCFunctionWithKeywords)fileio_truncate, METH_VARARGS | METH_KEYWORDS
but fails with "takes no keyword arguments". How do I fix this?TheBiggerGuy commented
on Apr 16, 2012 TheBiggerGuymannequinMannequinAuthorSorry 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.
This is my first time working with cpython directly, I have only worked on small python to c modules before so please say if I am barking up the wrong tree.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.
TheBiggerGuy commented
on Apr 17, 2012 TheBiggerGuymannequinMannequinAuthor@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
cpython | Python | Status
-----------------------+-------------------------------+-------
iobase_readlines | readline(limit=-1) | patch v2
iobase_readline | readlines(hint=-1) | patch v2
iobase_seek | seek(offset, whence=SEEK_SET) | patch v2
iobase_truncate | truncate(size=None) | patch v2
fileio_seek | seek(offset, whence=SEEK_SET) | patch v2
fileio_read | read(n=-1) | patch v2
textiowrapper_read | read(n=-1) | ToDo
textiowrapper_readline | readline(limit=-1) | ToDo
textiowrapper_seek | seek(offset, whence=SEEK_SET) | ToDo
textiowrapper_truncate | truncate(size=None) | ToDo
textiobase_read | read(n=-1) | ToDo
textiobase_readline | readline(limit=-1) | ToDo
{bufferedio.c} | | ToDo
{bytesio.c} | | ToDo
{stringio.c} | | ToDops.
I am using code from within other C files and http://docs.python.org/dev/extending/extending.html#keyword-parameters-for-extension-functions to base my patch on but I still get "x()" takes no keyword arguments". What have I missed/Are the docs correct?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().
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: