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

[hpk at codespeak.net]

Author: hpk
Date: Mon Oct 18 14:07:49 2004
New Revision: 7007

Modified:
   py/dist/doc/future.txt
Log:
added a new future chapter about mapping
the standard python library into the 'py' namespace ... 



Modified: py/dist/doc/future.txt
==============================================================================
--- py/dist/doc/future.txt	(original)
+++ py/dist/doc/future.txt	Mon Oct 18 14:07:49 2004
@@ -383,13 +383,13 @@
 Generating xml/html 
 ===================
 
-The py-doc strives to offer enough functionality to represent
+The py lib strives to offer enough functionality to represent
 itself and especially its API in html or xml.  Moreover,
 `py.test`_ wants to run distributedly in order to execute
 tests on different processes and platforms. It will need to
 exchange data between its running program fragments.  
 
-For example, test ``Results`` could be represented in lightweight 
+For example, test ``results`` could be represented in lightweight 
 xml or we could export the whole result of the testing process
 as xml, anyway, to allow other tools to post-process the output. 
 The starting point for this, btw, is the `Reporter`_ from the
@@ -432,13 +432,56 @@
 
    print unicode(doc).encode('latin1')
 
-This would give you a latin1 representation of the obvious document. 
+This would print a latin1 representation of the obvious document. 
 I think the beauty of this is apparent and beats string-concantentation
-or DOM-manipulations big time.  For now, i don't think we should
-strive to offer much more than the above.  Well, of course, we would
-like to access a sane object model for the generated html but this
-needs some more experimentations and a comparison with xist_ i guess. 
+or DOM-manipulations big time.  
 
+For now, i don't think we should strive to offer much more
+than the above.  Well, of course, we would like to access a
+sane object model for the generated html but this needs some
+more experimentations and a comparison with xist_ i guess. 
+
+mapping the standard python library into py?
+============================================
+
+After you have worked with the py lib a bit, you might enjoy
+the lazy importing, i.e. you only have to ``import py`` and
+work your way to your desired object.  This way of using it
+also ensures that we will focus on getting short paths to
+objects and (because of the import/export system we can) avoid
+uglyness like ''ConfigParser.ConfigParser`` alltogether. 
+
+convenience, lazyness, oh the joy!
+----------------------------------
+
+Now it would be rather convenient to be able to say:: 
+
+    py.std.traceback.print_exc() 
+
+without having to import anything else than 'py' at 
+the beginning.  Not having imports for the `python 
+standard library`  would obviously get rid of the
+unused import problem :-) 
+
+Moreover, this would resolve some of the issues 
+stated in `the relative/absolute import PEP-328`_, 
+as with the above approach you never have ambiguity 
+problems.  The above is obviously a pretty absolute 
+path that will not be confused with local names. 
+(Well, never put a file ``py.py`` in an importable 
+path, mind you :-) 
+
+Backporting new python modules? 
+-------------------------------
+
+We may also think about backporting some 2.3 and 2.4 
+modules to have them generally available.  Maybe it
+is not really worth it. At least we don't need to
+think about it before the first step of making
+the plain system libraries available. 
+
+.. _`the relative/absolute import PEP-328`: http://www.python.org/peps/pep-0328.html
+.. _`python standard library`: http://www.python.org/doc/2.3.4/lib/lib.html
 .. _`xpython EuroPython 2004 talk`: http://codespeak.net/svn/user/hpk/talks/xpython-talk.txt
 .. _`under the xpy tree`: http://codespeak.net/svn/user/hpk/xpy/xml.py
 .. _`future book`: future.html