A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/060703.html below:

[Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification

[Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modificationTim Peters tim.peters at gmail.com
Fri Feb 10 18:54:17 CET 2006
[Jeremy]
>> I added some const to several API functions that take char* but
>> typically called by passing string literals.  In C++, a string literal
>> is a const char* so you need to add a const_cast<> to every call site,
>> which is incredibly cumbersome.  After some discussion on python-dev,
>> I made changes to a small set of API functions and chased the
>> const-ness the rest of the way, as you would expect.  There was
>> nothing random about the places const was added.

[Guido]
> I still don't understand *why* this was done,

Primarily to make life easier for C++ programmers using Python's C
API.  But didn't Jeremy just say that?

Some people (including me) have been adding const to char* API
arguments for years, but in much slower motion, and at least I did it
only when someone complained about a specific function.

> nor how the set of functions was chosen if not randomly.

    [Jeremy]
    I added some const to several API functions that take char* but
    typically called by passing string literals.

If he had _stuck_ to that, we wouldn't be having this discussion :-) 
(that is, nobody passes string literals to
PyArg_ParseTupleAndKeywords's kws argument).
More information about the Python-Dev mailing list

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