[py-svn] r7014 - in py/dist: doc py py/misc

[hpk at codespeak.net]

Author: hpk
Date: Mon Oct 18 23:52:42 2004
New Revision: 7014

Added:
   py/dist/doc/misc.txt
   py/dist/py/misc/std.py
   py/dist/py/misc/test_std.py
Modified:
   py/dist/doc/   (props changed)
   py/dist/doc/future.txt
   py/dist/doc/index.txt
   py/dist/py/__init__.py
   py/dist/py/pytest.py
Log:
the future is becoming experimentally present :-) 
may i present the py.std hook? 

    http://codespeak.net/py/current/doc/misc.html



Modified: py/dist/doc/future.txt
==============================================================================
--- py/dist/doc/future.txt	(original)
+++ py/dist/doc/future.txt	Mon Oct 18 23:52:42 2004
@@ -441,46 +441,7 @@
 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

Modified: py/dist/doc/index.txt
==============================================================================
--- py/dist/doc/index.txt	(original)
+++ py/dist/doc/index.txt	Mon Oct 18 23:52:42 2004
@@ -4,11 +4,14 @@
 Here is some documentation about main areas within 
 *the py lib*: 
 
+
    `py.test`_ describes features of the py.test utility
 
    `py.execnet`_ offers an innovative way to distribute programs across the net 
-   
-   `why_py`_ describes a bit of the motivation and background 
+
+   `miscellaneous features`_ describes some more py lib features 
+
+   `why py?`_ describes a bit of the motivation and background 
 
    `future`_ handles development visions and plans for the near future. 
   
@@ -21,7 +24,8 @@
 
 .. _`py.execnet`: execnet.html 
 .. _`py.test`: test.html 
-.. _`why_py`: why_py.html 
+.. _`why py?`: why_py.html 
 .. _`future`: future.html 
 .. _`getting started`: getting_started.html 
+.. _`miscellaneous features`: misc.html 
 

Added: py/dist/doc/misc.txt
==============================================================================
--- (empty file)
+++ py/dist/doc/misc.txt	Mon Oct 18 23:52:42 2004
@@ -0,0 +1,83 @@
+====================================
+Miscellaneous features of the py lib 
+====================================
+
+.. contents::
+.. sectnum::
+
+Mapping the standard python library into py 
+===========================================
+
+    Warning: This feature is very young and thus experimental.
+    Be prepared to adapt your code later if you use it. 
+
+After you have worked with the py lib a bit, you might enjoy
+the lazy importing, i.e. you only have to do ``import py`` and
+work your way to your desired object.  Using the full path 
+also ensures that there remains a focus on getting short paths 
+to objects. 
+
+The ``py.std`` hook
+------------------- 
+
+Of course, no matter what, everybody will continue to use the
+python standard library because it is a very usable code base.
+However, to properly support lazyness the py lib offers a way
+to get to many standard modules without requiring "import"
+statements.  For example, to get to the print-exception
+functionality of the standard library you can write:: 
+
+    py.std.traceback.print_exc() 
+
+without having to do anything else than the usual ``import py`` 
+at the beginning.  Note that not having imports for the 
+`python standard library` obviously gets rid of the *unused 
+import* problem. Modules only get imported when you actually
+need them. 
+
+Moreover, this approach resolves some of the issues stated in
+`the relative/absolute import PEP-328`_, as with the above
+approach you never have ambiguity problems.  The above
+traceback-usage is an absolute path that will not be
+accidentally get confused with local names.  (Well, never put
+a file ``py.py`` in an importable path, btw, mind you :-) 
+
+Automagically accessing sub packages doesn't work (yet?) 
+--------------------------------------------------------
+
+If you use the ``py.std`` hook you currently cannot magically
+import nested packages which otherwise need explicit imports of
+their sub-packages.  For example, the suversion bindings
+require you to do something like:: 
+
+    import svn.client 
+
+If you just do the naive thing with the py lib, i.e. write
+``py.std.svn.client`` it will not work unless you previously
+imported it already.  The py lib currently doesn't try to
+magically make this work.  The ``py.std`` hook really is
+intended for Python standard modules which very seldomly (if
+at all) provide such nested packages. 
+
+**Note that you may never rely** on module identity, i.e. 
+that ``X is py.std.X`` for any ``X``. This is to allow
+us later to lazyly import nested packages. Yes, lazyness
+is hard to resist :-) 
+
+Note: you get an AttributeError, not an ImportError
+---------------------------------------------------
+
+If you say ``py.std.XYZ`` and importing ``XYZ`` produces an
+``ImportError`` , it will actually show up as an
+``AttributeError``. It is deemed more important to adhere to
+the standard ``__getattr__`` protocol than to let the
+``ImportError`` pass through.  For example, you might want to
+do::
+
+    getattr(py.std.cStringIO, 'StringIO', py.std.StringIO.StringIO) 
+
+and you would expect that it works. It does work although it will 
+take away some lazyness because ``py.std.StringIO.StringIO`` will
+be imported in any case. 
+
+.. _`the relative/absolute import PEP-328`: http://www.python.org/peps/pep-0328.html

Modified: py/dist/py/__init__.py
==============================================================================
--- py/dist/py/__init__.py	(original)
+++ py/dist/py/__init__.py	Mon Oct 18 23:52:42 2004
@@ -1,5 +1,6 @@
 from initpkg import initpkg 
 initpkg(__name__, exportdefs = {
+    'std':                './misc/std.std', 
     'path.local':         './path/local/local.LocalPath',
     'path.checker':       './path/common.checker', 
     'path.svnurl':        './path/svn/urlcommand.SvnCommandPath',

Added: py/dist/py/misc/std.py
==============================================================================
--- (empty file)
+++ py/dist/py/misc/std.py	Mon Oct 18 23:52:42 2004
@@ -0,0 +1,15 @@
+
+import sys
+
+class Std(object):
+    def __init__(self):
+        self.__dict__ = sys.modules 
+
+    def __getattr__(self, name):
+        try:
+            m = __import__(name)
+        except ImportError: 
+            raise AttributeError("py.std: could not import %s" % name) 
+        return m 
+
+std = Std() 

Added: py/dist/py/misc/test_std.py
==============================================================================
--- (empty file)
+++ py/dist/py/misc/test_std.py	Mon Oct 18 23:52:42 2004
@@ -0,0 +1,13 @@
+
+import py
+
+def test_os():
+    import os
+    assert py.std.os is os 
+
+def test_import_error_converts_to_attributeerror():
+    py.test.raises(AttributeError, "py.std.xyzalskdj")
+
+def test_std_gets_it():
+    for x in py.std.sys.modules:
+        assert x in py.std.__dict__ 

Modified: py/dist/py/pytest.py
==============================================================================
--- py/dist/py/pytest.py	(original)
+++ py/dist/py/pytest.py	Mon Oct 18 23:52:42 2004
@@ -1,13 +1,11 @@
 #pythonexecutables = ('python2.2', 'python2.3',) 
 #pythonexecutable = 'python2.2' 
 
-def setup_module(extpy):
-    mod = extpy.resolve() 
-    mod.module = 23
-    directory = pypath.root.dirpath()
-    
-    
-    
+# in the future we want to be able to say here: 
+#def setup_module(extpy):
+#    mod = extpy.resolve() 
+#    mod.module = 23
+#    directory = pypath.root.dirpath()
     
 # standard options (modified from cmdline) 
 verbose = 0