> > > -1 on removing PyArg_NoArgs() ... this API is still in very active > > > use in third party extensions. > > > > Would it be OK if it issued a warning? > > Hmm, people would start screaming, I guess -- this API is used > far more than e.g. the regex/regsub module combo. A one-time-per- > module warning would probably be OK though. That's what I wanted, but now that you mention it I'm not sure if the warning module can currrently detect from which module a particular C API is called -- it'll probably put the blame on a particular line in the user's code, and then repeat the warning for each *different* line of user code. > I seriously think that we should install a set of common > third party extensions somewhere to that we can easily > check usage of the APIs in the outside world, e.g. take > the packages Aahz collected recently and unzip them to > some directory on python.org. A grep would then quickly > produce proof of "common" usage. +1 > > > I'd suggest to have a PEP which documents all C API changes > > > or deprecations together with a short decsription of how to > > > update old code. > > > > It shouldn't be a PEP (that's a *proposal*). It should be part of > > the C API docs, possibly an appendix. > > I was thinking of an informational PEP -- mostly because PEPs > are easily accessible and also simple to write (LaTeX is not > everybody's friend ;-). Yeah, that's fine. Let whoever writes it decide on the format. :-) > True, but there are other instances where this was a problem > in the past, e.g. > > #if PY_VERSION_HEX < 0x01060000 > > #if !defined(PyObject_DEL) > # define PyObject_DEL(x) free(x) > # define PyObject_Del(x) free(x) > #endif > > #endif Why the PY_VERSION_HEX guard? Isn't the !defined() guard enough? --Guido van Rossum (home page: http://www.python.org/~guido/)
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