<br><br><div class="gmail_quote">2009/12/5 Yaroslav Halchenko <span dir="ltr">&lt;<a href="mailto:yoh@dartmouth.edu">yoh@dartmouth.edu</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

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&#39;t have unit tests or a type of problem which is easy to detect errors, then they may never notice a problem.<br>

 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
&gt;    I&#39;m thinking of a C++ solution.  To deprecate in Python will require<br>
&gt;    Python magic (like you say above) that I&#39;m not familiar with.  Willi<br>
</div>nah... just static variable/flag to set upon first std::cerr &lt;&lt;<br>
&quot;DeprecationWarning: ...&quot; &lt;&lt; std::endl;<br>
;-)<br>
<div class="im"><br></div></blockquote><div><br>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.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
&gt;    the method entirely) so that users of the library are forced to check<br>
&gt;    what broke, and so that we don&#39;t allow library users to release<br>
&gt;    products that are doing things incorrectly.<br>
</div>well... at least I see no Build-Depends on the library in Debian - so<br>
there might indeed be just a little hit.<br>
<div class="im"><br></div></blockquote><div><br>That might indeed be a problem, but I don&#39;t know of any debian programs that have Build-Depends on kdtree... how do I find that out?<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">
&gt;    Can we do this in Python?  Otherwise users may just upgrade (apt-get?)<br>
&gt;    the library and not check for DeprecationWarning messages.   Well,<br>
</div>they usually annoy me enough to change my code ;)<br>
<div class="im"><br></div></blockquote><div><br>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.<br>

<br>I personally prefer a fail-fast scenario.  If its half broken, don&#39;t continue to hobble along.  It helps to guarantee correctness, at the expense of availablility.<br> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">
&gt;    whatever the standard procedure for python is, will do, I&#39;ll let you<br>
&gt;    guys figure out the best way.<br>
</div>Well -- since I am a new &quot;user&quot; to the library -- I could not care less<br>
actually -- whatever solution you choose would be ok with me since I<br>
would not need to fix anything and Python wrapping hasn&#39;t yet hit Debian<br>
so regardless I would need to backport it whenever/if it does.<br>
<div class="im"><br></div></blockquote><div><br>A good thing :)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
&gt;    Well, the call to _box() functions would only happen once per call, so<br>
&gt;    the slowness should be relatively minor as long as the tree is large<br>
&gt;    enough to consume most of the execution time.<br>
&gt;    If its a tiny tree, a linear search may end up being quicker anyway.<br>
</div>In my usecases tree usually will be 5000-100000 points most of the time<br>
on regular grid (but I don&#39;t want to rely on that) and I would query<br>
30-100 at a time ;)<br><br></blockquote><div><br>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?<br></div></div><br>cheers<br>

Paul<br><br>