Repository navigation
PyArg_ParseTupleAndKeywords doesn't take const char *keywords[]Â #65210
Description
| BPO | 21011 |
|---|---|
| Nosy | @methane, @serhiy-storchaka, @MojoVampire, @hvenev |
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:
assignee = None
closed_at = None
created_at = <Date 2014-03-21.16:45:16.140>
labels = ['extension-modules', 'type-feature', '3.8']
title = "PyArg_ParseTupleAndKeywords doesn't take const char *keywords[]"
updated_at = <Date 2018-07-03.09:45:24.075>
user = 'https://github.com/hvenev'bugs.python.org fields:
activity = <Date 2018-07-03.09:45:24.075>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2014-03-21.16:45:16.140>
creator = 'h.venev'
dependencies = []
files = []
hgrepos = []
issue_num = 21011
keywords = []
message_count = 4.0
messages = ['214388', '214857', '320945', '320952']
nosy_count = 4.0
nosy_names = ['methane', 'serhiy.storchaka', 'josh.r', 'h.venev']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21011'
versions = ['Python 3.8']
Activity
hvenev commentedon Mar 21, 2014
This really annoys me. I have to store the literals in char[] and then make a char*[] from them. It would be better if a simple array of string literals could be used. It would also require less data space because string literals could be merged by the compiler.
I don't know why PyArg_ParseTupleAndKeywords would ever modify the keywords array so it makes absolutely no sense to me for the array not to be const char*[].
In all cases I have seen PyArg_ParseTupleAndKeywords being used string literals were converted to char* (dropping const) which is far far worse than inefficient code.
MojoVampire commentedon Mar 25, 2014
This has come up before. Links to additional info:
https://mail.python.org/pipermail/python-dev/2006-February/060689.html
http://bugs.python.org/issue1772673
methane commentedon Jul 3, 2018
I think we can't fix this until Python 4.
May I close this issue as "won't fix" for now?
Or can we add "Python 4" keyword to list backward incompatible changes we want to do in the future?
serhiy-storchaka commentedon Jul 3, 2018
We can't change this API because this would break virtually all user code.
But we can introduce a macro like PY_SSIZE_T_CLEAN. If it is defined before including Python.h, PyArg_ParseTupleAndKeywords() will take an array of const strings. This will help for compatibility with C++.
pythongh-65210: Add const qualifiers in PyArg_VaParseTupleAndKeywords()
serhiy-storchaka commentedon Jun 21, 2023
We can fix this at least for C++, because in C++ the
const char * const *declaration is compatible with arguments of typeconst char * const *,char * const *,const char **, andchar **.Sad, it is not so in C, but we can provide a lever to control the declaration, and may change the default in distant future.
gh-65210: Add const qualifiers in PyArg_VaParseTupleAndKeywords() (GHâĶ
pythongh-65210: Add const qualifiers in PyArg_VaParseTupleAndKeywordsâĶ
pythongh-65210: Add const qualifiers in PyArg_VaParseTupleAndKeywordsâĶ