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

2012-08-16 Thread Ethan Furman
MRAB wrote: On 16/08/2012 17:13, Ethan Furman wrote: Currently there are: .index(data) --> returns index of data in Index, or raises error .query(string) --> brute force search, returns all matching records .search(match) --> binary search through table, returns all matching

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

2012-08-16 Thread MRAB
On 16/08/2012 17:13, Ethan Furman wrote: MRAB wrote: On 16/08/2012 02:22, Ethan Furman wrote: Steven D'Aprano wrote: On Wed, 15 Aug 2012 16:26:09 -0700, Ethan Furman wrote: Indexes have a new method (rebirth of an old one, really): .index_search( match, start=None, stop

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

2012-08-16 Thread Ethan Furman
MRAB wrote: On 16/08/2012 02:22, Ethan Furman wrote: Steven D'Aprano wrote: On Wed, 15 Aug 2012 16:26:09 -0700, Ethan Furman wrote: Indexes have a new method (rebirth of an old one, really): .index_search( match, start=None, stop=None, nearest=False, partial=

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

2012-08-16 Thread Hans Mulder
On 16/08/12 01:26:09, Ethan Furman wrote: > Indexes have a new method (rebirth of an old one, really): > > .index_search( > match, > start=None, > stop=None, > nearest=False, > partial=False ) > > The defaults are to search the entire index for exact matches and raise >

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

2012-08-15 Thread MRAB
On 16/08/2012 02:22, Ethan Furman wrote: Steven D'Aprano wrote: On Wed, 15 Aug 2012 16:26:09 -0700, Ethan Furman wrote: Indexes have a new method (rebirth of an old one, really): .index_search( match, start=None, stop=None, nearest=False, partial=False ) [...

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

2012-08-15 Thread MRAB
On 16/08/2012 01:28, Tim Chase wrote: On 08/15/12 19:21, Ethan Furman wrote: 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? Ah, well that's s

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

2012-08-15 Thread Ethan Furman
Steven D'Aprano wrote: On Wed, 15 Aug 2012 16:26:09 -0700, Ethan Furman wrote: Indexes have a new method (rebirth of an old one, really): .index_search( match, start=None, stop=None, nearest=False, partial=False ) [...] Why "index_search" rather than just "se

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

2012-08-15 Thread Steven D'Aprano
On Wed, 15 Aug 2012 16:26:09 -0700, Ethan Furman wrote: > Indexes have a new method (rebirth of an old one, really): > >.index_search( > match, > start=None, > stop=None, > nearest=False, > partial=False ) [...] Why "index_search" rather than just "search"? >

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

2012-08-15 Thread Tim Chase
On 08/15/12 19:21, Ethan Furman wrote: > 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? Ah, well that's somewhat clearer. Return the

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

2012-08-15 Thread Ethan Furman
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

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

2012-08-15 Thread Tim Chase
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 i

dbf.py API question concerning Index.index_search()

2012-08-15 Thread Ethan Furman
Indexes have a new method (rebirth of an old one, really): .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. match is the search

Re: dbf.py API question

2012-08-08 Thread Ole Martin Bjørndalen
On Wed, Aug 8, 2012 at 5:18 PM, Ethan Furman wrote: > Ed Leafe wrote: >> When converting from paradigms in other languages, I've often been >> tempted to follow the accepted pattern for that language, and I've almost >> always regretted it. > +1 >> When in doubt, make it as Pythoni

Re: dbf.py API question

2012-08-08 Thread Ethan Furman
Ed Leafe wrote: When converting from paradigms in other languages, I've often been tempted to follow the accepted pattern for that language, and I've almost always regretted it. +1 When in doubt, make it as Pythonic as possible. +1 QOTW ~Ethan~ -- http://mail.python.org/

Re: dbf.py API question

2012-08-07 Thread Ed Leafe
On Aug 2, 2012, at 10:55 AM, Ethan Furman wrote: > SQLite has a neat feature where if you give it a the file-name of ':memory:' > the resulting table is in memory and not on disk. I thought it was a cool > feature, but expanded it slightly: any name surrounded by colons results in > an in-memo

Re: dbf.py API question

2012-08-06 Thread Ethan Furman
[redirecting back to list] Ole Martin Bjørndalen wrote: On Sun, Aug 5, 2012 at 4:09 PM, Ethan Furman wrote: Ole Martin Bjørndalen wrote: You can do this by implementing either __getitem__ or __iter__, unless the streaming flag would also make your table not in memory. Cool! Wow! I realize n

Re: dbf.py API question

2012-08-05 Thread Ethan Furman
Ole Martin Bjørndalen wrote: On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman wrote: SQLite has a neat feature where if you give it a the file-name of ':memory:' the resulting table is in memory and not on disk. I thought it was a cool feature, but expanded it slightly: any name surrounded by colo

Re: dbf.py API question

2012-08-04 Thread Ole Martin Bjørndalen
On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman wrote: > SQLite has a neat feature where if you give it a the file-name of ':memory:' > the resulting table is in memory and not on disk. I thought it was a cool > feature, but expanded it slightly: any name surrounded by colons results in > an in-memo

Re: dbf.py API question

2012-08-03 Thread Tim Chase
On 08/03/12 08:11, Ethan Furman wrote: > So far all feedback is for the flag, so that's what I'll do. I agree with the flag, though would also be reasonably content with using None for the filename to indicate in-memory rather than on-disk storage. -tkc -- http://mail.python.org/mailman/list

Re: dbf.py API question

2012-08-03 Thread Ethan Furman
Peter Otten wrote: Ethan Furman wrote: SQLite has a neat feature where if you give it a the file-name of ':memory:' the resulting table is in memory and not on disk. I thought it was a cool feature, but expanded it slightly: any name surrounded by colons results in an in-memory table. I'm loo

Re: dbf.py API question

2012-08-03 Thread Peter Otten
Ethan Furman wrote: > SQLite has a neat feature where if you give it a the file-name of > ':memory:' the resulting table is in memory and not on disk. I thought > it was a cool feature, but expanded it slightly: any name surrounded by > colons results in an in-memory table. > > I'm looking at th

dbf.py API question

2012-08-02 Thread Ethan Furman
SQLite has a neat feature where if you give it a the file-name of ':memory:' the resulting table is in memory and not on disk. I thought it was a cool feature, but expanded it slightly: any name surrounded by colons results in an in-memory table. I'm looking at the same type of situation with