bug reporting

[Martin von Loewis]

"Arthur Siegel" <ajs at ix.netcom.com> writes:

> It could waste time of the developers to have to
> weed through false alarm bug reports.  One of the
> roles of this list is to vet some of these issues.

That is a reasonable approach. However, the question is how one should
react if the newsgroup does not give any feedback.

IMO, the next step should be to research the exact cause oneself.

> The issue was related to overloading operators in a class subbed from the
> 'complex' built-in - not exactly a high traffic lane, I suspect.
> 
> Is the recommendation to submit it as a maybe bug?

In general, yes. If you clearly understand the problem and its causes,
and can demonstrate the problem in a small, self-contained example,
submit a bug report. Bug reports should be structured as
- what did I do
- what happened
- what did I expect to happen instead.

Without seeing the details of subclassing complex: there was a sort-of
explicit decision not to call subclass methods in the implementations
of the builtin types, for efficiency. So for a dictionary, .get()
won't call __getitem__(), instead, it will operate directly on the
internal representation. If your problem is of the same type, you will
need to implement all derived methods.

If it is something else, report a bug. Processing of a bug may take
many months; in some cases even years. Bug reports primarily help the
Python developers, not the reporters. 

Of course, the community at-large is encouraged to review the bug
reports, in addition to reading this list - perhaps they can help
resolving some of them.
 
Regards,
Martin