[Doc-SIG] A promise

Fred L. Drake, Jr. fdrake@acm.org
Mon, 27 Nov 2000 12:14:18 -0500 (EST)

Tony J Ibbs (Tibs) writes:
 > If we don't have a solution for Python 2.1, I will be sad, but not
 > devastated. On the other hand, if we don't have a solution for 2.2, I
 > shall be angry.

  At this point, I don't think worrying about Python releases is
interesting.  Until there's something to use, it doesn't matter.  I
don't see any reason to bundle the tool until it's pretty much
"right".  There's also no precedent of including executable tools
beyond the interpreter itself for Unix, so I don't think this is an

Lawrence Tratt sea:
 > Bad idea. IMHO, the only way to create a professional tool is
 > to get it to use Pythons parse trees ("import"ing the modules
 > is at best mickey mouse even if it solves one or two problems
 > that static analysis can't hope to) and that really means that

  I agree that parse-tree analysis is required; I don't see why this
precludes making the tool a little more general.  If 1.5.2 support is
required by the author of the tool, it's a requirement I won't argue
with!  I think it's a fair requirement that the modules being
documented be parsable by the version of Python doing the parsing --
if a module uses list comprehensions, it's ok if the doc tool can't
handle it when run under 1.5.2.  Pulling interesting information out
of the parse trees isn't that hard; at most, there may need to be
different sets of patterns to match against based on version, but
there just aren't that many versions to worry about.  Supporting
Jython will be harder, but also should not be too hard.  (This points
to using the tokenize module instead of the parser module, as well.)

 > It will use REs <fx:spit> because that's "standard" and I don't want to
 > fight the "getting a parser into Python" battle.

  There's already a Python parser in the interpreter; it doesn't
require building one.  So this is a freebie.  ;)

 > I don't expect *other* people to get "excited" about this (but heh, I've
 > had three responses, which is about, ooh, two more than I expected!).
 > Ultimately, the only response that *counts* will be Guido's (and I
 > *suspect* that also means Frank's) when something gets finished and

  So who is this Frank person, and why is he involved in this?
  My comments on the tool will inform Guido's, if that's what you're
getting at.  Which is not to say that he'll agree with any conclusions
I make.  ;)


Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations