This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: TypeError: truncate() takes no keyword arguments
Type: behavior Stage: needs patch
Components: Documentation, Interpreter Core Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: TheBiggerGuy, berker.peksag, docs@python, georg.brandl, martin.panter, pitrou, r.david.murray
Priority: normal Keywords: patch

Created on 2012-04-15 02:04 by TheBiggerGuy, last changed 2022-04-11 14:57 by admin.

Files
File name Uploaded Description Edit
test.py TheBiggerGuy, 2012-04-15 02:04 Test file
truncate.ver1.patch TheBiggerGuy, 2012-04-16 21:56 First Version allowing both positional and keyword parameters review
truncate.ver2.patch TheBiggerGuy, 2012-04-17 09:40 Second Version (still needs work) review
Messages (14)
msg158308 - (view) Author: Guy Taylor (TheBiggerGuy) Date: 2012-04-15 02:04
The Python docs suggest that io.IOBase.truncate' should take a keyword argument of 'size'.
However this causes a 'TypeError':
  TypeError: truncate() takes no keyword arguments

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
http://docs.python.org/library/io.html?highlight=truncate#io.IOBase.truncate
msg158388 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-16 01:07
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 :)
msg158403 - (view) Author: Guy Taylor (TheBiggerGuy) Date: 2012-04-16 07:47
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....?
msg158410 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-16 11:34
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.
msg158494 - (view) Author: Guy Taylor (TheBiggerGuy) Date: 2012-04-16 19:48
@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.
msg158495 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-16 20:01
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 issue 8706 for more details.
msg158507 - (view) Author: Guy Taylor (TheBiggerGuy) Date: 2012-04-16 21:56
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:
 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?
msg158509 - (view) Author: Guy Taylor (TheBiggerGuy) Date: 2012-04-16 22:04
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.
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.
msg158513 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-04-16 22:58
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.
msg158535 - (view) Author: Guy Taylor (TheBiggerGuy) Date: 2012-04-17 09:40
@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}           |                               | ToDo

ps.
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?
msg158547 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-17 12:13
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.
msg158548 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-17 12:14
macro, function...something automated, anyway :)
msg244937 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-06-07 01:04
See also Issue 23738 and PEP 457 for fixing the documentation instead, possibly something like truncate(size=None, /). Also, Issue 17003 has changed some of the keywords to be more consistent, making parts of this patch incorrect.
msg251139 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-09-20 05:24
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 Issue 25057, also proposing keyword arguments for seek().
History
Date User Action Args
2022-04-11 14:57:29adminsetgithub: 58791
2020-12-15 23:28:33iritkatrielsetversions: + Python 3.10, - Python 2.7, Python 3.2, Python 3.3
2015-09-20 05:24:31martin.pantersetmessages: + msg251139
2015-09-20 05:13:28martin.panterlinkissue23738 dependencies
2015-06-07 01:04:49martin.pantersetnosy: + martin.panter
messages: + msg244937
2015-06-06 14:30:08berker.peksagsetnosy: + berker.peksag
2012-04-17 12:14:04r.david.murraysetmessages: + msg158548
2012-04-17 12:13:31r.david.murraysetmessages: + msg158547
2012-04-17 09:40:30TheBiggerGuysetfiles: + truncate.ver2.patch

messages: + msg158535
2012-04-16 22:58:42georg.brandlsetnosy: + georg.brandl
messages: + msg158513
2012-04-16 22:04:33TheBiggerGuysetmessages: + msg158509
2012-04-16 21:56:04TheBiggerGuysetfiles: + truncate.ver1.patch
keywords: + patch
messages: + msg158507
2012-04-16 20:01:56r.david.murraysetmessages: + msg158495
2012-04-16 19:48:15TheBiggerGuysetmessages: + msg158494
2012-04-16 11:34:35r.david.murraysetmessages: + msg158410
2012-04-16 07:47:43TheBiggerGuysetmessages: + msg158403
2012-04-16 01:07:05r.david.murraysetversions: + Python 3.3
nosy: + r.david.murray, pitrou

messages: + msg158388

stage: needs patch
2012-04-15 02:04:32TheBiggerGuycreate