Re: [Python-Dev] GeneratorExit inheriting from Exception
Michael Chermside <[EMAIL PROTECTED]> wrote: > > Barry writes: > > I still believe in this, and I'm thankful for the support I've seen. It > > won't happen for Python 2.x, but I do plan on addressing this for Py3K. > > When you do, I'd like you to consider one change to the names. You are > proposing this: > > > Exception > > +- KeyboardInterrupt > > +- GeneratorExit > > +- SystemExit > > +- StopIteration > > +- Error > > | +- ImportError > > | +- (etc.) > [...] > > If we use that structure, I still strongly feel that what you call "Error" > ought to be named "Exception" (and what you call "Exception" should be > named "BaseException" or perhaps "Raisable"). The reason is this: [snip some good reasons] +1 for those good reasons and others. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in x86 gentoo trunk
The Buildbot has detected a new failure of x86 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/97 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: georg.brandl Build Had Warnings: warnings test sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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" <[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 [email protected] 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
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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3000 Process
On Mon, 2006-03-20 at 20:06 -0800, Guido van Rossum wrote: > There's also a list for Python-3000-related checkins. Don't subscribe > to that one yet, it's very boring and uninteresting. Also, Barry > hasn't done the svn magic yet. :-) We're having a small problem on the svn box which requires Thomas's intervention, so it might be a little while. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in amd64 gentoo trunk
The Buildbot has detected a new failure of amd64 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/100 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: martin.v.loewis Build Had Warnings: warnings test sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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: > 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 [email protected] 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
"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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43126 - in python/trunk: Doc/lib/libsocket.tex Lib/socket.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
[attribution lost] Looking into the library, I see many accessor functions starting with either get_ or get; however, I don't recall why that could have been relevant for socket objects. [attribution lost] >>> If you think that should be changed to attributes, we should >>> do that. [Guido] >> Accessor functions are typical for APIs translated too literally from >> Java. (threading.py being an example :-( ) >> >> I'd like to change this as long as we're doing greenfield API design. [Georg Brandl] > Does that mean to change it to attributes? > (since I'm no professional BDFL channeler I could have misread your > sentence ;) Yup, that's what it means. In addition, the "greenfield" part meant specifically they should be changed to read-only attributes. One trick to professional channeling is to do the Pythonic thing, and then just pretend you read Guido's mind. Of course I'm _way_ beyond that :-) ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43126 - in python/trunk: Doc/lib/libsocket.tex Lib/socket.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
Tim Peters wrote: > [Guido] >>> Accessor functions are typical for APIs translated too literally from >>> Java. (threading.py being an example :-( ) >>> >>> I'd like to change this as long as we're doing greenfield API design. > > [Georg Brandl] >> Does that mean to change it to attributes? >> (since I'm no professional BDFL channeler I could have misread your >> sentence ;) > > Yup, that's what it means. In addition, the "greenfield" part meant > specifically they should be changed to read-only attributes. Thank you! Changed in rev. 43196. > One trick to professional channeling is to do the Pythonic thing, and > then just pretend you read Guido's mind. Of course I'm _way_ beyond > that :-) One day, I want to become like you! ;) Cheers, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in x86 XP-2 trunk
The Buildbot has detected a new failure of x86 XP-2 trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/83 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: barry.warsaw Build Had Warnings: warnings failed slave lost sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot failure in x86 XP-2 trunk
The Buildbot has detected a new failure of x86 XP-2 trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/84 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: The web-page 'force build' button was pressed by 'Tim': lost connection Build Source Stamp: [branch trunk] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in g4 osx.4 trunk
The Buildbot has detected a new failure of g4 osx.4 trunk. Full details are available at: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/94 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: georg.brandl Build Had Warnings: warnings test sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] 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: >> - 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] supported platforms OS2?
Jim Jewett wrote: > Is OS2 still actively supported? If you mean, is Python still actively supported on OS/2, then the answer is yes. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] supported platforms OS2?
Andrew MacIntyre wrote: > Jim Jewett wrote: > >> Is OS2 still actively supported? > > If you mean, is Python still actively supported on OS/2, then the answer > is yes. Just to clarify, I haven't been actively monitoring other changes for impact on the OS/2 port for the last few months (too much happening in the rest of my life), but am getting back into the swing of things now that I have a SVN checkout to work from. Barring disaster, there will be a 2.5 release of the OS/2 port. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] svn checkins are now split
I believe I've figured out the magic to split checkin messages so that python/branches/p3yk goes to python-3000-checkins and everything else goes to python-checkins. Let me know if you notice any problems, and feel free to subscribe to whichever list(s) you're interested in. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in amd64 gentoo trunk
The Buildbot has detected a new failure of amd64 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/105 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: barry.warsaw Build Had Warnings: warnings test sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
Is it your intent to push for more use of the abstract API instead of the concrete APIs for all of Python's C data structures? Current API aside, are you advocating this approach for all new built-in types? Would you argue that Python 3.0's C API be stripped of everything but the abstract API and the bare essentials of the concrete API? If so, then I think this is extremely misguided. C is not Python, and while the abstract API is useful for some things, so is the concrete API. In fact, the Python C API's clarity, utility, completeness, and discoverability has made Python one of the nicest languages to embed and extend, and I see no reason to deviate from that for the sake of blind TOOWTDI worship. We have a rich tradition of providing both concrete and abstract APIs at the C layer, and I think that's a good thing that we should continue here. On Mon, 2006-03-20 at 03:44 -0500, Raymond Hettinger wrote: > PySet_Clear() > - > Use PyObject_CallMethod(s, "clear", NULL). > > Or if you need to save a millisecond on an O(n) operation, use > PyNumber_InPlaceSubtract(s,s) as shown in the docs. If the name bugs you, it > only takes a one-line macro to define a wrapper. The set API should not be > cluttered with unnecessary and redundant functions. This is a great example of what I'm talking about. You lose some static C compiler checks when you use either of these alternatives. C is not Python and we shouldn't try to make it so. The documentation is much less concise too, and if macros are encouraged, then every extension will invent their own name, further reducing readability, or use the obvious choice of PySet_Clear() and then question why Python doesn't provide this itself. This also has a detrimental effect on debugging. Macros suck for debugging and going through all the abstract API layers sucks. A nice, clean, direct call is so much more embedder-friendly. In addition, you essentially have all the pieces for PySet_Clear() right there in front of you, so why not expose them to embedders and make their lives easier? Forcing them to go through the abstract API or use obscure alternatives does not improve the API. It seems a false economy to not include concrete API calls just to end up back in setobject.c after layers of indirection. > PySet_Next() > > This is also redundant. The preferred way to iterate over a set should be > PyObject_GetIter(s). The iter api is generic and works for all containers. > It > ought to be the one-way-to-do-it. For the C API, I disagree for the reasons stated above. In this specific case, using the iterator API actually imposes more pain on embedders because there are more things you have to keep track of and that can go wrong. PyDict_Next() is a very nice and direct API, where you often don't have to worry about reference counting (borrowed refs in this case are the right thing to return). You also don't have to worry about error conditions, and both of these things reduce bugs because it usually means less code. PySet_Next() would provide the same benefits. I don't buy the safety argument against PyDict_Next()/PySet_Next() because they are clearly documented as requiring no modification during iteration. Again, this is what I mean by useful concrete vs. abstract APIs. When you /know/ you have a set and you /know/ you won't be modifying it, PySet_Next() is the perfect interface. If you will be modifying the set, or don't know what kind of sequence you have, then the abstract API is the right thing to use. > Further, it doesn't make sense to model this after the dictionary API where > the > next function is needed to avoid double lookups by returning pointers to both > the key and value fields at the same time (allowing for modification of the > value field). In contrast, for sets, there is no value field to look-up or > mutate (the key should not be touched). So, we shouldn't be passing around > pointers to the internal structure. I want to keep the internal structure of > sets much more private than they were for dictionaries -- all access should > be > through the provided C API functions -- that keeps the implementation > flexible > and allows for future improvements without worrying that we've broken code > for > someone who has touched the internal structure directly. The implementation of PySet_Next() would not return setentrys, it would return PyObjects. Yes, those would be borrowed refs to setentry.keys, but you still avoid direct access to internal structures. > Also, the _Next() api is not as safe as the _GetIter api which checks for > mutation during iteration. The safety should not be tossed aside without > good > reason. > > > PySet_Update() > --- > Use PyObject_CallMethod(s, "update", "O", iterable). That is the preferred > way > to access all of the high volume methods. Again, I disagree, but I don't think I need to restate my reasons. > Only the fine grain
Re: [Python-Dev] PySet API
[Barry] > Is it your intent to push for more use of the abstract API instead of > the concrete APIs for all of Python's C data structures? Current API > aside, are you advocating this approach for all new built-in types? > Would you argue that Python 3.0's C API be stripped of everything but > the abstract API and the bare essentials of the concrete API? It's not up to me. Perhaps someone else can chime-in about the philosophy of how the C API is supposed to balance abstract and concrete APIs. For concrete APIs, it does make sense to have methods for fine-grained access to containers (for the O(1) ops that tend to appear inside loops). I know that the more one uses the abstract API, the more likely the code is going to be able to accept duck typed inputs. Also, most things that have tp_slots have a corresponding abstract method instead of tons a concrete access points; hence, I would be supportive if you proposed a PyObject_Clear(o) function (for calling tp_clear slots when they exist and returning an error code when they don't). For setobject.c, if I still have a say in the matter, my strong preference is to keep the API minimal, expose fine-grained functions for efficiency, use PyNumber methods for direct access to operator style set operations, and use the abstract API for everything else. Though you have a different world view about fat vs thin APIs and on whether the C API should track the Python API, perhaps you can agree with my reasoning in this case. There is a semantic difference between code like s+=t and s.update(t). The former only works when t is a set and the latter works for any iterable. When the C code corresponds to the Python code, that knowledge is kept intact and there is no confusion between PyNumber_InPlaceAdd(s,t) vs PyObject_CallMethod(s, "update", "(O)", t). I did not want to fill-up the C API with methods corresponding to every named method in the Python API -- besides making the API unnecessarily fat, IMO, it introduces ambiguity about whether PySet_Update would be the set-only operation or the generator iteratable version. With respect to clear(), I do not not want to further enshrine that method. IMO, most uses of it are misguided and the code would be better-off allowing the existing set to be decreffed away and using PySet_New() instead. I realize that is a matter of taste, but it is a basic of API design that the module author provide clues about how the module is intended to be used. With respect to PySet_Next(), I do agree that it is both a bit faster and easier to use than the iterator API. That is more of a reflection of issues with the iterator API than it is an indication that PySet_Next() would be worthwhile. That being said, I stand by my rejection of that method. For dictionaries, the problems with the approach were some offset by the advantages of getting a simultaneous key/value lookup and by direct access to the memory where the value was stored. Sets, of course, do not have these offseting benefits. The problems with the approach however do apply to sets. I do not want to be passing around pointers to the private internal hash table -- programs have no business altering that memory directly. You have to be careful with even simple cases such as using PyString_AS_STRING which returns a pointer and then the underlying object can get decreffed away leaving a pointer to an invalid memory location (that happened to me recently but I caught it during code review). Also, there is the safety issue of having the table mutate during iteration. While your note downplayed the issue noting that the risks are fully disclosed, I speak from experience in saying that it is all too easy to accidentally allow the table to mutate during iteration -- I learned this the hard-way and had to undo a number of my uses of set_next() which had been used for speed and for being simpler than the iteator api. A single decref or call to a key's PyObject_Hash() is enough to trigger arbitrary Python code running during the middle of iteration, possibly resulting in a resize or value mutation. Take a look at the code for set_clear() to see the dance required to avoid this risk. IOW, the safety considerations alone preclude PySet_Next(). Instead, use PyObject_GetIter() and enjoy the benefits of safety, duck typing, and re-usable code. Because of the safety issues and passing internal pointers, I prefer that the _Next() api NOT get replicated throughout the language. It was needed for dicts, but shouldn't start sprouting up everywhere. All that being said, I understand that some of it comes down to taste and philosophical differences. As the module author, the existing API of course reflects my tastes and world-view. I have given you simple, one line alternatives to each proposal and listed the reasons for each choice, so it can't be argued that the API is somehow crippling your work. I'm sympathethic to your reluctance to use PyObject_CallMethod(). But, d
Re: [Python-Dev] PySet API
[Me] > There is a semantic difference between > code like s+=t and s.update(t). The former only works when t is a set > and the latter works for any iterable. When the C code corresponds to > the Python code, that knowledge is kept intact and there is no confusion > between > PyNumber_InPlaceAdd(s,t) vs PyObject_CallMethod(s, "update", "(O)", t). Of course, that should have been s|=t and PyNumber_InPlaceOr(). Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in amd64 gentoo trunk
The Buildbot has detected a new failure of amd64 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/108 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: tim.peters Build Had Warnings: warnings test sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot warnings in x86 gentoo trunk
The Buildbot has detected a new failure of x86 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/109 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: neal.norwitz Build Had Warnings: warnings test sincerely, -The Buildbot ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
