[py-svn] r7056 - py/dist/doc

[hpk at codespeak.net]

Author: hpk
Date: Wed Oct 20 03:38:46 2004
New Revision: 7056

Modified:
   py/dist/doc/future.txt
   py/dist/doc/misc.txt
Log:
- future: added a new section about transparent compilation 

- fixes to misc



Modified: py/dist/doc/future.txt
==============================================================================
--- py/dist/doc/future.txt	(original)
+++ py/dist/doc/future.txt	Wed Oct 20 03:38:46 2004
@@ -372,6 +372,56 @@
 more experimentations and a comparison with xist_ i guess. 
 
 
+.. _`compile-on-the-fly`: 
+
+Crossing the barriers of compilation 
+====================================
+
+Python developers are very used to the fact
+that compilation of python programs happens 
+automatically.  This is unlike Java and C where
+you need an explicit compilation step. 
+With Python, the language does it for you. 
+With the py lib we extend the **compile-on-the-fly** 
+notion for other program source than Python.  
+Well, we start with C-files files but want to make sure 
+that the mechanism is extensible towards other languages. 
+
+And of course, internally we just reuse `CPython's distutils`_
+which already provides the right abstractions to run the
+underlying system compiler. 
+
+development convenience rules
+-----------------------------
+
+As described in the `getting started`_ chapter the main 
+current method to utilize the py lib is to work from a 
+subversion checkout.  The **compile-on-the-fly** feature
+allows us to keep up with this work style.  You don't have to 
+issue any manual ``python setup.py install`` incantations 
+and you don't have to remember dependency issues. You
+can easily add a small C-coded module and make it 
+seemlessly available through the path object::
+
+    mod = somepath.getcompiled() 
+
+And you can grab objects from the freshly 
+compiled C-module. 
+
+we need a persistent storage for the py lib 
+-------------------------------------------
+
+A somewhat open question is where to store the underlying
+generated object and library files from `CPython's
+distutils`_.  We probably want to have the possibility of a
+*persistent location* in order to avoid runtime-penalties. A
+*persistent location* for the py lib would be a good idea
+anyway. We could cache some of the expensive test setups, like
+the multi-revision subversion repository that is created for
+each run of the tests. 
+
+.. _`CPython's distutils`: http://www.python.org/dev/doc/devel/lib/module-distutils.html
+
 Extending rest-tests to check links 
 ===================================
 

Modified: py/dist/doc/misc.txt
==============================================================================
--- py/dist/doc/misc.txt	(original)
+++ py/dist/doc/misc.txt	Wed Oct 20 03:38:46 2004
@@ -88,7 +88,7 @@
 Currently, the py lib offers two ways to interact with
 system executables. ``py.process.cmdexec()`` invokes
 the shell in order to execute a string.  The other
-one lets you directly execute a binary (XXX not implemented).
+one, ``localpath.sysexec()`` lets you directly execute a binary. 
 
 Both approaches will raise an exception in case of a return-
 code other than 0 and otherwise return the stdout-output 
@@ -110,7 +110,6 @@
 - it only allows to execute executables from the local 
   filesystem 
 
-
 .. _sysexec: 
 
 local paths have ``sysexec``
@@ -118,8 +117,7 @@
 
 The py lib currently offers a stripped down functionality of what
 the new `PEP-324 subprocess module`_ offers.  The main functionality 
-of synchronously executing a system executable has a
-straightforward api:: 
+of synchronously executing a system executable has a straightforward API:: 
 
     binsvn.sysexec('ls', 'http://codespeak.net/svn') 
 
@@ -130,8 +128,14 @@
 
 For a first go, we are just reusing the existing `subprocess
 implementation`_ but don't expose any of its API apart
-from the above "execute()" method. 
+from the above ``sysexec()`` method. 
+
+Note, however, that we currently don't support the ``sysexec`` 
+interface on win32.  We want to integrate our `compile-on-the-fly`_
+and use the ``_subprocess.c`` file from the `PEP-324 subprocess module`_. 
+
 
+.. _`compile-on-the-fly`: future.html#compile-on-the-fly 
 .. _`future book`: future.html 
 .. _`PEP-324 subprocess module`: http://www.python.org/peps/pep-0324.html
 .. _`subprocess implementation`: http://www.lysator.liu.se/~astrand/popen5/