Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.50,1.51 pep-0207.txt,1.3,1.4
On Tue, Nov 28, 2000 at 02:13:47PM -0800, Guido van Rossum wrote:
229 is not sufficiently worked out and doesn't seem a priority. (This can still make it into 2.1 if the author does the work.)
I was waiting for further comments on the idea before actually doing the work. Anyone see gaping holes in the basic idea? (I *can* just charge ahead and work on it anyway...) --amk
On Tue, Nov 28, 2000 at 02:13:47PM -0800, Guido van Rossum wrote:
229 is not sufficiently worked out and doesn't seem a priority. (This can still make it into 2.1 if the author does the work.)
Andrew:
I was waiting for further comments on the idea before actually doing the work. Anyone see gaping holes in the basic idea? (I *can* just charge ahead and work on it anyway...)
I'd say charge ahead, but check where you are every once in a while. Some things I'm not sure about include: - Always shared libs. What about Unixish systems that don't have shared libs? What if you just want something to be hardcoded as statically linked, e.g. for security reasons? (On the other hand there are some reasons why defaulting to shared libs is a good idea -- e.g. it makes it easier to upgrade a single extension module in an installation, e.g. for a critical fix.) - Doesn't distutils currently always look for an existing installed Python installation to get its Makefile info? How to force it to use the info from the build tree? BTW off-topic: I didn't demote your PEP 222 (Web Library Enhancements) but I'm pretty neutral on this -- except that it's probably a good idea to start from scratch with a new cgi-ish module (cgi2.py?) rather than making the existing cgi.py even more complicated. (Also, it's very fragile -- you never know who uses what mis-feature.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
idea to start from scratch with a new cgi-ish module (cgi2.py?) rather
Or it could be called "cgilib"... -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
On Tue, Nov 28, 2000 at 06:01:38PM -0500, Guido van Rossum wrote:
- Always shared libs. What about Unixish systems that don't have shared libs? What if you just want something to be hardcoded as statically linked, e.g. for security reasons? (On the other hand
Beats me. I'm not even sure if the Distutils offers a way to compile a static Python binary. (GPW: well, does it?)
idea to start from scratch with a new cgi-ish module (cgi2.py?) rather than making the existing cgi.py even more complicated. (Also, it's very fragile -- you never know who uses what mis-feature.)
Indeed. My inclination is to design two new Request and Response classes; haven't done that yet, though... --amk
On 28 November 2000, Andrew Kuchling said:
On Tue, Nov 28, 2000 at 06:01:38PM -0500, Guido van Rossum wrote:
- Always shared libs. What about Unixish systems that don't have shared libs? What if you just want something to be hardcoded as statically linked, e.g. for security reasons? (On the other hand
Beats me. I'm not even sure if the Distutils offers a way to compile a static Python binary. (GPW: well, does it?)
It's in the CCompiler interface, but hasn't been exposed to the outside world. (IOW, it's mainly a question of desiging the right setup script/command line interface: the implementation should be fairly straightforward, assuming the existing CCompiler classes do the right thing for generating binary executables.) Greg
Beats me. I'm not even sure if the Distutils offers a way to compile a static Python binary. (GPW: well, does it?)
It's in the CCompiler interface, but hasn't been exposed to the outside world. (IOW, it's mainly a question of desiging the right setup script/command line interface: the implementation should be fairly straightforward, assuming the existing CCompiler classes do the right thing for generating binary executables.) Distutils currently only supports build_*** commands for C-libraries and Python extensions.
Shouldn't there also be build commands for shared libraries, executable programs and static Python binaries? Thomas BTW: Distutils-sig seems pretty dead these days...
On 01 December 2000, Thomas Heller said:
Distutils currently only supports build_*** commands for C-libraries and Python extensions.
Shouldn't there also be build commands for shared libraries, executable programs and static Python binaries?
Andrew and I talked about this a bit yesterday, and the proposed interface is as follows: python setup.py build_ext --static will compile all extensions in the current module distribution, but instead of creating a .so (.pyd) file for each one, will create a new python binary in build/bin.<plat>. Issue to be resolved: what to call the new python binary, especially when installing it (presumably we *don't* want to clobber the stock binary, but supplement it with (eg.) "foopython"). Note that there is no provision for selectively building some extensions as shared. This means that Andrew's Distutil-ization of the standard library will have to override the build_ext command and have some extra way to select extensions for shared/static. Neither of us considered this a problem.
BTW: Distutils-sig seems pretty dead these days...
Yeah, that's a combination of me playing on other things and python.net email being dead for over a week. I'll cc the sig on this and see if this interface proposal gets anyone's attention. Greg
participants (5)
-
Andrew Kuchling -
Fred L. Drake, Jr. -
Greg Ward -
Guido van Rossum -
Thomas Heller