[Numpy-discussion] OpenOpt Suite release 0.45

Robert Kern robert.kern@gmail....
Wed Apr 10 02:31:24 CDT 2013


On Wed, Apr 10, 2013 at 12:30 PM, Dmitrey <tmp50@ukr.net> wrote:
>
>
> --- Исходное сообщение ---
> От кого: "Robert Kern" <robert.kern@gmail.com>
> Дата: 9 апреля 2013, 14:29:43

>> Well, it's your software. You are free to make it as buggy as you wish, I
>> guess.
>
> Yes, and that's why each time I get a bugreport I immediately start working
> on it, so usually I have zero opened bugs,  as now . It somewhat differs
> from  your bugtracker , that has tens of opened bugs, and ~ half of them are
> hanging for years (also, half of them are mentioned as high and highest
> priority) . But it's definitely your right  to keep it as buggy as you wish,
> as well!

You think comparing tracked bug counts across different projects means
anything? That's adorable. I admire your diligence at addressing the
bugs that you do acknowledge. That was never in question. But refusing
to acknowledge a bug is not the same thing as fixing a bug.

You cannot use objects that do not have a valid __eq__() (as in,
returns boolean True if and only if they are to be considered
equivalent for the purpose of dictionary lookup, otherwise returns
False) as dictionary keys. Your oofun object still violates this
principle. As dictionary keys, you want them to use their `id`
attributes to distinguish them, but their __eq__() method still just
returns another oofun with the default object.__nonzero__()
implementation. This means that bool(some_oofun == other_oofun) is
always True regardless of the `id` attributes. You have been
unfortunate enough to not run into cases where this causes a problem
yet, but the bug is still there, lurking, waiting for a chance hash
collision to silently give you wrong results. That is the worst kind
of bug.

--
Robert Kern


More information about the NumPy-Discussion mailing list