----- Original Message -----
From: "Guido van Rossum" <guido@python.org>
> > When you interface const-correct C or C++ code with Python, you
> > currently need to jump through hoops like this:
> >
> > somefunc(const char* modulename, const char* key)
> > {
> > ... PyImport_ImportModule(const_cast<char*>(modulename)) ...
> >
> >
> > I'd be willing to invest some time to change this, the question is:
> >
> > 1. someone opposed to such a change?
> >
> > 2. any technical reasons against it (const is ANSI, do we have a
> > portability problem that cannot be solved by a #define)?
> >
> > The largest negative effect I can see is that it'll add some
turbulence
> > to the CVS log (many little changes).
>
> -1.
>
> I've never tried to enforce const-correctness before, but I've heard
> enough horror stories about this. The problem is that it breaks 3rd
> party extensions left and right,
Only if you change the strings /returned/ by Python (or structure
members) to const char*. Changing your parameters to const char* won't
hurt anybody.
> and fixing those isn't always easy.
> In general, whenever you add a const somewhere, it ends up propagating
> to some other API, which then also requires a const, which propagates
> to yet another API needing a const, ad infinitum.
Pretty FUD-ly, Guido! That problem only happens to people that don't
really understand const and its implications. If you leave the job in
the hands of someone who's used const extensively there's no reason it
should cause serious problems.
-Dave
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