M.-A. Lemburg wrote: > Right, but I don't see the point of each and every > extension having to go through these hoops when you > could add support for these checks (including error > reporting) to the few APIs in question, in particular > the PyArg_ParseTuple() API.
I don't want to rename the existing APIs, so porters to ssize_t have an easier life (just fix the compiler warnings). As for PyArg_ParseTuple: this already works and requires no changes either way. > I don't expect this to happen any time soon for the ten or > twenty other 3rd party extensions we regularly use and this > would prevent an upgrade to Python 2.5. It shouldn't. It could sensibly prevent an upgrade to 64-bit machines, but there would be no reason not to upgrade on 32-bit machines. > In particular, functions that currently take int* output > parameters should continue to do so. New functions should be > revised to enable Py_ssize_t* output arguments and preseve > backwards compatibility. > > (This also includes the strategy to be used, so you can > remove the note on strategy) Will do. > Please also add a comment on the fact that extensions > which haven't been recompiled for the Python 2.5 API > will not get imported (the API_LEVEL check should consistently > fail for these instead of just issuing a warning). I will add it as an open issue. I disagree that this should actually be done. >>Would you like to write a specification for that? > > > Sure, if there's hope to get this into the code. I don't know. So far, you are the only one wanting this kind of change. If the change actually existed, more people might be willing to voice an opinion - whether that will be in favour of more hackishness and backwards compatibility, or against, I cannot guess. I would personally want to restrict hackishness to places that the compiler doesn't warn about. >>To simplify the porting. > > > Sorry, I lost you there: > > I'm saying that two sets of APIs (one for int*, one > for Py_ssize_t*) will make porting easier since > updated code will only have to rename the APIs > used. Furthermore, it will allow to write code > that easily works in Python 2.1-2.4 as well as > Python 2.5. Yes, but users of the new API (who would conceptually do the right thing) would need more effort, just to protect users who do nothing (which conceptually do the wrong thing). By just editing the APIs (instead of also renaming them), I simplify the porting. > I'm talking about the few APIs that use output parameters. > Those do support error reporting. Hmm. I think I could personally accept a change that uses macro tricks to do all that, i.e. keep the output parameters at int* if some macro (Py_SIZE_T_CLEAN) is not defined, and use Py_ssize_t* if it is defined. People would then get the right warnings still, but no changes would be necessary to "old" code. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
