[py-svn] r36642 - py/dist/py/documentation

[hpk at codespeak.net]

Author: hpk
Date: Sat Jan 13 13:29:12 2007
New Revision: 36642

Removed:
   py/dist/py/documentation/maciej-implementation-notes.txt
Log:
after review i think that most of 
maciej's notes have been either resolved
already or are in other issues, so 
there is no need to keep it in the main
doc directory. 



Deleted: /py/dist/py/documentation/maciej-implementation-notes.txt
==============================================================================
--- /py/dist/py/documentation/maciej-implementation-notes.txt	Sat Jan 13 13:29:12 2007
+++ (empty file)
@@ -1,99 +0,0 @@
-
-Pylib roadmap, from my point of view
-====================================
-
-Author: Maciek Fijalkowski
---------------------------
-
-Date: 7.X.2006
-
-Rough specifications of what needs to be done regarding py.test
-(especially distributed version), py.api and others.
-
-So main targets (for near future) of pylib developement would be:
-
-* further py.test distributed developement, especially incorporating
-  some command line options (I think -x and -k are done). This might be:
-
-  - DONE options transfer to clients (maybe whole conftest) to allow them
-    to perform special things.
-  - -s (how???) --view for pypy, etc.
-  - screen/--pdb (there is some work done in this area)
-  - If someone (merlinux?) set up test farm (few machines connected
-    together for running tests), provide convenient interface for
-    running at least nightly tests (web one? offline html?) or even
-    just running tests for branch, trunk, custom svn without need to
-    upload local changes every time (RSync daemon?). I'm not sure if
-    it does make any sense, but makes convinient if we provide
-    front machine with access, not all the nodes (XXX and what with
-    screen?)
-  - Make sure web frontend works when more than one client (webbrowser)
-    connects to it (actually it does not).
-  - XXX: anything else?
-
-* integration from py.test distributed into normal py.test, especially
-  cool reporting features as well as web frontend (and extend it a bit)
-
-* integrate some kind of TestRunner, which will run the tests and perform
-  some additional stuff. This is related to (but not limited):
-
-  - benchmarks
-
-  - py.api integration
-
-PY.API:
--------
-
-(actually lying down in py.test.tracer in branch, maybe not
-too nice name for that, will go to py.api).
-
-So, todo list is (in random order):
-
-* Make interface for every possible single item on the end (function,
-  method, generator) to provide better coverage. Function/method DONE.
-
-* Make more... (frontend for API extraction, backend for output 
-  generation, different source link generators, etc. etc.)
-
-* Provide some model of determining which methods are exposed as API
-  and which are internal (just called directly in unittest looks like
-  enough for now, altough we do not have method of determining that yet)
-
-* Provide some command line debugger-like tool (PDB hook?) which will expose
-  API information additionally to debugging info.
-
-* Make clean vision of pypy annotation typesystem, probably even
-  extend it a bit (it's still easier to use than providing all
-  the interface on our own). Possible extensions:
-
-  - Provide SomeUnion instead of SomeObject which will behave like
-    gathering all possibilities together (this might be beneficient to
-    pypy as well).
-  - Provide some convinient way of getting common interface out of
-    objects that are contained in SomeObject. Like "what are the
-    common methods of both, even if they do not share a baseclass".
-    In this place, it should be quite easy to add different type
-    joining functions by user, because different projects might have
-    different needs at this point.
-
-* Test it on generating pylib documentation.
-
-* Make some API definition tool (object format) for defining API in
-  pypy. This will make a lot easier annotating the pypy source with
-  info (like "what the heck type comes here as an argument"....)
-
-* Add several different things to trace, mostly tracing of side effects
-  (track what method can change what attributes, as well as in child nodes.
-  Maybe global variables as well).
-
-Timeline:
----------
-
-This is quite huge wishlist.... I don't know exactly what are priorities
-on all the stuff, what I would go first is to make API tool usable and
-easy to use as soon as possible, to show it at HHU on sprint in some
-running fashion. It should be well tested and maybe not containing
-all-the-possible features, but runnable.
-
-Next thing to do is to extend py.test distributed, especially with
-screen functionality.