2010/8/17, Vineet Jain :
> Looking at the source code, it seems that the row object returned back
> from pytables will always try and look up the key as name and then
> revert to an index by int. If I get a numpy array back and use it in
> cython code then I can index (not database index) some_nump
Looking at the source code, it seems that the row object returned back
from pytables will always try and look up the key as name and then
revert to an index by int. If I get a numpy array back and use it in
cython code then I can index (not database index) some_numpy_array[i]
would be translated to
2010/8/16, Vineet Jain :
> Is it possible to just get numpy arrays back from a query, so that
> when I index then in cython code I can get indexing at c speed?
You can get numpy structured arrays out of a query by using the
`Table.readWhere()` method. But I'm not sure about the second part of
you
Is it possible to just get numpy arrays back from a query, so that
when I index then in cython code I can get indexing at c speed?
Vineet
On Mon, Aug 16, 2010 at 7:24 AM, Francesc Alted wrote:
> 2010/8/15, Vineet Jain :
>> While looking at the code I noticed the function:
>>
>> tables.tableExte
2010/8/15, Vineet Jain :
> While looking at the code I noticed the function:
>
> tables.tableExtension.getNestedFieldCache
>
> does a try except block on every row lookup like row[0], row[1]. Is
> that not going to be rather slow?
In general, a ``try: except` ` block is faster than a `hasattr` or
While looking at the code I noticed the function:
tables.tableExtension.getNestedFieldCache
does a try except block on every row lookup like row[0], row[1]. Is
that not going to be rather slow?
Vineet
On Sun, Aug 15, 2010 at 10:53 AM, Vineet Jain wrote:
> Ok found the problem. I was doing a r
Ok found the problem. I was doing a raise in my application and
somehow the try except block was printing the last know exception
which was a pytables exception.
Vineet
On Sun, Aug 15, 2010 at 10:36 AM, Vineet Jain wrote:
> Another exception:
>
> File "lrucacheExtension.pyx", line 590, in tabl
Another exception:
File "lrucacheExtension.pyx", line 590, in tables.lrucacheExtension.getslot_
KeyError: 3518L
What is strange is that I've looked at the code of pytables in both
the instances it is surrounded by try except KeyError blocks. So don't
understand how I can get these exception? Th
I'm getting the following error:
File "tableExtension.pyx", line 126, in
tables.tableExtension.getNestedFieldCache
KeyError: 2
And the exception stack is not showing the correct place where it is
getting called. Any idea on why the exception stack is not correct.
Also is it possible to find o
El dc 19 de 08 del 2009 a les 14:38 -0400, en/na Manning, Jonathan va
escriure:
> In testing other code, I stumbled across an exception when a user sets
> PYTABLES_SYS_ATTR=False from openFile.
FYI, I've just added (r4236) support for not propagating system
attributes during copies with ptrepack
El dc 19 de 08 del 2009 a les 14:38 -0400, en/na Manning, Jonathan va
escriure:
> In testing other code, I stumbled across an exception when a user sets
> PYTABLES_SYS_ATTR=False from openFile.
>
> The following patch is one way to fix it (silences the exception), but I'm
> not sure I like the b
In testing other code, I stumbled across an exception when a user sets
PYTABLES_SYS_ATTR=False from openFile.
The following patch is one way to fix it (silences the exception), but I'm not
sure I like the behavior still. The error comes from a few lines below, where
it tries to set FILTERS any
12 matches
Mail list logo
