On Sun, Nov 23, 2008 at 3:16 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > On Sat, Nov 22, 2008 at 11:51 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > >> On Sat, Nov 22, 2008 at 06:29, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On Nov 22, 2008, at 4:05 AM, Martin v. Löwis wrote: >> > >> >> I just noticed that the Python 3 C API still contains PY_SSIZE_T_CLEAN. >> >> >> >> This macro was a transition mechanism, to allow extensions to use >> >> Py_ssize_t in PyArg_ParseTuple, while allowing other module continue >> >> to use int. >> >> >> >> In Python 3, I would like the mechanism, making Py_ssize_t the only >> >> valid data type for size in, say, s# parsers. >> >> >> >> Is it ok to still change that? >> > >> > Given that we just released the last planned candidate, I'd say it was >> too >> > late to change this for Python 3.0. >> > >> >> But we can at least document that the macro is a gone as soon as 3.0 >> final is out the door. >> >> -Brett > > > I'll commit the following update to the py3k docs if nobody objects. As it > is now, the only mention of PY_SSIZE_T_CLEAR at all is in whatsnew/2.5.rst. > This officially documents it and mentions that it is going away to be always > on in the future. I'm assuming in 3.1 but I just left it as "a future > version" to not commit to that. At least the py3k docs encourage use of s* > rather than s#. > > -gps > Wording fixed slightly and committed as r67361. > > > Index: Doc/extending/extending.rst > =================================================================== > --- Doc/extending/extending.rst (revision 67360) > +++ Doc/extending/extending.rst (working copy) > @@ -587,11 +587,16 @@ > > Some example calls:: > > + #define PY_SSIZE_T_CLEAN /* Make "s#" use Py_ssize_t rather than int. > */ > + #include <Python.h> > + > +:: > + > int ok; > int i, j; > long k, l; > const char *s; > - int size; > + Py_ssize_t size; > > ok = PyArg_ParseTuple(args, ""); /* No arguments */ > /* Python call: f() */ > Index: Doc/c-api/arg.rst > =================================================================== > --- Doc/c-api/arg.rst (revision 67360) > +++ Doc/c-api/arg.rst (working copy) > @@ -42,12 +42,19 @@ > responsible** for calling ``PyBuffer_Release`` with the structure after > it > has processed the data. > > -``s#`` (string, Unicode or any read buffer compatible object) [const char > \*, int] > +``s#`` (string, Unicode or any read buffer compatible object) [const char > \*, int or :ctype:`Py_ssize_t`] > This variant on ``s*`` stores into two C variables, the first one a > pointer > to a character string, the second one its length. All other > read-buffer > compatible objects pass back a reference to the raw internal data > representation. Since this format doesn't allow writable buffer > compatible > - objects like byte arrays, ``s*`` is to be preferred. > + objects like byte arrays, ``s*`` is to be preferred. The type of > + the length argument (int or :ctype:`Py_ssize_t`) is controlled by > + defining the macro :cmacro:`PY_SSIZE_T_CLEAN` before including > + :file:`Python.h`. If the macro was defined, the output will be a > + :ctype:`Py_ssize_t` rather than an int. > + This behavior will change in a future Python version to only support > + :ctype:`Py_ssize_t` and drop int support. It is best to always > + define :cmacro:`PY_SSIZE_T_CLEAN`. > > ``y`` (bytes object) [const char \*] > This variant on ``s`` converts a Python bytes or bytearray object to a > C > >
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
