From furnish@laura.llnl.gov Thu Jan 2 19:41:17 1997 From: furnish@laura.llnl.gov (Geoffrey Furnish) Date: Thu, 2 Jan 1997 11:41:17 -0800 Subject: [PYTHON META-SIG] New SIG Message-ID: <199701021943.OAA16102@python.org> Hello and Happy New Year to all! I would like to propose a new SIG, one for discussing improvements to Python to support writing extensions in C++. At the last Python workshop, I presented a talk in which I said (among other things), that the Python API, as seen from a C++ perspective, could be more convenient. I am starting now to write significant amounts of C++ Python extension code, so I am now ready to tackle this problem. In the (perhaps vain) hope that the results of this effort might be useful to others, I am thinking it might be useful to carry out some of the design discussions in a pseudo-public forum, and a new SIG seems ideally suited. There are several issues with writing extensions in C++ that need to be addressed. 1) Python main() should be compiled in C++. 2) The Python API should be divided into classes, according to what sorts of PyObjects they work on. In other words, instead of calling PyDict_XXX, you ought to be able to do PyDict *d; d->XXX(); 3) Error handling should use C++ exceptions instead of return values. This would free the C++ extension writer from having to check for NULL results all the time, and allow a more intentional coding style. User functions could then throw exceptions to register errors, and for that matter, the C++ized Python API functions could do the same. 4) To support 3), method invocation should be wrapped in a try block. Thus any exception thrown by code in 3), would be caught without trashing the interpretter. This will require that more things besides just main() be compiled in C++. 5) Method invocation should be made more convenient to the extension writer. Currently if you have an extension facility packaged as a C++ class, you must cobble together a bunch of global functions (the one regarded as the "methods" by the Python extension facility), which merely invoke the true (C++) methods of your extension object. It would sure be nice if that artificial level of indirection could be avoided (or, at a minimum, automated). 6) Various portions of the Python API could be made typesafe. Py_BuildValue, for instance, could be made to dispense with the format string, and could take arguments by reference, relieving the extension writer from the need to count &'s and *'s. I have already started on this project list. I have hacked up some autoconf support for compiling main with C++ if requested (user says ./configure --with-cxx). (If not so requested, Python is built just as it was before). I have also done some preliminary work on constructing a PyDict class, and have done some studying of the Python core to see how some of these other items might be accomplished. In short, my work in this area is already under way, and I hope to be able to cut some patch sets in the reasonably near term future, which could be distributed to others who wish to write Python extension modules in C++. It would seem then, that to maximize the possibility for positive effect, that it would be useful to set up a SIG for discussion of these goals and the implementations thereof. I suggest the sig be named: cxx-sig@python.org or, even (preferably, if possible) c++-sig@python.org (does anyone know if majordomo can handle list names like this yet? I set up a C++ related majordomo list a couple years back and read in the documentation to avoid special chars, I wonder if this has been rectified yet?). Anyway, assuming this sig is authorized and created, and whatever name it is given, my proposed short description would be: c++-sig: A SIG for discussing improvements to Python to support extension modules coded in C++. My proposed long description would be: ------------------------------------------------- C++-SIG, a SIG for discussing development of a C++ interface to Python This list exists in order to discuss the design and development of a C++ binding for the compiled interface to Python, and associated classes and tools for the construction of Python extension modules in C++. Major issues to be discussed/resolved, include, but are not limited to: 1) Autoconf support for enabling C++ support in Python. This must be managed in a way which does not change the C API, or the behavior of Python if not configured for C++ support, in any (observable?) way. In other words, conventional C extension modules must continue to work, whether Python is configured with C++ support or not. 2) Typesafety in the Python API. 3) Introducing C++ classes for the various major Python abstractions, such as dictionaries, lists, tuples, modules, whatever. 4) Providing semantics for these classes which are natural both to a Python affecinado, and to a C++ affecinado. For example, the PyDict class should have an operator[], and should also support STL style iterators. Many issues of this form. 5) Method invocation. How to make the invocation of C++ member functions as natural and/or painless as possible. 6) Error handling. How to irradicate NULL checking in favor of C++ style exceptions. ------------------------------------------------- I welcome any and all discussion of the merits of the creation of such a SIG, of the possible impact on the Python community, or of any other concerns that people may have. My personal view is that this is work that I will do whether it gains popular support or not, but if it can be done in a way which is genuinely useful to others, so much the better. One could hope that at some point in the indefinite future, these enhancements might wander into the official Python core distribution. I am certainly committed to providing the C++ support in a strictly add-on fashion, that is, not taking anything away from C, while adding value to C++. And finally, I am of course, willing to serve as owner of the list, if that is a necessary aspect of getting it created. BTW, if it matters, LLNL is an institutional PSA member. Cheers to all, and looking forward to your reactions, -- Geoffrey Furnish email: furnish@llnl.gov LLNL X/ICF phone: 510-424-4227 fax: 510-423-0925 ================= META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org ================= From Barry A. Warsaw" Message-ID: <199701022158.QAA02814@anthem.CNRI.Reston.Va.US> >>>>> "GF" == Geoffrey Furnish writes: GF> I would like to propose a new SIG, one for discussing GF> improvements to Python to support writing extensions in C++. Sounds good to me. You mission statement looks reasonable and your volunteering to be the list owner certainly helps! :-) GF> I suggest the sig be named: GF> cxx-sig@python.org GF> or, even (preferably, if possible) c++-sig@python.org (does GF> anyone know if majordomo can handle list names like this yet? GF> I set up a C++ related majordomo list a couple years back and GF> read in the documentation to avoid special chars, I wonder if GF> this has been rectified yet?). I'm pretty sure Majordomo can handle c++-sig@python.org. I used to run the c++-mode-victims list via Majordomo. I'll run a test to be sure though... Let's hear from others, but it sounds like there's a very well-defined mission for this sig, so I'm in favor of it. -Barry ================= META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org ================= From friedric@rose.rsoc.rockwell.com Thu Jan 2 22:49:00 1997 From: friedric@rose.rsoc.rockwell.com (Robin Friedrich) Date: Thu, 2 Jan 1997 16:49:00 -0600 Subject: [PYTHON META-SIG] New SIG Message-ID: <199701022249.QAA10364@darwin.rsoc.rockwell.com> This sig is a GOOD thing so I definately agree. Looks like everything is in order. Robin PS Barry, I still am on the hook for the text^H^H^H^Hstring sig, something soon....he says sheepishly... ================= META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org ================= From Barry A. Warsaw" Message-ID: <199701132146.QAA08402@anthem.CNRI.Reston.Va.US> Geoffrey Furnish has proposed the C++-SIG for discussion of C++ bindings to Python. I have set the sig up in `test' mode. Please read the info file and see if it's okay. Follow up here if you have any corrections. If there are no objections in the next couple of days, I'll go ahead and turn the list on. Currently, you cannot subscribe and `c++-sig@python.org' is not yet active. To get the info file send the following message to `majordomo@python.org': info c++-sig Geoffrey has volunteered to be the list owner. -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From majordomo-owner@python.org Mon Jan 13 21:44:22 1997 From: majordomo-owner@python.org (Barry A. Warsaw) Date: Mon, 13 Jan 1997 16:44:22 -0500 Subject: [PYTHON META-SIG] Re: String SIG References: <32D078C6.26F2@phoenix.net> Message-ID: <199701132144.QAA08398@anthem.CNRI.Reston.Va.US> Robin Friedrich has proposed the STRING-SIG for discussion of enhanced string processing in Python. I have set the sig up in `test' mode. Please read the info file and see if it's okay. Follow up here if you have any corrections. If there are no objections in the next couple of days, I'll go ahead and turn the list on. Currently, you cannot subscribe and `string-sig@python.org' is not yet active. To get the info file send the following message to `majordomo@python.org': info string-sig Robin, you are volunteering to be the list owner, right? -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From furnish@laura.llnl.gov Thu Jan 2 19:41:17 1997 From: furnish@laura.llnl.gov (Geoffrey Furnish) Date: Thu, 2 Jan 1997 11:41:17 -0800 Subject: [PYTHON META-SIG] New SIG Message-ID: <199701021943.OAA16102@python.org> Hello and Happy New Year to all! I would like to propose a new SIG, one for discussing improvements to Python to support writing extensions in C++. At the last Python workshop, I presented a talk in which I said (among other things), that the Python API, as seen from a C++ perspective, could be more convenient. I am starting now to write significant amounts of C++ Python extension code, so I am now ready to tackle this problem. In the (perhaps vain) hope that the results of this effort might be useful to others, I am thinking it might be useful to carry out some of the design discussions in a pseudo-public forum, and a new SIG seems ideally suited. There are several issues with writing extensions in C++ that need to be addressed. 1) Python main() should be compiled in C++. 2) The Python API should be divided into classes, according to what sorts of PyObjects they work on. In other words, instead of calling PyDict_XXX, you ought to be able to do PyDict *d; d->XXX(); 3) Error handling should use C++ exceptions instead of return values. This would free the C++ extension writer from having to check for NULL results all the time, and allow a more intentional coding style. User functions could then throw exceptions to register errors, and for that matter, the C++ized Python API functions could do the same. 4) To support 3), method invocation should be wrapped in a try block. Thus any exception thrown by code in 3), would be caught without trashing the interpretter. This will require that more things besides just main() be compiled in C++. 5) Method invocation should be made more convenient to the extension writer. Currently if you have an extension facility packaged as a C++ class, you must cobble together a bunch of global functions (the one regarded as the "methods" by the Python extension facility), which merely invoke the true (C++) methods of your extension object. It would sure be nice if that artificial level of indirection could be avoided (or, at a minimum, automated). 6) Various portions of the Python API could be made typesafe. Py_BuildValue, for instance, could be made to dispense with the format string, and could take arguments by reference, relieving the extension writer from the need to count &'s and *'s. I have already started on this project list. I have hacked up some autoconf support for compiling main with C++ if requested (user says ./configure --with-cxx). (If not so requested, Python is built just as it was before). I have also done some preliminary work on constructing a PyDict class, and have done some studying of the Python core to see how some of these other items might be accomplished. In short, my work in this area is already under way, and I hope to be able to cut some patch sets in the reasonably near term future, which could be distributed to others who wish to write Python extension modules in C++. It would seem then, that to maximize the possibility for positive effect, that it would be useful to set up a SIG for discussion of these goals and the implementations thereof. I suggest the sig be named: cxx-sig@python.org or, even (preferably, if possible) c++-sig@python.org (does anyone know if majordomo can handle list names like this yet? I set up a C++ related majordomo list a couple years back and read in the documentation to avoid special chars, I wonder if this has been rectified yet?). Anyway, assuming this sig is authorized and created, and whatever name it is given, my proposed short description would be: c++-sig: A SIG for discussing improvements to Python to support extension modules coded in C++. My proposed long description would be: ------------------------------------------------- C++-SIG, a SIG for discussing development of a C++ interface to Python This list exists in order to discuss the design and development of a C++ binding for the compiled interface to Python, and associated classes and tools for the construction of Python extension modules in C++. Major issues to be discussed/resolved, include, but are not limited to: 1) Autoconf support for enabling C++ support in Python. This must be managed in a way which does not change the C API, or the behavior of Python if not configured for C++ support, in any (observable?) way. In other words, conventional C extension modules must continue to work, whether Python is configured with C++ support or not. 2) Typesafety in the Python API. 3) Introducing C++ classes for the various major Python abstractions, such as dictionaries, lists, tuples, modules, whatever. 4) Providing semantics for these classes which are natural both to a Python affecinado, and to a C++ affecinado. For example, the PyDict class should have an operator[], and should also support STL style iterators. Many issues of this form. 5) Method invocation. How to make the invocation of C++ member functions as natural and/or painless as possible. 6) Error handling. How to irradicate NULL checking in favor of C++ style exceptions. ------------------------------------------------- I welcome any and all discussion of the merits of the creation of such a SIG, of the possible impact on the Python community, or of any other concerns that people may have. My personal view is that this is work that I will do whether it gains popular support or not, but if it can be done in a way which is genuinely useful to others, so much the better. One could hope that at some point in the indefinite future, these enhancements might wander into the official Python core distribution. I am certainly committed to providing the C++ support in a strictly add-on fashion, that is, not taking anything away from C, while adding value to C++. And finally, I am of course, willing to serve as owner of the list, if that is a necessary aspect of getting it created. BTW, if it matters, LLNL is an institutional PSA member. Cheers to all, and looking forward to your reactions, -- Geoffrey Furnish email: furnish@llnl.gov LLNL X/ICF phone: 510-424-4227 fax: 510-423-0925 ================= META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org ================= From Barry A. Warsaw" Message-ID: <199701022158.QAA02814@anthem.CNRI.Reston.Va.US> >>>>> "GF" == Geoffrey Furnish writes: GF> I would like to propose a new SIG, one for discussing GF> improvements to Python to support writing extensions in C++. Sounds good to me. You mission statement looks reasonable and your volunteering to be the list owner certainly helps! :-) GF> I suggest the sig be named: GF> cxx-sig@python.org GF> or, even (preferably, if possible) c++-sig@python.org (does GF> anyone know if majordomo can handle list names like this yet? GF> I set up a C++ related majordomo list a couple years back and GF> read in the documentation to avoid special chars, I wonder if GF> this has been rectified yet?). I'm pretty sure Majordomo can handle c++-sig@python.org. I used to run the c++-mode-victims list via Majordomo. I'll run a test to be sure though... Let's hear from others, but it sounds like there's a very well-defined mission for this sig, so I'm in favor of it. -Barry ================= META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org ================= From friedric@rose.rsoc.rockwell.com Thu Jan 2 22:49:00 1997 From: friedric@rose.rsoc.rockwell.com (Robin Friedrich) Date: Thu, 2 Jan 1997 16:49:00 -0600 Subject: [PYTHON META-SIG] New SIG Message-ID: <199701022249.QAA10364@darwin.rsoc.rockwell.com> This sig is a GOOD thing so I definately agree. Looks like everything is in order. Robin PS Barry, I still am on the hook for the text^H^H^H^Hstring sig, something soon....he says sheepishly... ================= META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org ================= From Barry A. Warsaw" Message-ID: <199701132146.QAA08402@anthem.CNRI.Reston.Va.US> Geoffrey Furnish has proposed the C++-SIG for discussion of C++ bindings to Python. I have set the sig up in `test' mode. Please read the info file and see if it's okay. Follow up here if you have any corrections. If there are no objections in the next couple of days, I'll go ahead and turn the list on. Currently, you cannot subscribe and `c++-sig@python.org' is not yet active. To get the info file send the following message to `majordomo@python.org': info c++-sig Geoffrey has volunteered to be the list owner. -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From majordomo-owner@python.org Mon Jan 13 21:44:22 1997 From: majordomo-owner@python.org (Barry A. Warsaw) Date: Mon, 13 Jan 1997 16:44:22 -0500 Subject: [PYTHON META-SIG] Re: String SIG References: <32D078C6.26F2@phoenix.net> Message-ID: <199701132144.QAA08398@anthem.CNRI.Reston.Va.US> Robin Friedrich has proposed the STRING-SIG for discussion of enhanced string processing in Python. I have set the sig up in `test' mode. Please read the info file and see if it's okay. Follow up here if you have any corrections. If there are no objections in the next couple of days, I'll go ahead and turn the list on. Currently, you cannot subscribe and `string-sig@python.org' is not yet active. To get the info file send the following message to `majordomo@python.org': info string-sig Robin, you are volunteering to be the list owner, right? -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________