Re: [Python-Dev] Documenting the ssize_t Python C API changes
Fredrik Lundh wrote: >> - Usage of the "old" function pointer type name (e.g. intobjargproc) >>likely also indicates an error, since many of these pointers have >>changed there types. I believe the only exception for this is inquiry, >>which still has legit uses, in nb_nonzero, tp_clear, and tp_is_gc. > > is there a complete list of these somewhere ? This is actually in the PEP: the new types are ssizeargfunc ssizessizeargfunc ssizeobjargproc ssizessizeobjargproc lenfunc readbufferproc writebufferproc segcountproc charbufferproc These replace intargfunc intintargfunc intobjargproc intintobjargproc inquiry (partial) getreadbufferproc getwritebufferproc getsegcountproc getcharbufferproc 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Jeremy Hylton wrote: > It sounds more like the PEP should list these three categories and > tell developers that they need to inspect their code for instances of > them and fix them in the appropriate way. Perhaps with an example of > each. +1; I will do that. 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
On 3/21/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Don't you think developers are capable enough to judge for > themselves ? > > They might also want to change their extensions to make use > of the new possibilities, so a list of APIs taking Py_ssize_t > parameters on input would be handy to check where there's > potential for such a change in their code. > > Perhaps we should have three lists: > > 1. Py_ssize_t output parameters (these need changes) > 2. Py_ssize_t return values (these need overflow checks) > 3. Py_ssize_t input parameters (these can be used to enhance >the extension) It sounds more like the PEP should list these three categories and tell developers that they need to inspect their code for instances of them and fix them in the appropriate way. Perhaps with an example of each. Jeremy ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Martin v. Löwis wrote: > There are two improvements you could make: > - Some of the functions in the first list return Py_ssize_t; calling >them can cause truncation if the result value is larger than INT_MAX >(and it is assigned to an int). To find those functions, do >grep 'PyAPI_FUNC(Py_ssize_t)' Include/*.h fixed (based on the list MAL just posted). > - Usage of the "old" function pointer type name (e.g. intobjargproc) >likely also indicates an error, since many of these pointers have >changed there types. I believe the only exception for this is inquiry, >which still has legit uses, in nb_nonzero, tp_clear, and tp_is_gc. is there a complete list of these somewhere ? ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
M.-A. Lemburg wrote: > Perhaps we should have three lists: > > 1. Py_ssize_t output parameters (these need changes) > 2. Py_ssize_t return values (these need overflow checks) > 3. Py_ssize_t input parameters (these can be used to enhance >the extension) > > Here's the list for 2 (I already provided the list for 1 in the > other mail): thanks! I've updated the ssizecheck tool. ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Perhaps we should have three lists: >1. Py_ssize_t output parameters (these need changes) >2. Py_ssize_t return values (these need overflow checks) >3. Py_ssize_t input parameters (these can be used to enhance the extension) If I were an extension writer in a position to need these, I am sure I would prefer the three lists separated. (Where housed would otherwise be pretty irrelevant.) I know I would strongly prefer to have them be separate plain ascii text files linked to as appendixes rather than incorporated into the PEP itself. I might also like a separate doc (or wiki entry/ies) on updating extension to use Py_ssize_t, with more than one persons experiences, if indeed it it not trivial and straightforward. Terry Jan Reedy ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> Interesting: A few mails ago you suggested that developers >> do exactly what I did to get the list of changes. Now you >> gripe about the output format of the grep. > > Developers which use grep can read the output of grep. Developers > which use other methods of searching (e.g. Visual Studio) can > understand the output of these tools. I don't say they *should* > search for Py_ssize_t, I said they *can* if they want to. > > I still don't think anybody would *want* to read such a list. They don't necessarily want to read it, but like Fredrik did, use as input for their testing tools. >> I really don't understand what your problem is with documenting >> the work that you and others have put into this. Why is there >> so much resistance ? > > Because I think it is pointless, confusing, and redundant in a dangerous > way. There is absolutely NO problem with API changes where a function > consumes Py_ssize_t. Why should anybody care that > PyString_FromStringAndSize now consumes a Py_ssize_t? Passing an int > works just fine, and if the int fits the length of the string, it will > absolutely do the right thing. There is no need to touch that code, > or worry about the change. > > Putting PyString_FromStringAndSize into such a list *will* make > developers worry, because they now think they have to change their code > somehow, when there is absolutely for action. Don't you think developers are capable enough to judge for themselves ? They might also want to change their extensions to make use of the new possibilities, so a list of APIs taking Py_ssize_t parameters on input would be handy to check where there's potential for such a change in their code. Perhaps we should have three lists: 1. Py_ssize_t output parameters (these need changes) 2. Py_ssize_t return values (these need overflow checks) 3. Py_ssize_t input parameters (these can be used to enhance the extension) Here's the list for 2 (I already provided the list for 1 in the other mail): ./dictobject.h: -- PyAPI_FUNC(Py_ssize_t) PyDict_Size(PyObject *mp); ./tupleobject.h: -- PyAPI_FUNC(Py_ssize_t) PyTuple_Size(PyObject *); ./stringobject.h: -- PyAPI_FUNC(Py_ssize_t) PyString_Size(PyObject *); ./longobject.h: -- PyAPI_FUNC(Py_ssize_t) _PyLong_AsSsize_t(PyObject *); ./intobject.h: -- PyAPI_FUNC(Py_ssize_t) PyInt_AsSsize_t(PyObject *); ./abstract.h: -- PyAPI_FUNC(Py_ssize_t) PyObject_Size(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PyObject_Length(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) _PyObject_LengthHint(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PySequence_Size(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PySequence_Length(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PyMapping_Size(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PyMapping_Length(PyObject *o); ./unicodeobject.h: -- PyAPI_FUNC(Py_ssize_t) PyUnicode_GetSize( -- PyObject *unicode/* Unicode object */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_AsWideChar( -- PyUnicodeObject *unicode, /* Unicode object */ -- register wchar_t *w,/* wchar_t buffer */ -- Py_ssize_t size /* size of buffer */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_Tailmatch( -- PyObject *str, /* String */ -- PyObject *substr,/* Prefix or Suffix string */ -- Py_ssize_t start,/* Start index */ -- Py_ssize_t end, /* Stop index */ -- int direction/* Tail end: -1 prefix, +1 suffix */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_Find( -- PyObject *str, /* String */ -- PyObject *substr,/* Substring to find */ -- Py_ssize_t start,/* Start index */ -- Py_ssize_t end, /* Stop index */ -- int direction/* Find direction: +1 forward, -1 backward */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_Count( -- PyObject *str, /* String */ -- PyObject *substr,/* Substring to count */ -- Py_ssize_t start,/* Start index */ -- Py_ssize_t end /* Stop index */ -- ); ./listobject.h: -- PyAPI_FUNC(Py_ssize_t) PyList_Size(PyObject *); > Furthermore, it is redundant because there are now *four* places where > the signature of the API is mentioned: in the header, in the > implementation, in the API docs, and in the PEP. The compiler watches > for consistency of the first two; consistency of the others is a manual > process, and thus error-prone. It's a one-time operation, documenting the changes between Python 2.4 and 2.5 - much like the grand renaming in the C API a few years ago. You'd only create the lists once in the PEP, namely when Python 2.5 is released. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ...
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Fredrik Lundh wrote: > M.-A. Lemburg wrote: > >> Here's a grep of all the changed/new APIs, please include it >> in the PEP. > > I've posted a simple-minded source scanner here: > > http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py Very nice. Thanks ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
M.-A. Lemburg wrote: > Interesting: A few mails ago you suggested that developers > do exactly what I did to get the list of changes. Now you > gripe about the output format of the grep. Developers which use grep can read the output of grep. Developers which use other methods of searching (e.g. Visual Studio) can understand the output of these tools. I don't say they *should* search for Py_ssize_t, I said they *can* if they want to. I still don't think anybody would *want* to read such a list. > I really don't understand what your problem is with documenting > the work that you and others have put into this. Why is there > so much resistance ? Because I think it is pointless, confusing, and redundant in a dangerous way. There is absolutely NO problem with API changes where a function consumes Py_ssize_t. Why should anybody care that PyString_FromStringAndSize now consumes a Py_ssize_t? Passing an int works just fine, and if the int fits the length of the string, it will absolutely do the right thing. There is no need to touch that code, or worry about the change. Putting PyString_FromStringAndSize into such a list *will* make developers worry, because they now think they have to change their code somehow, when there is absolutely for action. Furthermore, it is redundant because there are now *four* places where the signature of the API is mentioned: in the header, in the implementation, in the API docs, and in the PEP. The compiler watches for consistency of the first two; consistency of the others is a manual process, and thus error-prone. 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Fredrik Lundh wrote: > I've posted a simple-minded source scanner here: > > http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py Great job! I've added a link to that to the PEP. There are two improvements you could make: - Some of the functions in the first list return Py_ssize_t; calling them can cause truncation if the result value is larger than INT_MAX (and it is assigned to an int). To find those functions, do grep 'PyAPI_FUNC(Py_ssize_t)' Include/*.h - Usage of the "old" function pointer type name (e.g. intobjargproc) likely also indicates an error, since many of these pointers have changed there types. I believe the only exception for this is inquiry, which still has legit uses, in nb_nonzero, tp_clear, and tp_is_gc. 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> Here's a grep of all the changed/new APIs, please include it >> in the PEP. > > You want me to include that *literally*? Are you serious? Feel free to format it in a different way. > Please go ahead and commit that change yourself: I consider > it completely unreadable and entirely worthless. Interesting: A few mails ago you suggested that developers do exactly what I did to get the list of changes. Now you gripe about the output format of the grep. I really don't understand what your problem is with documenting the work that you and others have put into this. Why is there so much resistance ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
M.-A. Lemburg wrote: > Here's a grep of all the changed/new APIs, please include it > in the PEP. You want me to include that *literally*? Are you serious? Please go ahead and commit that change yourself: I consider it completely unreadable and entirely worthless. 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
M.-A. Lemburg wrote: > Here's a grep of all the changed/new APIs, please include it > in the PEP. I've posted a simple-minded source scanner here: http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> It's not a waste of time at all: you'd be helping lots and >> lots of developers out there who want to fix their extensions. > > This is free software, anybody is free to decide what they do. With due respect for other developers, yes. > I don't believe that developers would be helped a lot - they > can easily search for Py_ssize_t in the header files, and > find all the APIs that have changed. Of course they can. We could also stop writing documentation and tell users to read the code instead - after all, it's all there, ready to be consumed by interested parties. Oh, and for changes: we'll just point them to Subversion and tell them to run a 'svn diff'. > However, they *should* not have to do that. Instead, they > should look at it from a conceptual point of view: Does > that variable "count" something (memory, number of elements, > size of some structure). If it does, and it currently counts > that using an int, it should be changed to use a Py_ssize_t > instead. > > So just review all occurrences of int in your code, and you > are done. No need to look at API lists. Just did a grep on the mx Extensions: 17000 cases of 'int' being used. Sounds like a nice weekend activity... Seriously, your suggestion on how to port the extensions to Py_ssize_t is certainly true, but this may not be what all extension authors would want to do (or at least not right away). Instead, they'll want to know what changed and then check their code for uses of the changed APIs, in particular those APIs where output parameters are used. I think that documenting these changes is part of doing responsible development. You seem to disagree. >> The ssize_t patch is the single most disruptive patch in >> Python 2.5, so it deserves special attention. > > I can believe you that you would have preferred not to see > that patch at all, not at this time, and preferably never. > I have a different view. I don't see it as a problem, but > as a solution. You are right in that I would have rather seen this change go into Py3k than into the 2.x series. You're wrong in saying that I would have preferred not to get such a change into Python at all. I've given up believing that there would be a possibility of having code that works in both Py3k and Py2.x. I've also given up, believing that code written for Py2.x will continue to work in Py3k. I still holding on to the belief that the 2.x will not introduce major breakage between the versions and that there'll always be some way to write software that works in 2.n and 2.n+1 for any n. However, I feel that at least some Python developers seem to be OK with breaking this possibility, ignoring all the existing working code that's out there. > Again, if you think the documentation should be improved, > go ahead and improve it. Here's a grep of all the changed/new APIs, please include it in the PEP. ./dictobject.h: -- PyAPI_FUNC(int) PyDict_Next( -- PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value); -- PyAPI_FUNC(Py_ssize_t) PyDict_Size(PyObject *mp); ./pyerrors.h: -- PyAPI_FUNC(PyObject *) PyUnicodeDecodeError_Create( -- const char *, const char *, Py_ssize_t, Py_ssize_t, Py_ssize_t, const char *); -- PyAPI_FUNC(PyObject *) PyUnicodeEncodeError_Create( -- const char *, const Py_UNICODE *, Py_ssize_t, Py_ssize_t, Py_ssize_t, const char *); -- PyAPI_FUNC(PyObject *) PyUnicodeTranslateError_Create( -- const Py_UNICODE *, Py_ssize_t, Py_ssize_t, Py_ssize_t, const char *); -- PyAPI_FUNC(int) PyUnicodeEncodeError_GetStart(PyObject *, Py_ssize_t *); -- PyAPI_FUNC(int) PyUnicodeDecodeError_GetStart(PyObject *, Py_ssize_t *); -- PyAPI_FUNC(int) PyUnicodeTranslateError_GetStart(PyObject *, Py_ssize_t *); -- PyAPI_FUNC(int) PyUnicodeEncodeError_SetStart(PyObject *, Py_ssize_t); -- PyAPI_FUNC(int) PyUnicodeDecodeError_SetStart(PyObject *, Py_ssize_t); -- PyAPI_FUNC(int) PyUnicodeTranslateError_SetStart(PyObject *, Py_ssize_t); -- PyAPI_FUNC(int) PyUnicodeEncodeError_GetEnd(PyObject *, Py_ssize_t *); -- PyAPI_FUNC(int) PyUnicodeDecodeError_GetEnd(PyObject *, Py_ssize_t *); -- PyAPI_FUNC(int) PyUnicodeTranslateError_GetEnd(PyObject *, Py_ssize_t *); -- PyAPI_FUNC(int) PyUnicodeEncodeError_SetEnd(PyObject *, Py_ssize_t); -- PyAPI_FUNC(int) PyUnicodeDecodeError_SetEnd(PyObject *, Py_ssize_t); -- PyAPI_FUNC(int) PyUnicodeTranslateError_SetEnd(PyObject *, Py_ssize_t); ./tupleobject.h: -- PyAPI_FUNC(PyObject *) PyTuple_New(Py_ssize_t size); -- PyAPI_FUNC(Py_ssize_t) PyTuple_Size(PyObject *); -- PyAPI_FUNC(PyObject *) PyTuple_GetItem(PyObject *, Py_ssize_t); -- PyAPI_FUNC(int) PyTuple_SetItem(PyObject *, Py_ssize_t, PyObject *); -- PyAPI_FUNC(PyObject *) PyTuple_GetSlice(PyObject *, Py_ssize_t, Py_ssize_t); -- PyAPI_FUNC(int) _PyTuple_Resize(PyObject **, Py_ssize_t); -- PyAPI_FUNC(PyObject *) PyTuple_Pack(Py_ssize_t, ...); ./sliceobject.h: -- PyAPI_FUNC(int) PySlice_GetIndices(PySliceObject *r, Py_ssize_t length, --
Re: [Python-Dev] Documenting the ssize_t Python C API changes
"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Michael Hudson wrote: > >> > The ssize_t patch is the single most disruptive patch in >> > Python 2.5, so it deserves special attention. >> >> From your POV, maybe: from mine, it's definitely the new compiler. > > in what way does the new compiler affect third-party developers ? It has subtle bugs in it. I guess when it's working it has little effect and in that way it's less disruptive than the ssize_t branch. Cheers, mwh -- today's lesson don't strace X in an xterm -- from Twisted.Quotes ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Michael Hudson wrote: > > The ssize_t patch is the single most disruptive patch in > > Python 2.5, so it deserves special attention. > > From your POV, maybe: from mine, it's definitely the new compiler. in what way does the new compiler affect third-party developers ? ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > The ssize_t patch is the single most disruptive patch in > Python 2.5, so it deserves special attention. >From your POV, maybe: from mine, it's definitely the new compiler. Cheers, mwh -- I reject that approach. It has a suspicious lack of internet. -- from Twisted.Quotes ___ 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
M.-A. Lemburg wrote: > It's not a waste of time at all: you'd be helping lots and > lots of developers out there who want to fix their extensions. This is free software, anybody is free to decide what they do. I don't believe that developers would be helped a lot - they can easily search for Py_ssize_t in the header files, and find all the APIs that have changed. However, they *should* not have to do that. Instead, they should look at it from a conceptual point of view: Does that variable "count" something (memory, number of elements, size of some structure). If it does, and it currently counts that using an int, it should be changed to use a Py_ssize_t instead. So just review all occurrences of int in your code, and you are done. No need to look at API lists. > The ssize_t patch is the single most disruptive patch in > Python 2.5, so it deserves special attention. I can believe you that you would have preferred not to see that patch at all, not at this time, and preferably never. I have a different view. I don't see it as a problem, but as a solution. Again, if you think the documentation should be improved, go ahead and improve it. 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
Re: [Python-Dev] Documenting the ssize_t Python C API changes
Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> I really don't understand why you put so much effort into >> trying to argue that the ssize_t patch isn't going to break >> extensions or that fixing compiler warnings is good enough. > > Well, in *this* thread, my main point is that I don't want > to provide the list that you demand, mainly because I consider > it a waste of my time to create it. It's not a waste of time at all: you'd be helping lots and lots of developers out there who want to fix their extensions. Apart from that I can only repeat what I said before: you expect developers to put lots of time into fixing their extensions to run with Python 2.5, so it's only fair that you invest some time into making it as easy as possible for them. The ssize_t patch is the single most disruptive patch in Python 2.5, so it deserves special attention. >> I consider the fact that it's currently not possible to have >> a look at the changed APIs a documentation which is in the >> responsibility of the patch authors to provide (just like it >> always is). > > It is possible to look at the changed APIs, see > > http://docs.python.org/dev/api/sequence.html That's neither a complete list (see the grep I sent), nor does it highlight the changes. The API documentation is not the right place for the documentation of this change, IMHO, since it always refers to the current state in a specific Python release and not the changes applied to an API compared to an older release. The PEP is the perfect place for such a list, I guess. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 20 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
