failed unittest in py-kdtree_test.py

[Paul Harris]

2009/12/5 Yaroslav Halchenko <yoh at dartmouth.edu>

> Sorry for a delay...
>
> On Fri, 04 Dec 2009, Paul Harris wrote:
> >      since I had braking API I would have just kept count_within_range
> >      and created count_within_radius ;-)
> >    The reason to break the API is so that we automatically warn all users
> >    of the old _range() functions that it doesn't work in the way they
> >    probably imagine.
> Well... any sane user first checks what function does "for sure" ;)
> Thus, who knows, might be that most of users  might use it actually
> correctly
>
>
well, you didn't use it correctly, I know I didn't use it correctly (twice,
once when I first started using kdtree, and a year later after I forgot the
trick).

We get questions about it about once a month, and those are only questions
from people who were able to notice a problem.  If programmers don't have
unit tests or a type of problem which is easy to detect errors, then they
may never notice a problem.


> >    I'm thinking of a C++ solution.  To deprecate in Python will require
> >    Python magic (like you say above) that I'm not familiar with.  Willi
> nah... just static variable/flag to set upon first std::cerr <<
> "DeprecationWarning: ..." << std::endl;
> ;-)
>
>
Unfortunately that is useless for a normal Windows GUI-based program.
Windows programs will swallow/disable the cout/cerr/cin, something to do
with winmain and the fact that there is no console to write the messages out
to.   You can build a Console program in windows, but they are rare these
days.  Even python apps tend to have GUI interfaces, and those have the
console hidden/disabled.

>    the method entirely) so that users of the library are forced to check
> >    what broke, and so that we don't allow library users to release
> >    products that are doing things incorrectly.
> well... at least I see no Build-Depends on the library in Debian - so
> there might indeed be just a little hit.
>
>
That might indeed be a problem, but I don't know of any debian programs that
have Build-Depends on kdtree... how do I find that out?



>  >    Can we do this in Python?  Otherwise users may just upgrade
> (apt-get?)
> >    the library and not check for DeprecationWarning messages.   Well,
> they usually annoy me enough to change my code ;)
>
>
If you see the messages.  If the user is Grandma and all the messages go to
syslog, then we may go quite some time before someone notices that the app
needs to be changed.

I personally prefer a fail-fast scenario.  If its half broken, don't
continue to hobble along.  It helps to guarantee correctness, at the expense
of availablility.


 >    whatever the standard procedure for python is, will do, I'll let you
> >    guys figure out the best way.
> Well -- since I am a new "user" to the library -- I could not care less
> actually -- whatever solution you choose would be ok with me since I
> would not need to fix anything and Python wrapping hasn't yet hit Debian
> so regardless I would need to backport it whenever/if it does.
>
>
A good thing :)


> >    Well, the call to _box() functions would only happen once per call, so
> >    the slowness should be relatively minor as long as the tree is large
> >    enough to consume most of the execution time.
> >    If its a tiny tree, a linear search may end up being quicker anyway.
> In my usecases tree usually will be 5000-100000 points most of the time
> on regular grid (but I don't want to rely on that) and I would query
> 30-100 at a time ;)
>
>
Out of curiousity, do you mean you would do 30-100 individual queries?  Or
do you mean you call the query once and expect to receive 30-100 responses?

cheers
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/libkdtree-devel/attachments/20091205/f9886d0c/attachment-0001.htm>