Sorting attributes by catagory

[Ron Adam]

This is for a new version of pydoc if I can get the class attributes sorted
out. The module level attributes aren't too difficult to categorize.

(I might be just too tired to see the obvious.)

The original pydoc did this a somewhat round about way, so I would like to
find a more direct method if possible.


Where dir(obj) is used to get all attributes of a module or class. And
they are then sorted into categories depending on what they are.

(In order of precedence.)

For modules:

- imported_items (defined in another module,
or is another module)
- classes
- functions
- other_objects (everything else)


For classes:

- from_else_where (object created someplace else)
- inherited_attributes (from parents classes or type)
- static_methods_here
- class_methods_here
- other_methods
- properties
- getset_descriptors
- other_descriptors
- other_attributes (everything else)


A single function that accepts an object and can return one of the above
(or equivalent) strings would be ideal. Finer grained categorizing is ok
as long as they don't overlap more than one group.

It seems I can get some of these fairly easy with the inspect module, but
others I need to test in multiple ways.

Any ideas?


Cheers,
Ron

 

[Nick Vatamaniuc]

This is for a new version of pydoc if I can get the class attributes sorted
out. The module level attributes aren't too difficult to categorize.

(I might be just too tired to see the obvious.)

The original pydoc did this a somewhat round about way, so I would like to
find a more direct method if possible.

Where dir(obj) is used to get all attributes of a module or class. And
they are then sorted into categories depending on what they are.

(In order of precedence.)

For modules:

- imported_items (defined in another module,
or is another module)
- classes
- functions
- other_objects (everything else)

For classes:

- from_else_where (object created someplace else)
- inherited_attributes (from parents classes or type)
- static_methods_here
- class_methods_here
- other_methods
- properties
- getset_descriptors
- other_descriptors
- other_attributes (everything else)

A single function that accepts an object and can return one of the above
(or equivalent) strings would be ideal. Finer grained categorizing is ok
as long as they don't overlap more than one group.

It seems I can get some of these fairly easy with the inspect module, but
others I need to test in multiple ways.

Any ideas?

Cheers,
Ron

Ron,

Consider using epydoc if you can. Epydoc will sort the methods and it
will also let you use custom CSS style sheets for the final HTML
output. Check out the documentation of my PyDBTable module.
http://www.psipy.com/PyDBTable

-Nick Vatamaniuc

 

[Ron Adam]

Ron,

Consider using epydoc if you can. Epydoc will sort the methods and it
will also let you use custom CSS style sheets for the final HTML
output. Check out the documentation of my PyDBTable module.
http://www.psipy.com/PyDBTable

-Nick Vatamaniuc

Hi Nick,

I already have sorting and style sheets taken care of. I'm just trying to
get the content of each sub section correct at this point. The overall
frame work is finished.

I don't think Epydoc can replace the console help() output. The site.py
module imports help(), from pydoc.py. That serves as the consoles
interactive help mode. When you type help() at the console, you are using
pydoc.

Some of the differences...

Epydoc
------
Output formats:
- html files
- graphs (requires Graphviz) I like this!
- pdf files (requires latex)

* Requires explicitly generating files first.
* Supports file parsing only instead of introspection.

Epydoc is more of a complete application and has many nice features such as
the graphs and completeness checks, that will make it better than pydoc for
creating more complete pre-generated html documents with less work.

Pydoc
=====
Output formats:
- live interactive console text
- live interactive html with a local html server.
* no files are generated. (just in the browser cache)
* supports custom CSS stylesheets

(API data output...)
- text
- html page
- html section (for use in templates)
- xml
- reST (not yet, but will be easy to do)

The reason for having additional output formats is it makes it much easier
to use it as a tool to extract documentation from source code to be
combined with existing more complete documentation.

I am planning on writing output formatters to return docutils and docbook
data structures as well. With those, you will be able to convert to latex,
pdf, and other formats. The data formats for those are very close to what
I'm using, so this should be easy to do.

Other side benefits of doing this is that some of the modules in pydoc have
been generalized so that they can be used without pydoc. The html server,
and the document data and formatter classes, can be used independently of
pydoc.

The overall total size has not increased much, and it is more modular,
maintainable, and extendable. Maintainability is a major concern for any
library module or package.

Of course it will need to be approved first. ;-)

Cheers,
Ron

 

[Nick Vatamaniuc]

Hi Nick,

I already have sorting and style sheets taken care of. I'm just trying to
get the content of each sub section correct at this point. The overall
frame work is finished.

I don't think Epydoc can replace the console help() output. The site.py
module imports help(), from pydoc.py. That serves as the consoles
interactive help mode. When you type help() at the console, you are using
pydoc.

Some of the differences...

Epydoc
------
Output formats:
- html files
- graphs (requires Graphviz) I like this!
- pdf files (requires latex)

* Requires explicitly generating files first.
* Supports file parsing only instead of introspection.

Epydoc is more of a complete application and has many nice features such as
the graphs and completeness checks, that will make it better than pydoc for
creating more complete pre-generated html documents with less work.

Pydoc
=====
Output formats:
- live interactive console text
- live interactive html with a local html server.
* no files are generated. (just in the browser cache)
* supports custom CSS stylesheets

(API data output...)
- text
- html page
- html section (for use in templates)
- xml
- reST (not yet, but will be easy to do)

The reason for having additional output formats is it makes it much easier
to use it as a tool to extract documentation from source code to be
combined with existing more complete documentation.

I am planning on writing output formatters to return docutils and docbook
data structures as well. With those, you will be able to convert to latex,
pdf, and other formats. The data formats for those are very close to what
I'm using, so this should be easy to do.

Other side benefits of doing this is that some of the modules in pydoc have
been generalized so that they can be used without pydoc. The html server,
and the document data and formatter classes, can be used independently of
pydoc.

The overall total size has not increased much, and it is more modular,
maintainable, and extendable. Maintainability is a major concern for any
library module or package.

Of course it will need to be approved first. ;-)

Cheers,
Ron

Thanks for the info, Ron. I had no idea pydoc was that powerful!
-Nick

 

[Ron Adam]

Thanks for the info, Ron. I had no idea pydoc was that powerful!
-Nick

Change *was* to *will be*.

It really needed to be re factored. ;-)


Cheers,
Ron