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 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
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=
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
>
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 )
[...
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
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
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"?
>
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
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 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
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
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
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/
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
[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
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
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
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
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
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
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
22 matches
Mail list logo