Being not quite the biggest Windows-lover, I haven't come across the
backslash problem yet. I'll try it myself.
> Also, some of the URLs are just flat out wrong. When running Apydia
> against the Turbogears trunk, for example, several of the documented
> methods (see "TurboGearsController") are inherited from Pylons, and
> these seem to be generated incorrectly.
Yep, there's a problem with inheritance. The URLs can't work, because
how should Apydia know where to look for the other project's Trac for
the baseclass? The best solution I've come up with so far is to just
remove the "View Source"-links for these methods (not in trunk yet).
If anyone has a better idea, please let me know.
> Some of the methods are missing as well.
Not good. I guess you're speaking of "_perform_call". I'll have to do
further investigations to find out why that is.
> A great start though...looking forward to seeing more!
Thank you for your nice feedback!
--
Daniel Haus
http://ematia.de
Probably you need to use posixpath for URLs, somewhere that you are
currently using os.path.
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
Yep, there's a problem with inheritance. The URLs can't work, because
how should Apydia know where to look for the other project's Trac for
the baseclass? The best solution I've come up with so far is to just
remove the "View Source"-links for these methods (not in trunk yet).
If anyone has a better idea, please let me know.
> Is there a way to figure out what package the superclass is in? If
> there is, then maybe apydia can search PyPI for the homepage of that
> package and insert a link to that homepage.
>
> Of course I don't know of a way to figure out what package it's in,
> and this would cause all sorts of other problems, but it's a thought.
Great Idea.
At least it'd be helpful to know (and to display) what class the
method belongs to. And to show inherited methods separately.