epydoc-devel — Discussions about epydoc development

Re: [Epydoc-devel] errors in 3.0alpha

[Stefan S. <se...@sy...>]

Edward Loper wrote:
> Stefan Seefeld wrote:
> 
>> I had a look at that but wasn't quite sure what to check out. I expected
>> the content of 'trunk' to be the root of the mainline, but it looks more
>> as if http://svn.sourceforge.net/viewcvs.cgi/epydoc/trunk/epydoc/src/
>> is what I'm looking for
> 
> 
> To get the contents of the current trunk (including docs, source code, 
> sandbox, etc), use:
> 
> % svn co https://svn.sourceforge.net/svnroot/epydoc/trunk/epydoc epydoc
> 
> To get just the source code for epydoc, use:
> 
> % svn co 
> https://svn.sourceforge.net/svnroot/epydoc/trunk/epydoc/src/epydoc epydoc

Thanks !
It appears none of the errors I reported are still there. I get a number
of nicely formatted 'Error' and 'Warning' messages which I don't yet understand,
but none of this look fatal.

>> To be honest, the main reason for me to try out epydoc is because I was
>> looking into the javadoc and rest parsers for inspiration, [...]
>> Thus there is considerable overlap with tools such as epydoc. May be 
>> there
>> are some ideas to share...
> 
> 
> I'm sure there are -- I've taken more than a few good ideas from some of 
> the other API documentation extractors out there, including javadoc, 
> doxygen, pydoc, pythondoc, etc.  A nice list of these tools is available 
> at <http://www.stack.nl/~dimitri/doxygen/links.html>

Yeah, I'm aware of that list. :-)

Thanks a lot !

Regards,
		Stefan

Re: [Epydoc-devel] errors in 3.0alpha

[Edward L. <ed...@gr...>]

Stefan Seefeld wrote:

> I had a look at that but wasn't quite sure what to check out. I expected
> the content of 'trunk' to be the root of the mainline, but it looks more
> as if http://svn.sourceforge.net/viewcvs.cgi/epydoc/trunk/epydoc/src/
> is what I'm looking for

To get the contents of the current trunk (including docs, source code, 
sandbox, etc), use:

% svn co https://svn.sourceforge.net/svnroot/epydoc/trunk/epydoc epydoc

To get just the source code for epydoc, use:

% svn co 
https://svn.sourceforge.net/svnroot/epydoc/trunk/epydoc/src/epydoc epydoc

> To be honest, the main reason for me to try out epydoc is because I was
> looking into the javadoc and rest parsers for inspiration, [...]
> Thus there is considerable overlap with tools such as epydoc. May be there
> are some ideas to share...

I'm sure there are -- I've taken more than a few good ideas from some of 
the other API documentation extractors out there, including javadoc, 
doxygen, pydoc, pythondoc, etc.  A nice list of these tools is available 
at <http://www.stack.nl/~dimitri/doxygen/links.html>

-Edward

Re: [Epydoc-devel] errors in 3.0alpha

[Stefan S. <se...@sy...>]

Edward Loper wrote:
> Hi, Stefan.
> 
> Thanks for the bug reports.  I *believe* that all the bugs you noted 
> should be fixed in the most recent version of epydoc (i.e., in the 
> subversion repository).  But I can't test that without having a piece of 
> sample code that elicits the problem.  If you're comfortable with using 
> subversion, please check out the most recent version of epydoc and see 
> if the problem(s) still exist:
> 
>   <http://sourceforge.net/svn/?group_id=32455>

I had a look at that but wasn't quite sure what to check out. I expected
the content of 'trunk' to be the root of the mainline, but it looks more
as if http://svn.sourceforge.net/viewcvs.cgi/epydoc/trunk/epydoc/src/
is what I'm looking for (I judged simply by the existence of a 'setup.py'
file). Also, I'm not sure what URL to feed to svn for the checkout. None
of the ones I tried worked. Can you help ?
Thanks !

> 
> If you'd rather not check out a copy from subversion, or the problem(s) 
> still exist, please file a bug report on sourceforge:
> 
>   <http://sourceforge.net/tracker/?group_id=32455&atid=405618>
> 
> If possible, please include an attachment containing a small piece of 
> sample code that elicits the problem(s).

Ok, I will try to.

To be honest, the main reason for me to try out epydoc is because I was
looking into the javadoc and rest parsers for inspiration, as I'd like
to improve the synopsis tool (http://synopsis.fresco.org). Synopsis
provides tools to parse source code in different languages (Python, IDL,
C, C++) and then process the generated AST, for example into documentation.

Thus there is considerable overlap with tools such as epydoc. May be there
are some ideas to share...

Regards,
		Stefan

Re: [Epydoc-devel] errors in 3.0alpha

[Edward L. <ed...@gr...>]

Hi, Stefan.

Thanks for the bug reports.  I *believe* that all the bugs you noted 
should be fixed in the most recent version of epydoc (i.e., in the 
subversion repository).  But I can't test that without having a piece of 
sample code that elicits the problem.  If you're comfortable with using 
subversion, please check out the most recent version of epydoc and see 
if the problem(s) still exist:

   <http://sourceforge.net/svn/?group_id=32455>

If you'd rather not check out a copy from subversion, or the problem(s) 
still exist, please file a bug report on sourceforge:

   <http://sourceforge.net/tracker/?group_id=32455&atid=405618>

If possible, please include an attachment containing a small piece of 
sample code that elicits the problem(s).

Thanks!
-Edward

[Epydoc-devel] more errors in 3.0alpha

[Stefan S. <se...@sy...>]

Hi there,

here is another error I get when parsing a different python
package:

...
   File "/usr/local/lib/python2.3/site-packages/epydoc/docintrospecter.py", line 144, in introspect_docs
     val_doc = introspecter(value)
   File "/usr/local/lib/python2.3/site-packages/epydoc/docintrospecter.py", line 332, in 
introspect_class
     basedoc.subclasses.append(class_doc)
AttributeError: 'ValueDoc' object has no attribute 'subclasses'

Thanks for any help.

Regards,
		Stefan

[Epydoc-devel] errors in 3.0alpha

[Stefan S. <se...@sy...>]

Hi there,

I'm trying out the new 3.0alpha version, which generates a variety
of errors on some of my code:


Here is the top of the stack trace for one:

   File "/usr/local/lib/python2.3/site-packages/epydoc/docintrospecter.py", line 139, in introspect_docs
     return _valuedoc_cache[pyid]
KeyError: -1208366636

Without really knowing what I was doing, I changed line 138 to

     if pyid in _valuedoc_cache:

and the error went away.

With that I get 'maximum recursion depth exceeded' with the following two functions
in the recursion:

   File "/usr/local/lib/python2.3/site-packages/epydoc/docintrospecter.py", line 257, in 
introspect_module
     child_val_doc = introspect_docs(child, context=module_doc)
   File "/usr/local/lib/python2.3/site-packages/epydoc/docintrospecter.py", line 144, in introspect_docs
     val_doc = introspecter(value)

(obviously the value is always the same).

Are these known problems ? Any ideas how I can debug this further ?

Thanks,
		Stefan

Re: [Epydoc-devel] epydoc 3.0 docstring truncation

[Tim V. S. <tva...@gm...>]

Awesome, thanks for the quick response!

On 3/23/06, Edward Loper <ed...@gr...> wrote:
>
> Tim Van Steenburgh wrote:
> > Had my first experience with epydoc today, using 3.0.  Ran the GUI tool
> > wth default options to create html docs for a single py file.  The firs=
t
> > character of every line in my docstrings has been truncated in the html
> > output.  Google didn't help me this time.  Any ideas?
>
> Yeah, this is caused by a bug in epydoc 3.0 alpha's handling of systems
> that use CRLF for newline.  It's fixed in subversion.
>
> If you're comfortable with it, I'd recommend getting epydoc from
> subversion for now -- there have been a lot of other bug fixes too (as
> well as some new features).  Epydoc 3.0 involved a lot of changes from
> epydoc 2, and is still very much an alpha release.
>
> Otherwise, you could wait for the next alpha (or beta) release, or just
> use epydoc 2 for now.
>
> -Edward
>
> p.s., If you'd prefer a quick fix, replace 'r' with 'rU' in line 517 or
>   epydoc/docparser.py:
>
> -    module_file =3D codecs.open(module_doc.filename, 'r', encoding)
> +    module_file =3D codecs.open(module_doc.filename, 'rU', encoding)
>

Re: [Epydoc-devel] epydoc 3.0 docstring truncation

[Edward L. <ed...@gr...>]

Tim Van Steenburgh wrote:
> Had my first experience with epydoc today, using 3.0.  Ran the GUI tool 
> wth default options to create html docs for a single py file.  The first 
> character of every line in my docstrings has been truncated in the html 
> output.  Google didn't help me this time.  Any ideas?

Yeah, this is caused by a bug in epydoc 3.0 alpha's handling of systems 
that use CRLF for newline.  It's fixed in subversion.

If you're comfortable with it, I'd recommend getting epydoc from 
subversion for now -- there have been a lot of other bug fixes too (as 
well as some new features).  Epydoc 3.0 involved a lot of changes from 
epydoc 2, and is still very much an alpha release.

Otherwise, you could wait for the next alpha (or beta) release, or just 
use epydoc 2 for now.

-Edward

p.s., If you'd prefer a quick fix, replace 'r' with 'rU' in line 517 or 
  epydoc/docparser.py:

-    module_file = codecs.open(module_doc.filename, 'r', encoding)
+    module_file = codecs.open(module_doc.filename, 'rU', encoding)

[Epydoc-devel] epydoc 3.0 docstring truncation

[Tim V. S. <tva...@gm...>]

Had my first experience with epydoc today, using 3.0.  Ran the GUI tool wth
default options to create html docs for a single py file.  The first
character of every line in my docstrings has been truncated in the html
output.  Google didn't help me this time.  Any ideas?

[Epydoc-devel] definition lists

[John M. G. <joh...@ya...>]

I'm using epydoc 2.1 and it doesn't look like I can write
definition lists with epytext. Is there a way to put definition
lists in my epydocs?

For now I'm stuck using double-dashes:

    - item one -- description
    - item two -- another description
    - and so on -- ...

Thanks,
---John


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Epydoc-devel] Re: Testing input encodings

[Edward L. <ed...@gr...>]

Daniele Varrazzo wrote:
> Hello Edward,
> 
> i can see in epydoc 3 there is support for encoding detection in
> source files, but i can't trigger it.
> 
> I am trying to generate docs for the included package, but source
> encoding is not detected. I am using the following command line:
> 
>     epydoc -o out --docformat=restructuredtext -v inenctest
> 
> You may use those files to extensively check if ascii+xml entities
> works in edge cases: there is a koi8r-encoded file and a fancy utf8
> file with some arabic, and some ebraic characters thrown in.

If you read pep 263 [1] carefully, the encoding directive applies to 
unicode strings, comments, and identifiers, but *not* to non-unicode 
strings.  In particular, under "Concepts", bullet 3, sub-bullet 5, it 
says that the tokenizer should:

     ... [create] string objects from the Unicode literal data
     by first reencoding the UTF-8 data into 8-bit string data
     using the given file encoding

You can see that this is indeed Python's behavior by introspecting one 
of the objects in your test modules:

 >>> import inenctest.encoding_test_utf8
 >>> print `inenctest.encoding_test_utf8.__doc__`
'Encoding epydoc test.\n\nCharacters in 128-155 
range:\n\xc3\xa0\xc3\xa8\xc3\xac\xc3\xb2\xc3\xb9\xc2\xa5\xc2\xa9\xc2\xae\n\nGoing 
east\n\xd1\x82\xd0\xb7\xd0\xb3\xd1\x8f\xd0\xb8\xd1\x95\n\nSouth 
east\n\xd7\x90\xd7\x91\xd7\x92\xd7\x93\n\nMore 
south\n\xd8\xb3\xd8\xb4\xd8\xb5\xd8\xb6\xd8\xb7\n\n'

The correct fix, then, is to use unicode strings as docstrings.  That 
way, your docstrings will behave right both within epydoc & within 
python.  To me, this seems analagous to people who use:

     def f(x):
         """Split x on newlines ('\n')"""

Where they should be using:

     def f(x):
         r"""Split x on newlines ('\n')"""

The introspection system, at least, gives a warning message that I hoped 
would let people know how to fix their mistake:

Warning: inenctest.encoding_test_utf8's docstring is not a unicode
          string, but it contains non-ascii data -- treating it as
          latin-1.

It looks like the parser doesn't print out a similar warning, so if you 
use --parse-only, you won't see this warning.  Maybe I should add a 
warning there.  Although it would be non-trivial to do. :-/


All that being said, I can see an argument for interpreting the 
docstrings according to the unicode encoding specified at the top, 
despite the fact that that's *not* how Python interprets them -- because 
that's almost certainly how the author intends for docstrings to be 
interpreted.  One problem, though, would be that it's not clear how I 
would figure out the encoding of the module if a user uses 
--inspect-only.  The easiest way to do this would be to not re-encode 
non-unicode strings; but then variables would be displayed with 
incorrect values.

So at this point, I'm still undecided which way to go -- be compliant 
with PEP 263 & Python, or be lenient and "do what I mean, not what I say."

-Edward

p.s., the two of your files that start with a BOM point out that my 
parser system currently fails if the file starts with a BOM; that, I 
will fix.

[1] http://www.python.org/doc/peps/pep-0263/

[Epydoc-devel] Moving to subversion

[Edward L. <ed...@gr...>]

I have moved development for epydoc 3.0 to the subversion repository, in 
the main src/ directory:

     <http://svn.sourceforge.net/epydoc>

The version of epydoc 3.0 in the CVS sandbox/ directory is now outdated. 
  CVS still contains the most up-to-date version of epydoc 2.

-Edward

[Epydoc-devel] Epydoc 3.0 alpha release

[Edward L. <ed...@gr...>]

I just uploaded an alpha release for epydoc 3.0 to sourceforge.  Epydoc 
3.0 still has a ways to go until it's ready for release, but I wanted to 
give people a chance to play with its new features, and to point out any 
bugs that they find.

Significant portions of epydoc were rewritten from scratch for this
version.  This has allowed me to increase epydoc's functionality in
several significant ways; but in this alpha release, some features
from epydoc 2.1 are not yet available, including LaTeX/ps/pdf output,
and completeness checking.  If you need those features, then you
should keep using epydoc 2.1.  If you find any bugs, or have
suggestions for improving it, please report them on sourceforge:

Bugs: <http://sourceforge.net/tracker/?group_id=32455&atid=405618>
Features: <http://sourceforge.net/tracker/?group_id=32455&atid=405621>

-Edward

---------------------------------------------------------------------
Summary of Changes:

The most significant change has to do with the way that epydoc
extracts documentation information about python modules.  In previous
versions, epydoc extracted information about each module by importing
it, and using introspection to examine its contents.  The new version
of epydoc still supports introspection, but is also capable of
extracting information about python modules by parsing their source
code.  Furthermore, the new version of epydoc can combine these two
sources of information (introspection & parsing).  This is important
because each source has its own advantages and disadvantages with
respect to the other.  In particular:

   - Introspection gives epydoc an accurate picture of what modules
     will look like programmatically.  In particular, some modules
     actively modify the namespace they define, or use various "magic"
     techniques to alter their public interface.  Using introspection
     gives epydoc an accurate picture of what these modified interfaces
     look like.

   - If a module has dependencies that are not met on the current system,
     then it may not be possible to import and introspect it; but the
     parser can still examine its contents.

   - If importing a module has significant side effects, then
     introspecting it might not be desirable; but the parser can
     still examine its contents.

   - If a module is not trusted, then it might not be desirable to
     import it; but the parser can still examine its contents.

   - By parsing a module, we can find "pseudo-docstrings" and
     "docstring comments," which are unavailable via introspection.
     In particular, this makes it possible to associate API
     documentation with variables.

   - Introspection can give information about builtin and extension
     modules, which would be unavailable to a python source code
     parser.  This includes builtin or extension bases for pure Python
     classes.

   - By parsing a module, we can easily determine which values were
     imported, and where they were imported from.  This information
     is not available via introspection.

Other improvements include:

   - Support for "pseudo-docstrings".  If a variable assignment
     statement is immediately followed by a bare string literal, then
     that assignment is treated as a docstring for that variable.  In
     classes, variable assignments at the class definition level are
     considered class variables; and assignments to instance variables
     in the constructor (__init__) are considered instance variables:

         >>> class A:
         ...     x = 22
         ...     """Docstring for class variable A.x"""
         ...
         ...     def __init__(self, a):
         ...         self.a = a
         ...         """Docstring for instance variable A.a"""

   - Support for "comment docstrings".  If a variable assignment
     is immediately preceeded by a comment whose lines begin with
     "#:", or is followed on the same line by such a comment, then
     it is treated as a docstring for that variable:

         >>> #: docstring for x
         ... x = 22

         >>> y = 33 #: docstring for y

   - Increased robustness in the face of a variety of "magic"
     manipulations of namespaces.

   - Support for nested classes

   - Full unicode support, including support for the 'encoding
     directive' (PEP 263).

   - The HTML output now includes pointers to colorized source
     code listings; and these source code listings contain
     pointers back into the documentation.

   - Methods that are inherited from "external" base classes are
     listed, but no longer described in detail.  E.g., if "object"
     is used as a base class, then the methods inherited from
     "object" will be listed at the bottom of the method summary
     table, but not described in detail.

   - The HTML output no longer contains separate pages for
     including and excluding private variables.  Instead, it uses
     CSS to dynamically hide or display private variables.  A
     cookie is used to record the user's preference.  (By default,
     private variables are hidden.)

[Epydoc-devel] Re: New rules for public objects definition

[Daniele V. <dan...@gm...>]

The patch eventually grew into something more complex, so i created a
CVS branch named "exp-all-is-interface" to continue testing.

Everybody is encouraged to test the if the generated doc fits your
needs and if the new strategy doesn't break documentation generation
for previously workable packages.

To check out the difference, please take a look at
http://www.initd.org/people/piro/static/psycopg2 (generated from the
branch version) and
http://www.initd.org/people/piro/static/psycopg2-head (generated from
the head version). For example, the "connection" and "cursor" objects
are exposed in the "extensions" package (where people should pick
from) instead of hidden in the _psycopg extension module.

[Epydoc-devel] Epydoc can detect source encoding

[Daniele V. <dan...@gm...>]

Hello,

i just checked into CVS a patch to enable correct parsing of non-ascii
input sources.

Source files encoding is read detected form the first two lines (or from
the file BOM for utf-8 encoded files) as per PEP 263.

The default utf-8 output encoding should be safe against any encoding error.

I only performed tests with reStructuredText docformat and html output:
further testing would be really appreciated.

Daniele

[Epydoc-devel] New rules for public objects definition

[Daniele V. <dan...@gm...>]

Hello,

i just submitted the patch 1400068 where the following updates are proposed:

 - if an object imported from a .c module is in the __all__ attribute
   of a .py module, it is considered belonging to the python module.
   This enables to shape the package structure (the API) using python
   modules, leaving c module as an implementative detail.
 - All modules specified on the command line not starting with an
   underscore are "public" and so - for example - appear in the toc
   and in the parent summary (the previous behavior is to made them
   public only if effectively imported by parent) This makes Epydoc more
   friendly towards those packages which are not made to be entirely
   imported.

Feedback on these updates is appreciated. I'd like to read somebody's
(and of course Edward's) opinion before applying the patch into the CVS.

Daniele

P.S. Patch url:
http://sourceforge.net/tracker/index.php?func=detail&aid=1400068&group_id=32455&atid=405620

[Epydoc-devel] Output for non-ascii characters fixed.

[Daniele V. <dan...@gm...>]

Hello list,

i just submitted a patch into CVS to fix Epydoc troubles with non-ascii
characters when ReStructuredText strings are used.

Applying something like John Lenton's patch 1205207, there is now an
--encoding option to select an output encoding. Default is utf-8. The
same encoding is also used to encode reST strings after they are
converted into html.

What i am going to fix now is the handling of input encoding. By default
docutils use the local encoding, so correct results can be obtained if
the sources encoding match it. utf-8 encoded sources are handled well
anyway. I want to read the correct encoding from the first source lines
(or the BOM) as per PEP 263.

Cheers,

Daniele

Re: [Epydoc-devel] [Fwd: Some ideas for epydoc]

[Simon B. <si...@ar...>]

On Thu, 07 Jul 2005 14:26:51 +0200
Reinhard Mueller <rei...@by...> wrote:

> Hello,
> 
> I sent the mail quoted below to edloper at gradient dot cis dot upenn
> dot edu more than a month ago, but I didn't receive any reaction so far.
> 
> Is the epydoc project still alive at all? Is this list the right place
> to ask such questions?
> 
> Thanks,
> Reinhard

I am in a similar situation; we have adopted epydoc at our company [1]
and have been modifying the code to be able to deal with latex math 
expressions. It seems that epydoc is the best tool around for doing
what it does (docstring extraction for api docs), and lots of people use
it (eg. the twisted folk).

...
> As epydoc has helped us a lot in the past, I would be willing (and able)
> to donate some manpower to epydoc (I represent a company). So I would
> appreciate your feedback on whether you would accept and incorporate
> patches to epydoc that solve the above points.
> 
> Thanks,
> Reinhard
> 

Yes, you bring up some good points. We are also prepared to work on
epydoc and contribute patches. 

bye,

Simon.

[1] http://sml.nicta.com.au


-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Epydoc-devel] [Fwd: Some ideas for epydoc]

[Fred L. D. Jr. <fd...@ac...>]

On Thursday 07 July 2005 08:26, Reinhard Mueller wrote:
 > Is the epydoc project still alive at all? Is this list the right place
 > to ask such questions?

I think it is, but it's not my project.

I think Ed's been really busy, and have no idea whether he's using Python 
these days or not.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

[Epydoc-devel] [Fwd: Some ideas for epydoc]

[Reinhard M. <rei...@by...>]

Hello,

I sent the mail quoted below to edloper at gradient dot cis dot upenn
dot edu more than a month ago, but I didn't receive any reaction so far.

Is the epydoc project still alive at all? Is this list the right place
to ask such questions?

Thanks,
Reinhard

-------- Weitergeleitete Nachricht --------
Betreff: Some ideas for epydoc
Datum: Wed, 01 Jun 2005 14:43:38 +0200
Hi,

we excessively use epydoc in the GNU Enterprise project
(http://www.gnuenterprise.org).

When I was playing with epydoc, I stumbled across a few points which I
could be an improvement for epydoc:

* If epydoc is run on a certain source tree, it even imports and
processes modules outside the source tree if they are used (imported)
within the code. It might be a good idea to provide an option to turn
this off. Example: if any of my code contains the line "import
SocektServer" (a standard Python module), epydoc parses the docstrings
of SocketServer.py (provided by Python) which unfortunately isn't valid
epydoc syntax, so an error message is generated.

* We sometimes import modules that add an identifier to __builtins__.
Whenever such an identifier is used in module initialization code,
epydoc stumbles over that.

* When a module generates a exception when imported, it would help if
there was a way to get the *full* traceback instead of only the
exception text.

* I would love an option to make epydoc output sorted in the order of
appearance in the file instead of alphabetically. This way, a logical
order of e.g. functions within a class in the source code would also end
up in a logical order of the function descriptions in epydoc output.

As epydoc has helped us a lot in the past, I would be willing (and able)
to donate some manpower to epydoc (I represent a company). So I would
appreciate your feedback on whether you would accept and incorporate
patches to epydoc that solve the above points.

Thanks,
Reinhard

[Epydoc-devel] Error: 1

[Leonardo G. <leo...@ri...>]

Error importing 'module.module': 1
Where and which the error?
Thanks, Leonardo.

[Epydoc-devel] select encoding of html files

[John L. <jl...@gm...>]

The attached patch adds an option, encoding, that selects the encoding
of the (x)html files.

I hope the patch format is ok.

--=20
John Lenton (jl...@gm...) -- Random fortune:
Don't anthropomorphise computers and cars, They hate that.

[Epydoc-devel] latex math

[Simon B. <si...@ar...>]

We have a requirement for latex math (eg. $\sum_i x_i$) in our documentation,
and i'd like to patch epydoc to handle this:.

In the latex.py I would change _text_to_latex to no do anything to stuff in between $,
and for the html i would patch the _to_html method in epytext.py. Probably I would
use PyX (it has good support for calling tex) and the ghostscript command to
render the latex into an image.

I guess the syntax would be something like M{$\sum_i x_i$}.

Is there any interest in supporting such a patch ? Any other suggestions ?

Simon.


-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Epydoc-devel] Epydoc + wxPython

[Robin D. <ro...@al...>]

João Vilela wrote:
> Hi!
> 
> I don't know if this is the right place for this but there isn't a list
> for questions and the main developer didn't respond me, so...
> 
> When using epydoc with a program in wxPython I get the following errors:
> 

>     return '%s.%s' % (self.module(), objname)
>   File "/usr/local/lib/python2.4/site-packages/epydoc/uid.py", line 585,
> in module
>     if (self._module is not None and
>   File
> "/usr/local/lib/python2.4/site-packages/wx-2.5.4-gtk2-ansi/wx/_gdi.py",
> line 398, in __eq__
>     return _gdi_.Pen___eq__(*args, **kwargs)
> TypeError: argument number 2: a 'wxPen *' is expected, 'type(<class
> 'wx._core.App'>)' is received
> 
> Any clue?

There is a patch for this problem in this message:
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:msp:36880:lahoembohbmdnoafcplj


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!

[Epydoc-devel] Epydoc + wxPython

[<jv...@dc...>]

Hi!

I don't know if this is the right place for this but there isn't a list
for questions and the main developer didn't respond me, so...

When using epydoc with a program in wxPython I get the following errors:

1 - Normal mode:

Importing 1 modules.
  [.]
Building API documentation for 1 modules.
  [.]
INTERNAL ERROR: argument number 2: a 'wxPen *' is expected, 'type(<class
'wx._core.App'>)' is received
Writing HTML docs (10 files) to 'html'.
  [..........]

2 - Debug mode:

Importing 1 modules.
  [1/1] Importing isap.py
Building API documentation for 1 modules.
  [1/1] Building docs for isap
    Building docs for isap
    Building docs for isap.App
Traceback (most recent call last):
  File "/usr/local/bin/epydoc", line 7, in ?
    cli()
  File "/usr/local/lib/python2.4/site-packages/epydoc/cli.py", line 110,
in cli
    docmap = _make_docmap(modules, options)
  File "/usr/local/lib/python2.4/site-packages/epydoc/cli.py", line 483,
in _make_docmap
    try: d.add(module)
  File "/usr/local/lib/python2.4/site-packages/epydoc/objdoc.py", line
2954, in add
    self._add(objID)
  File "/usr/local/lib/python2.4/site-packages/epydoc/objdoc.py", line
2968, in _add
    self._add(link.target())
  File "/usr/local/lib/python2.4/site-packages/epydoc/objdoc.py", line
2961, in _add
    self.add_one(objID)
  File "/usr/local/lib/python2.4/site-packages/epydoc/objdoc.py", line
2900, in add_one
    self.data[objID] = ClassDoc(objID, self._verbosity)
  File "/usr/local/lib/python2.4/site-packages/epydoc/objdoc.py", line
1589, in __init__
    self._base_order = [make_uid(b) for b in base_order]
  File "/usr/local/lib/python2.4/site-packages/epydoc/uid.py", line 781,
in make_uid
    uid = ObjectUID(object)
  File "/usr/local/lib/python2.4/site-packages/epydoc/uid.py", line 418,
in __init__
    name = self._findname()
  File "/usr/local/lib/python2.4/site-packages/epydoc/uid.py", line 509,
in _findname
    return '%s.%s' % (self.module(), objname)
  File "/usr/local/lib/python2.4/site-packages/epydoc/uid.py", line 585,
in module
    if (self._module is not None and
  File
"/usr/local/lib/python2.4/site-packages/wx-2.5.4-gtk2-ansi/wx/_gdi.py",
line 398, in __eq__
    return _gdi_.Pen___eq__(*args, **kwargs)
TypeError: argument number 2: a 'wxPen *' is expected, 'type(<class
'wx._core.App'>)' is received

Any clue?

Tks in advance!
JP