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

hpk at codespeak.net hpk at codespeak.net
Sun Oct 17 23:50:47 CEST 2004 

Author: hpk
Date: Sun Oct 17 23:50:47 2004
New Revision: 6988

Modified:
   py/dist/doc/   (props changed)
   py/dist/doc/future.txt
   py/dist/doc/test.txt
   py/dist/doc/why_py.txt
Log:
little fixes here and there. 



Modified: py/dist/doc/future.txt
==============================================================================
--- py/dist/doc/future.txt	(original)
+++ py/dist/doc/future.txt	Sun Oct 17 23:50:47 2004
@@ -5,25 +5,26 @@
 .. contents::
 .. sectnum::
 
-This document tries to make transparent ideas regarding future
-development of the py lib.  *Note that all statements within this
-document - even if they sound factual - just express 
-thoughts and not always real code so read with some caution. 
-This is not a reference guide (tm).* 
+This document tries to describe directions and guiding ideas
+for the near-future development of the py lib.  *Note that all
+statements within this document - even if they sound factual -
+may just express thoughts. They not always refer to real code
+so read with some caution.  This is not a reference guide
+(tm).* 
 
 .. _`a more general view on path objects`:
 
-Direction: A more general view on ``py.path`` objects 
-=====================================================
+A more general view on ``py.path`` objects 
+==========================================
 
-Seen from a more general persective, the current ``fspy`` path 
+Seen from a more general persective, the current ``py.path.fspy`` path 
 offers a way to go from a file to the structured content of 
-a file, namely a python object.  This path retains some
-common "path" operations and semantics but also offers additional
+a file, namely a python object.  The ``fspy`` path retains some
+common ``path`` operations and semantics but offers additional
 methods, e.g. ``resolve()`` gets you a true python object.   
 
 But apart from python files there are many other examples 
-of structured content like xml documents or Ini-style 
+of structured content like xml documents or INI-style 
 config files.  While some tasks will only be possible 
 to perform in a domain specific manner (e.g. applying xslt 
 etc.pp) ``py.path`` offers a common behaviour for 
@@ -52,7 +53,7 @@
 content of the file as values. 
 
 But it also works (today!) for ``fspy`` paths if you put the following
-python code in the file, referenced as ``startpath`` above::
+python code in a file:: 
 
     class Section1:
         someoption = "i am an option value" 

Modified: py/dist/doc/test.txt
==============================================================================
--- py/dist/doc/test.txt	(original)
+++ py/dist/doc/test.txt	Sun Oct 17 23:50:47 2004
@@ -6,7 +6,7 @@
 .. sectnum::
 
 *PLEASE NOTICE*: 
-    Warning: a few names like ``Driver`` and ``Item`` used in this document 
+    a few names like ``Driver`` and ``Item`` used in this document 
     mostly represent a future naming, they are currently called differently, 
     ``Runner`` and ``Unit`` respectively.  The latter names are causing 
     confusion with the ``unittest.py``  nomen clatura. ``py.test`` 
@@ -24,21 +24,18 @@
 statement. 
 
 The existence of a standalone ``py.test`` tool allows 
-to write tests without any boilerplate: 
+to write tests without any boilerplate::
 
     def test_answer():
         assert 42 == 43 
 
 this would be the complete content of a ``test_sample.py``
-test script and you can simply execute the tests by invoking: 
+test script and you can execute the tests by invoking::
 
     py.test test_sample.py 
 
-For seeing various options you can use:
-
-    py.test -h 
-
-to see the list of options. 
+See `getting started`_ for how to install the 'py.test' script
+on your system. 
 
 
 Basic features for writing tests
@@ -349,3 +346,5 @@
 - lift some of the arbitrary restrictions of unittest.py: 
   allow plain test functions (without being in a class) and 
   allow classes to simply mean "grouping" of tests. 
+
+.. _`getting started`: getting_started

Modified: py/dist/doc/why_py.txt
==============================================================================
--- py/dist/doc/why_py.txt	(original)
+++ py/dist/doc/why_py.txt	Sun Oct 17 23:50:47 2004
@@ -20,17 +20,17 @@
 
 - due to python's default *export all names* policy for modules
   and packages it is hard to refactor code across 
-  releases becaue you might break uses of your code 
+  releases because you might break usages of your code 
 
-- the python "batteries included" are tied to the python 
-  release process.  You can't easily benefit from new python 
-  module in older python versions which you might have 
-  to use for whatever reason. 
+- the python "batteries included" standard modules are tied to 
+  the python release process.  You can't easily benefit from 
+  new python module in older python versions which you might 
+  have to use for whatever reason. 
 
-- support for interaction with command line utilities 
-  or e.g. pygame-based shells is missing. 
+- support for richer interactive interaction with command line 
+  utilities or e.g. pygame-based shells is missing. 
 
-- often modules/packages are implemented in java-style 
+- modules/packages are often implemented in javaesque -style 
 
 - distributed applications are implemented using 
   a variant of Remote Method Invocation (RMI) which carries 
@@ -40,16 +40,17 @@
 - there is no _automated_ way of installing, maintaining 
   and upgrading applications 
 
-The py lib tries to address these problems.  Of course, we
+The py lib tries to address these problems.  It is thus in
+risk of trying to do too many things at once.  Of course, we
 can't solve them all at once but you will find that the above
 points currently drive the development of the py lib. The py
 lib wants to support a *decent and well supported development
 process* addressing important deployment, versioning, testing and
-documentation issues - seen from the perspective of a 
+documentation issues - seen primarily from the perspective of a 
 FOSS developer. 
 
-What is your current focus? 
-=========================== 
+What is the py libs current focus? 
+==================================
 
 Currently, the main focus of the py lib is to get a decent
 `test environment`_.  Automated tests fit very well to the
@@ -133,23 +134,23 @@
 and Holger Krekel, after which Holger continued on an
 iteration of the py.test tool (known first as 'utest', then as
 'std.utest', now 'py.test'). Helpful discussions took place
-with Martijn Faassen, and then Armin Rigo who contributed
-important parts.  He and Holger came up with a couple of
-iterations of the testing-code that reduced the API to almost
-nothing: just the assert statement and an assert_raises
-method. 
+with Martijn Faassen, Stephan Schwarzer and then Armin Rigo who 
+contributed important parts.  He and Holger came up with a
+couple of iterations of the testing-code that reduced the API
+to almost nothing: just the assert statement and an
+assert_raises method. 
 
 Now recently, after Holgers `talk at EP2004`_ more people
-were interested and there were some discussions with Jim Fulton 
-and Marius Gedminas and more recently, Ian Bicking.  However, 
-there is no real core development team as such. Also we
-are somewhat lacking in the win32 area. Every now and
-then the py lib is tested on windows but it's currently 
-not a continous concern of one of the current developers or 
+were interested and there were some discussions with Jim Fulton, 
+Marius Gedminas, Laura Creighton and more recently, Ian Bicking.  
+However, there is no real core development team as such. Also
+we are somewhat lacking in the win32 area. Every now and then
+the py lib is tested on windows but it's currently not a
+continous concern of one of the current developers or
 contributors.  
 
-However, one of the improvements to the testing code is to 
-allow running tests across multiple python versions and 
+However, one of the future directions of the `py.test tool and library`_ 
+is to allow running tests across multiple python versions and 
 computers.  Then we can run tests without having to walk 
 up or boot up a windows machine :-) 
 
@@ -161,3 +162,4 @@
 .. _`PyPy`: http://codespeak.net/pypy
 .. _`envisioned import/export system`: future.html#importexport
 .. _future: future.html
+.. _`py.test tool and library`: test

More information about the pytest-commit mailing list