docstring-develop Mailing List for Docstring Processing System (Page 3)
Status: Pre-Alpha
Brought to you by:
goodger
Menu
▾
▴
docstring-develop — Project development discussions.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
(27) |
Sep
(23) |
Oct
(4) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tony J I. (Tibs) <to...@ls...> - 2001-08-16 13:18:57
|
[recipients pruned - I've removed Python-Dev - will they care?] I've had a *little* time to play with ast-mining.py, but won't have any more today. Whilst I'm not sure if this is of direct interest to anyone else, I'm providing an update on the "release early, release often" principle. I've uploaded two files: http://www.tibsnjoan.co.uk/reST/ast-mining.py http://www.tibsnjoan.co.uk/reST/test.py The former now has a different command line interface (huh - sounds posher than it is) - basically it can do what it did before, but it can also "pretty print" the AST, or find candidates for assignments followed by docstrings (DPS proposes to support these). It doesn't yet check the candidates! The latter is a simple test Python file suitable for input. My intention is to provide a well commented example of a visitor, and some simple tools for learning about ASTs. This is obviously of interest to me, and I'm fairly sure addresses some of Neal's needs - is it also useful to you, Jeremy? The example visitor should then be directly usable by DPS, which is why I'm faffing around with assignment docstrings (it will also make the example a bit more interesting). Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
|
From: Tony J I. (Tibs) <to...@ls...> - 2001-08-15 15:31:43
|
Hmm. Is everyone on that list of recipients really interested? Anyway, I've spent a happy time (when I should have been earning money - oh well) expanding Jeremy's example, ast-mining.py, to do more things. I've done all of the easy stuff first (makes sense to me). Anyway, it now reports on a lot more stuff, and is probably already useful enough to be "plugged in" to initial DPS/reST usages. Rather than make this message even longer, I've put it at: http://www.tibsnjoan.co.uk/reST/ast-mining.py I've been testing it by running it on itself. Comments, as ever, welcome. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "How fleeting are all human passions compared with the massive continuity of ducks." - Dorothy L. Sayers, "Gaudy Night" My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
|
From: Tony J I. (Tibs) <to...@ls...> - 2001-08-15 12:57:30
|
Jeremy Hylton wrote: > I'd like to avoid producing many different versions > for intermediate drafts. Makes sense. > Might you be able to grab the Python source tree and try it out: I had a quick look earlier - our TeX setup doesn't seem to *quite* agree with what's there. So in the end, given the documentation is (in fact) not too long I've just printed the pages. Hmm - might I suggest that so far as random users are concerned, one long page in HTML may be more useful than the individual pages, for external consumption? Anyway, I'm currently in the midst (as time allows) of expanding your original short example into a longer example that extracts more stuff - fun. I'll post it (or put it up somewhere and say so) later on, I hope. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
|
From: Jeremy H. <je...@zo...> - 2001-08-15 12:05:08
|
>>>>> "TJI" == Tibs <Tony> writes: TJI> Jeremy Hylton wrote: >> A first and quite incomplete draft of docs for the compiler >> package has been checked in Tools/compiler/doc. The HTML version >> is currently available from >> http://www.python.org/~jeremy/compiler/ TJI> Great Stuff, but... TJI> Is there any chance of a "flat" version of this? - I would like TJI> something I could print out, and these hierarchical TJI> organisations can be a right pain. Fred's excellent documentation tools can be used to produce pdf, ps, html, etc. from the tex source. I'd like to avoid producing many different versions for intermediate drafts. Might you be able to grab the Python source tree and try it out: run Doc/tools/mkhowto on Tools/compiler/doc/compiler.tex. I'll produce all the various formats when I have a solid draft. Jeremy |
|
From: Tony J I. (Tibs) <to...@ls...> - 2001-08-15 09:15:17
|
Jeremy Hylton wrote: > A first and quite incomplete draft of docs for the compiler package > has been checked in Tools/compiler/doc. The HTML version is currently > available from > http://www.python.org/~jeremy/compiler/ Great Stuff, but... Is there any chance of a "flat" version of this? - I would like something I could print out, and these hierarchical organisations can be a right pain. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
|
From: David G. <dgo...@bi...> - 2001-08-15 01:47:33
|
Neal Norwitz <ne...@me...> wrote on 2001-08-14 11:13: > Would you also want default parameter values? Yes. > PyChecker needs all of that, plus additional info. So there is a lot > of overlap. I think the DPS will use a small subset of what PyChecker needs. The only extra information the DPS may need is attribute and additional docstrings, string literals in certain contexts that are not currently recognized as docstrings (see PEP 258). > Pooling efforts would be good. I also don't know anything about > the ASTs/compiler, but am willing to work on it. I look forward to it, and to reading Jeremy's docs. (Go, doc writer!) -- David Goodger dgo...@bi... Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net |
|
From: Jeremy H. <je...@zo...> - 2001-08-14 22:42:56
|
A first and quite incomplete draft of docs for the compiler package
has been checked in Tools/compiler/doc. The HTML version is currently
available from
http://www.python.org/~jeremy/compiler/
Jeremy
|
|
From: Fred L. D. Jr. <fd...@ac...> - 2001-08-14 16:31:38
|
Jeremy Hylton writes: > I'm on the hook for AST/compiler documentation, which I plan to work > on this week. I will probably have more time for it later in the week > than I will today or tomorrow. So between standing over your shoulder to make sure this gets done, and watching over Barry's shoulder to make sure the smtpd module gets documented, I'm going to get a fair bit of exercise this week... well, I guess some people would consider that a good thing. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
|
From: Tony J I. (Tibs) <to...@ls...> - 2001-08-14 15:56:37
|
Jeremy Hylton wrote: > I wouldn't wait for people to argue about the right AST either. Use > the one Greg and Bill came up with for p2c. It's in Tools/compiler in > the Python distribution. It's much simpler than the parse tree > produced by the parser module. And, as far as I know, no one is > advocating a different AST. Indeed, it was the one I used for my stpy.py "testbed" earlier this year (this had code that trivially found docstrings for a module and its classes and functions/methods, and presented them (albeit not very prettily) in HTML as such. The code to use compiler was *very* simple, at this level. It even works under 1.5.2 (with, I think, two lines commented out). As I remember, it wasn't terribly fast, but who cares... It also lacked documentation, but that just means some more staring at code (and maybe the parser documentation) to work out what to expect. > It doesn't have a query language, but neither does tokenize.py <wink>. Hmm - for the purposes we're after, any "query" is purely theoretical, I think (i.e., in the sense that *everything* done on a datastructure might be considered a query). At least for the moment. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "How fleeting are all human passions compared with the massive continuity of ducks." - Dorothy L. Sayers, "Gaudy Night" My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
|
From: Jeremy H. <je...@zo...> - 2001-08-14 15:50:53
|
>>>>> "NN" == Neal Norwitz <ne...@me...> writes:
>> I'd be very interested in pooling efforts to make this easier. I
>> know almost nothing about ASTs now, but that could change in a
>> hurry :-).
NN> Pooling efforts would be good. I also don't know anything about
NN> the ASTs/compiler, but am willing to work on it.
I'm on the hook for AST/compiler documentation, which I plan to work
on this week. I will probably have more time for it later in the week
than I will today or tomorrow.
In the absence of documentation, here's a trivial example program that
extracts some information about methods and attributes from a class
and its methods. I wasn't exhaustive here. I'll get attributes
assigned to by "self.x" in a method body and I'll get method
definitions in the class body. I don't deal with obvious things like
attributes defined at the class level.
Jeremy
from compiler import parseFile, walk, ast
class Class:
def __init__(self, name, bases):
self.name = name
self.bases = bases
self.methods = {}
self.attributes = {}
def addMethod(self, meth):
self.methods[meth.name] = meth
def addInstanceAttr(self, name):
self.attributes[name] = name
def getMethodNames(self):
return self.methods.keys()
def getAttrNames(self):
return self.attributes.keys()
class Method:
def __init__(self, name, args, defaults):
self.name = name
self.args = args
self.defaults = defaults
def getSelf(self):
return self.args[0]
class ClassExtractor:
classes = []
def visitClass(self, node, klass=None, meth=None):
c = Class(node.name, node.bases)
self.visit(node.code, c)
self.classes.append(c)
def visitFunction(self, node, klass=None, meth=None):
if klass is not None and meth is None:
m = Method(node.name, node.argnames, node.defaults)
klass.addMethod(m)
self.visit(node.code, klass, m)
else:
self.visit(node.code)
def visitAssAttr(self, node, klass=None, meth=None):
if isinstance(node.expr, ast.Name) and meth is not None:
if node.expr.name == meth.getSelf():
klass.addInstanceAttr(node.attrname)
else:
self.visit(node.expr)
def main(py_files):
extractor = ClassExtractor()
for py in py_files:
ast = parseFile(py)
walk(ast, extractor)
for klass in extractor.classes:
print klass.name
print klass.getMethodNames()
print klass.getAttrNames()
print
if __name__ == "__main__":
import sys
main(sys.argv[1:])
|
|
From: Jeremy H. <je...@zo...> - 2001-08-14 15:29:14
|
>>>>> "TP" == Tim Peters <ti...@ho...> writes: TP> Let me suggest you don't really want an AST -- you want an TP> object model for Python source that answers the questions above TP> directly. Agreed. TP> directly. An AST may be an effective (under the covers) TP> implementation technique to get such info, but if you don't want TP> to wait for people to argue about "the right" AST and "the TP> right" tree-based query language to make it better than TP> completely useless <wink>, you can answer all the stuff above by TP> building on tokenize.py now. I wouldn't wait for people to argue about the right AST either. Use the one Greg and Bill came up with for p2c. It's in Tools/compiler in the Python distribution. It's much simpler than the parse tree produced by the parser module. And, as far as I know, no one is advocating a different AST. It doesn't have a query language, but neither does tokenize.py <wink>. Jeremy |
|
From: Neal N. <ne...@me...> - 2001-08-14 15:15:43
|
David Goodger wrote: > > >From the PyChecker AST discussion, it seems we may have a common goal. For It seems that way. > the Docstring Processing System, I am looking into gleaning information from > the abstract syntax tree. From the working notes, under "Docstring > Extractor": > > We need code that scans a parsed Python module, and returns an > ordered tree containing the names, docstrings (including > additional docstrings), and additional info (in parentheses below) > of all of the following objects: > - methods (+ formal parameters) > - functions (+ formal parameters) Would you also want default parameter values? PyChecker needs all of that, plus additional info. So there is a lot of overlap. > I'd be very interested in pooling efforts to make this easier. I know almost > nothing about ASTs now, but that could change in a hurry :-). Pooling efforts would be good. I also don't know anything about the ASTs/compiler, but am willing to work on it. Neal |
|
From: David G. <dgo...@bi...> - 2001-08-14 04:43:08
|
From the PyChecker AST discussion, it seems we may have a common goal. For
the Docstring Processing System, I am looking into gleaning information from
the abstract syntax tree. From the working notes, under "Docstring
Extractor":
We need code that scans a parsed Python module, and returns an
ordered tree containing the names, docstrings (including
additional docstrings), and additional info (in parentheses below)
of all of the following objects:
- packages
- modules
- module attributes (+ values)
- classes (+ inheritance)
- class attributes (+ values)
- instance attributes (+ values)
- methods (+ formal parameters)
- functions (+ formal parameters)
In order to evaluate interpreted text cross-references, namespaces
for each of the above will also be required.
I'd be very interested in pooling efforts to make this easier. I know almost
nothing about ASTs now, but that could change in a hurry :-).
--
David Goodger dgo...@bi... Open-source projects:
- Python Docstring Processing System: http://docstring.sourceforge.net
- reStructuredText: http://structuredtext.sourceforge.net
- The Go Tools Project: http://gotools.sourceforge.net
|
|
From: Garth T K. <ga...@de...> - 2001-08-10 02:09:04
|
> What is the situation with HTML output Kinda stalled. I was going to write an XSLT transform, but got held up because 4Suite doesn't build cleanly on Cygwin. I'm still waiting for someone else to wrap DL_EXPORT() macros around every single external function and variable in 83 or so files. :/ [Hmm. Maybe I should just do it in the XSLT bit and hope against all logic that it doesn't call anything else.] If you want to start on it, feel free. I'm happy to extend the test framework to check not just the pprint output of the parser, but also the XML and XHTML. That way, as we finish the parser (adding ordered lists, for example) and add those test cases, you can see where you need to extend the template. Regards, Garth. |
|
From: David G. <dgo...@bi...> - 2001-08-10 01:23:01
|
I miswrote > 12:00 in Sydney [UTC+1000]). Should be 14:00 in eastern Australia. g'day! |
|
From: Tony J I. (Tibs) <to...@ls...> - 2001-08-09 08:05:33
|
> I've set up cron jobs on SourceForge to generate daily > snapshots of the working files from CVS. David - you're a hero. That will make my life a lot easier - as you say, CVS is quite low bandwidth (for a small set of files like this), but the problem with my connection isn't speed, it's up-and-down-ness, which can be very irritating. I'm getting the itch to code again - since it's often a trade-off between enough sleep and coding this isn't as easy a decision as it might be, but being able to keep up to date with the CVS makes it *possible* for me to consider contributing. What is the situation with HTML output and with docstring location - the former is easier, and the latter more interesting (but may be addressed by inspect.py in the near future) - is either worth a not-very-good commitment to look at, or is one of you going to be doing it soon? (hmm - should that question be on the other list?) Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "How fleeting are all human passions compared with the massive continuity of ducks." - Dorothy L. Sayers, "Gaudy Night" My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
|
From: David G. <dgo...@bi...> - 2001-08-09 05:05:21
|
I've set up cron jobs on SourceForge to generate daily snapshots of the working files from CVS. They'll be generated at 04:00 UTC (24:00 Eastern daylight time [UTC-0400], 21:00 Pacific daylight [UTC-0700], 12:00 in Sydney [UTC+1000]). The snapshots are located as follows: - DPS code & spec: http://docstring.sourceforge.net/dps-snapshot.tgz - DPS homepage: http://docstring.sourceforge.net/dps-web-snapshot.tgz - reStructuredText code & spec (includes restructuredtext/test on the Rrefactor-test branch): http://structuredtext.sourceforge.net/rst-snapshot.tgz - reStructuredText homepage: http://structuredtext.sourceforge.net/rst-web-snapshot.tgz There are no links to these on the web pages yet. I'll add them soon. -- David Goodger dgo...@bi... Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net |
|
From: David G. <dgo...@bi...> - 2001-08-01 04:36:08
|
subscribe here: http://lists.sourceforge.net/lists/listinfo/docstring-checkins |
|
From: David G. <go...@us...> - 2001-08-01 02:56:37
|
Update of /cvsroot/docstring/dps/dps/parsers
In directory usw-pr-cvs1:/tmp/cvs-serv3294/dps/dps/parsers
Modified Files:
model.py
Log Message:
added setup_parse() so unoverridden parse() could raise a NotImplementedError
Index: model.py
===================================================================
RCS file: /cvsroot/docstring/dps/dps/parsers/model.py,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** model.py 2001/07/22 22:35:42 1.1.1.1
--- model.py 2001/08/01 02:56:35 1.2
***************
*** 13,16 ****
def parse(self, inputstring):
! """Return a document tree."""
self.inputstring = inputstring
--- 13,20 ----
def parse(self, inputstring):
! """Override to parse `inputstring` and return a document tree."""
! raise NotImplementedError('subclass must override this method')
!
! def setup_parse(self, inputstring):
! """Initial setup, used by `parse()`."""
self.inputstring = inputstring
|
|
From: David G. <go...@us...> - 2001-08-01 02:46:49
|
Update of /cvsroot/docstring/dps/spec
In directory usw-pr-cvs1:/tmp/cvs-serv1656/dps/spec
Modified Files:
dps-notes.txt
Log Message:
minor mods
Index: dps-notes.txt
===================================================================
RCS file: /cvsroot/docstring/dps/spec/dps-notes.txt,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** dps-notes.txt 2001/07/22 22:36:09 1.1.1.1
--- dps-notes.txt 2001/08/01 02:46:47 1.2
***************
*** 9,14 ****
=====
- - set up CVS on SF!
-
- Complete PEP 258 DPS Generic Implementation Details.
--- 9,12 ----
***************
*** 18,29 ****
from 2001-06-19/20.
! - Document DTD element semantics.
! - Create a standalone reStructuredText -> HTML/XML converter (stdin ->
! stdout filter), as a proof of concept.
- Get cracking on the DPS itself!
- Add layout component to framework? Or part of the formatter?
--- 16,29 ----
from 2001-06-19/20.
! - Document!
! - Modules.
! - DTD element semantics.
- Get cracking on the DPS itself!
- Add layout component to framework? Or part of the formatter?
+
+ - Add validation? See http://pytrex.sf.net, RELAX NG.
|
|
From: David G. <dgo...@bi...> - 2001-07-29 23:35:45
|
on 2001-07-29 7:02 PM, Garth T Kidd (ga...@de...) wrote: > PyTREX looks like it can nicely validate the parser output (via > ``.asdom().toxml()``), but doesn't seem to provide tools for > automatically generating the patterns from the DTD. I'm not worried about that. There are tools out there, and it shouldn't be a frequent task. Incremental maintenance should be easy. > I can understand David's reluctance to use an external parser if he can > possibly avoid it; it just took me Much Work to get PyXML and 4Suite to > build and install under Cygwin. Yes, and I'm loathe to include anything but pure Python in the project. I work on a compiler-challenged OS, so feel like a second-class citizen when I'd like to use some C extension. Not to mention that I haven't done any C programming for 10 years. > David, are you intending your tests to be run only during testing, or as > an optional "paranoid mode" for dps and restructuredtext where people > can have all of their output checked for validity versus the DTD? Both? Both. Just having "paranoid mode" automatically means that it's available for testing too. David |
|
From: Garth T K. <ga...@de...> - 2001-07-29 23:02:50
|
> > Basically I'm looking for the XML/DOM equivalent of regular > > expression matching, something that can answer the question: > > "given a pattern P, is DOM tree D valid?" > > Sounds like you want pytrex. PyTREX looks like it can nicely validate the parser output (via ``.asdom().toxml()``), but doesn't seem to provide tools for automatically generating the patterns from the DTD. Can anyone suggest a way of filling the gap so that we don't have to hand-maintain the tests in sync with the DTD? Suspicions: if we switch to using an XML schema, perhaps we can pull PyTREX patterns out of the schema using XSLT. Perhaps we can build the schema from the PyTREX patterns. Perhaps we can establish some middle-format from which we can derive both schema and patterns -- `permittedContents` attributes in ``nodes.py``, or something. It's a fun problem to mull over, that's for sure. I can understand David's reluctance to use an external parser if he can possibly avoid it; it just took me Much Work to get PyXML and 4Suite to build and install under Cygwin. David, are you intending your tests to be run only during testing, or as an optional "paranoid mode" for dps and restructuredtext where people can have all of their output checked for validity versus the DTD? Both? Regards, Garth. |
|
From: Rich S. <rs...@zo...> - 2001-07-29 19:09:55
|
> Basically I'm > looking for the XML/DOM equivalent of regular expression matching, something > that can answer the question: "given a pattern P, is DOM tree D valid?" Sounds like you want pytrex. /r$ |
|
From: David G. <dgo...@bi...> - 2001-07-29 16:57:58
|
In the Docstring Processing System, there is a class library module [1]_ with one class for each element in the DTDs [2]_. The nodes (text & element objects) have an asdom() method, which constructs an xml.dom.minidom tree. I would like to implement a validate() method, which would verify that the content of each element node adheres to the content models from the DTDs. I could manually code each validate() method, but thought that there must be some way to encode the content models in the classes such that they can be automatically validated (without running an external parser). Basically I'm looking for the XML/DOM equivalent of regular expression matching, something that can answer the question: "given a pattern P, is DOM tree D valid?" Does anybody know of ways to accomplish this validation? Pointers to existing standards and/or implementations would be much appreciated. Any Python implementations out there? Thanks in advance. David Goodger .. _[1] http://docstring.sourceforge.net/dps/nodes.py .. _[2] http://docstring.sourceforge.net/spec/gpdi.dtd, http://docstring.sourceforge.net/spec/ppdi.dtd, http://docstring.sourceforge.net/spec/soextblx.dtd -- David Goodger dgo...@bi... Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net |
|
From: David G. <go...@us...> - 2001-07-29 15:56:01
|
Update of /cvsroot/docstring/dps In directory usw-pr-cvs1:/tmp/cvs-serv14176/dps Modified Files: README.txt Log Message: brought up to date Index: README.txt =================================================================== RCS file: /cvsroot/docstring/dps/README.txt,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -C2 -d -r1.1.1.1 -r1.2 *** README.txt 2001/07/22 22:36:35 1.1.1.1 --- README.txt 2001/07/29 15:55:58 1.2 *************** *** 5,9 **** Author: David Goodger Contact: dgo...@bi... - Version: 0.3 Date: $Date$ Web-site: http://docstring.sourceforge.net/ --- 5,8 ---- *************** *** 18,23 **** ! Archive Contents ! ================ * README.txt: You're reading it. --- 17,22 ---- ! Project Files & Directories ! =========================== * README.txt: You're reading it. *************** *** 28,41 **** * setup.py: Installation script. See "Installation" below. ! * spec: The project specification directory. Contains PEPs (Python ! Enhancement Proposals) and XML DTDs (document type definitions) * dps: The project source directory, installed as a Python package. Installation ============ ! The first step is to expand the dps.0.3.tar.gz archive. It contains a distutils setup file "setup.py". OS-specific installation instructions follow. --- 27,42 ---- * setup.py: Installation script. See "Installation" below. ! * install.py: Quick & dirty installation script. * dps: The project source directory, installed as a Python package. + * spec: The project specification directory. Contains PEPs (Python + Enhancement Proposals) and XML DTDs (document type definitions) + Installation ============ ! The first step is to expand the .tar.gz archive. It contains a distutils setup file "setup.py". OS-specific installation instructions follow. *************** *** 58,61 **** --- 59,64 ---- permissions to complete this step. + You can also just run install.py; it does the same thing. + Windows ------- *************** *** 72,75 **** --- 75,81 ---- <path_to_python.exe>\python setup.py install + If your system is set up to run Python when you double-click on .py + files, you can run install.py to do the same as the above. + MacOS ----- *************** *** 83,94 **** also wrong, and you will need to set up your system to recognize ".py" file extensions as Python files. See ! http://gotools.sf.net/mac/python.html for detailed instructions. ! Once set up, it's easiest to start over by expanding the archive ! again. 3. The distutils options window will appear. From the "Command" popup list choose "install", click "Add", then click "OK". Usage ===== --- 89,104 ---- also wrong, and you will need to set up your system to recognize ".py" file extensions as Python files. See ! http://gotools.sourceforge.net/mac/python.html for detailed ! instructions. Once set up, it's easiest to start over by expanding ! the archive again. 3. The distutils options window will appear. From the "Command" popup list choose "install", click "Add", then click "OK". + If install.py is a "Python module" (see step 2 above if it isn't), you + can run it instead of the above. The distutils options windown will + not appear. + Usage ===== *************** *** 96,102 **** The package modules are mostly in their infancy, continually growing and evolving. The module evolution is being driven by the ! reStructuredText parser project; see http://structuredtext.sf.net. The ! dps.statemachine module is usable independently. It contains extensive ! inline documentation (in reStructuredText format). The specs, the package structure, and the skeleton modules may also be --- 106,113 ---- The package modules are mostly in their infancy, continually growing and evolving. The module evolution is being driven by the ! reStructuredText parser project; see ! http://structuredtext.sourceforge.net. The dps.statemachine module is ! usable independently. It contains extensive inline documentation (in ! reStructuredText format). The specs, the package structure, and the skeleton modules may also be |
