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
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,
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,
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
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
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
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
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?
The question
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
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
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 )
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~
--
On Wed, Aug 8, 2012 at 5:18 PM, Ethan Furman et...@stoneleaf.us 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
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-memory
[redirecting back to list]
Ole Martin Bjørndalen wrote:
On Sun, Aug 5, 2012 at 4:09 PM, Ethan Furman et...@stoneleaf.us 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.
Ole Martin Bjørndalen wrote:
On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman et...@stoneleaf.us 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
On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman et...@stoneleaf.us 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
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 the
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
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
--
20 matches
Mail list logo
