Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #27124 > unrolled thread

Re: dbf.py API question concerning Index.index_search()

Started byEthan Furman <ethan@stoneleaf.us>
First post2012-08-15 17:21 -0700
Last post2012-08-15 17:21 -0700
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: dbf.py API question concerning Index.index_search() Ethan Furman <ethan@stoneleaf.us> - 2012-08-15 17:21 -0700

#27124 — Re: dbf.py API question concerning Index.index_search()

FromEthan Furman <ethan@stoneleaf.us>
Date2012-08-15 17:21 -0700
SubjectRe: dbf.py API question concerning Index.index_search()
Message-ID<mailman.3333.1345075905.4697.python-list@python.org>
Tim Chase wrote:
> On 08/15/12 18:26, Ethan Furman wrote:
>>    .index_search(
>>       match,
>>       start=None,
>>       stop=None,
>>       nearest=False,
>>       partial=False )
>>
>> The defaults are to search the entire index for exact matches and raise
>> NotFoundError if it can't find anything.
>>
>> The question is what should the return value be?
>>
>> I don't like the usual pattern of -1 meaning not found (as in
>> 'nothere'.find('a')), so I thought a fun and interesting way would be to
>> subclass long and override the __nonzero__ method to return True/False
>> based on whether the (partial) match was found.  The main problems I see
>> here is that the special return value reverts to a normal int/long if
>> anything is done to it (adding, subtracting, etc), and the found status
>> is lost.
>>
>> The other option is returning a (number, bool) tuple -- safer, yet more
>> boring... ;)
> 
> I'm not quite sure I follow...you start off by saying that it will
> "raise NotFoundError" if it can't find anything.  So if it finds
> something, just return it.  Because if it found the item, it gives
> it to you; if it didn't find the item, it raised an error.  That
> sounds like a good (easy to understand) interface, similar to how
> string.index() works.


Indeed, it's even less clear without the part you snipped.  ;)  Which 
wasn't very.

The well-hidden clue was this line:

nearest returns where the match should be instead of raising an error

And my question should have been:

   What should the return value be when nearest == True?

My bit of fun was this class:

   class IndexLocation(long):
     """used by Index.index_search -- represents the index where the
        match criteria is if True, or would be if False"""
     def __new__(cls, value, found):
       "value is the number, found is True/False"
       result = long.__new__(cls, value)
       result.found = found
       return result
     def __nonzero__(self):
       return self.found

~Ethan~

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web