#39 Warnings on parameters upon overriding disappeared

[Jan T. Kim]

epydoc 2.1 produces a warning if the parameter list of
an overriding method does not match that of the
inherited method. This behaviour has disappeared in
epydoc 3.0alpha2.

Please bring back this warning, at least optionally
(i.e. by a command line option).

More generally, I would also appreciate it if, again at
least optionally, plain console output was available as
an alternative to the more colourful, curses-style
progress bars. This would provide for better
integration into automated setups (e.g. generation of
API documentation within a Makefile / autoconf /
automake etc.).

Thanks for your work.

Best regards, Jan

[Edward Loper]

Logged In: YES
user_id=195958

I'll try to work on brininging this warning message back.

As to the output format, you can control it to some extent
with -v; and if you are sending output to stream that
doesn't understand curses, epydoc *should* automatically
fall back to a more plain output format. (E.g., piping
epydoc through cat.)

If that's not sufficient output control, then please give
me a detailed description of what you'd like the output
format to look like. All logging & progress output is
handled by a "Logger" object, and it should be fairly easy
to swap in a new one with different behavior.

[Jan T. Kim]

Logged In: YES
user_id=968539

Thanks for your reply, I look forward to getting the
warnings in 3.0 too. It's so much better to be alerted to
epytext problems upon running epydoc than noticing problems
only upon using the generated docs.

Regarding the output format, I don't have any specific
preferences; my remark mainly resulted from running
3.0alpha2 for a number of times, trying to see whether the
warnings might flash by for a split second before being
overwritten by the progress bar.

Would it be possible to provide a command line option to
switch off the curses-based output format?

Also, would it be possible for epydoc to exit with a
non-zero exit code if any epytext problems (resulting in
warnings) occurred? This would reduce the risk of
overlooking these warnings when they occur in larger,
make-based development contexts.

Best regards & thanks, Jan

[Edward Loper]

Logged In: YES
user_id=195958
Originator: NO

Added a --simple-term option in revision 1461, which turns off all color & cursor control.

[Edward Loper]

Logged In: YES
user_id=195958
Originator: NO

Added three new options to control return value, for use with makefiles or other systems: --fail-on-error, --fail-on-warning, and --fail-on-docstring-warning.

(svn revision 1462)

[Edward Loper]

Logged In: YES
user_id=195958
Originator: NO

I am changing this item to a feature request; and I'm afraid it might have to wait for 3.1 -- we're trying to get 3.0 out the door.