[Numpy-discussion] Recarray attributes writeable
Hi everyone -
Recarrays have convenience attributes such that
fields may be accessed through . in additioin to
the field() method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
tr.field('ra')[:] = 0.0
tr.ra
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tr.ra = 3
tr.ra
3
tr.field('ra')
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
I feel this should raise an exception, just as with trying to write
to the size attribute. Any thoughts?
Erin
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Recarray attributes writeable
El dv 16 de 06 del 2006 a les 14:46 -0700, en/na Andrew Straw va
escriure:
Erin Sheldon wrote:
Anyway - Recarrays have convenience attributes such that
fields may be accessed through . in additioin to
the field() method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
tr.field('ra')[:] = 0.0
tr.ra
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tr.ra = 3
tr.ra
3
tr.field('ra')
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
I feel this should raise an exception, just as with trying to write
to the size attribute. Any thoughts?
I have not used recarrays much, so take this with the appropriate
measure of salt.
I'd prefer to drop the entire pseudo-attribute thing completely before
it gets entrenched. (Perhaps it's too late.)
However, I think that this has its utility, specially when accessing to
nested fields (see later). In addition, I'd suggest introducing a
special accessor called, say, 'fields' in order to access the fields
themselves and not the attributes. For example, if you want to access
the 'strides' attribute, you can do it in the usual way:
import numpy
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,strides')
tr.strides
(20,)
but, if you want to access *field* 'strides' you could do it by issuing:
tr.fields.strides
repr of field accessor object (shape, type...)
tr.fields.strides[:]
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
We have several advantages in adopting the previous approach:
1. You don't mix (nor pollute) the namespaces for attributes and fields.
2. You have a clear idea when you are accessing a variable or a field.
3. Accessing nested columns would still be very easy:
tr.field('nested1').field('nested2').field('nested3') vs
tr.fields.nested1.nested2.nested3
4. You can also define a proper __getitem__ for accessing fields:
tr.fields['nested1']['nested2']['nested3'].
In the same way, elements of 'nested2' field could be accessed by:
tr.fields['nested1']['nested2'][2:10:2].
5. Finally, you can even prevent setting or deleting columns by
disabling the __setattr__ and __delattr__.
PyTables has adopted a similar schema for accessing nested columns,
except for 4, where we decided not to accept both strings and slices for
the __getitem__() method (you know the mantra: there should preferably
be just one way of doing things, although maybe we've been a bit too
much strict in this case), and I think it works reasonably well. In any
case, the idea is to decouple the attributes and fields so that they
doesn't get mixed.
Implementing this shouldn't be complicated at all, but I'm afraid that I
can't do this right now :-(
--
0,0 Francesc Altet http://www.carabos.com/
V V Cárabos Coop. V. Enjoy Data
-
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Recarray attributes writeable
On 6/17/06, Francesc Altet [EMAIL PROTECTED] wrote: However, I think that this has its utility, specially when accessing to nested fields (see later). In addition, I'd suggest introducing a special accessor called, say, 'fields' in order to access the fields themselves and not the attributes. For example, if you want to access the 'strides' attribute, you can do it in the usual way: import numpy tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,strides') tr.strides (20,) but, if you want to access *field* 'strides' you could do it by issuing: tr.fields.strides repr of field accessor object (shape, type...) tr.fields.strides[:] array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.]) [...] +1 I meant to write exactly the same thing, but was too lazy to do it :) Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Recarray attributes writeable
This reply sent 9:36 AM, Jun 17 (because it may not show up
for a day or so from my gmail account, if it shows up at all)
On 6/17/06, Francesc Altet [EMAIL PROTECTED] wrote:
El dv 16 de 06 del 2006 a les 14:46 -0700, en/na Andrew Straw va
escriure:
Erin Sheldon wrote:
Anyway - Recarrays have convenience attributes such that
fields may be accessed through . in additioin to
the field() method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
tr.field('ra')[:] = 0.0
tr.ra
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tr.ra = 3
tr.ra
3
tr.field('ra')
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
I feel this should raise an exception, just as with trying to write
to the size attribute. Any thoughts?
I have not used recarrays much, so take this with the appropriate
measure of salt.
I'd prefer to drop the entire pseudo-attribute thing completely before
it gets entrenched. (Perhaps it's too late.)
I think that initially I would concur to drop them. I am new to numpy,
however, so they are not entrenched for me. Anyway, see below.
However, I think that this has its utility, specially when accessing to
nested fields (see later). In addition, I'd suggest introducing a
special accessor called, say, 'fields' in order to access the fields
themselves and not the attributes. For example, if you want to access
the 'strides' attribute, you can do it in the usual way:
import numpy
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,strides')
tr.strides
(20,)
but, if you want to access *field* 'strides' you could do it by issuing:
tr.fields.strides
repr of field accessor object (shape, type...)
tr.fields.strides[:]
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
We have several advantages in adopting the previous approach:
1. You don't mix (nor pollute) the namespaces for attributes and fields.
2. You have a clear idea when you are accessing a variable or a field.
3. Accessing nested columns would still be very easy:
tr.field('nested1').field('nested2').field('nested3') vs
tr.fields.nested1.nested2.nested3
4. You can also define a proper __getitem__ for accessing fields:
tr.fields['nested1']['nested2']['nested3'].
In the same way, elements of 'nested2' field could be accessed by:
tr.fields['nested1']['nested2'][2:10:2].
5. Finally, you can even prevent setting or deleting columns by
disabling the __setattr__ and __delattr__.
This is interesting, and I would add a 6th to this:
6. The .fields by itself could return the names of the fields, which are
currently not accessible in any simple way. I always think that these
should be methods (.fields(),.size(), etc) but if we are going down
the attribute route, this might be a simple fix.
PyTables has adopted a similar schema for accessing nested columns,
except for 4, where we decided not to accept both strings and slices for
the __getitem__() method (you know the mantra: there should preferably
be just one way of doing things, although maybe we've been a bit too
much strict in this case), and I think it works reasonably well. In any
case, the idea is to decouple the attributes and fields so that they
doesn't get mixed.
Strings or fieldnum access greatly improves the scriptability, but this
can always be done through the .field() access.
Erin
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] Recarray attributes writeable
Hi everyone -
(this is my fourth try in the last 24 hours to post this.
Apparently, the gmail smtp server is in the blacklist!!
this is bad).
Anyway - Recarrays have convenience attributes such that
fields may be accessed through . in additioin to
the field() method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
tr.field('ra')[:] = 0.0
tr.ra
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tr.ra = 3
tr.ra
3
tr.field('ra')
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
I feel this should raise an exception, just as with trying to write
to the size attribute. Any thoughts?
Erin
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] Recarray attributes writeable (3rd try)
Hi everyone -
(this is my third try in the last 24 hours to post this.
For some reason it hasn't been making it through)
Recarrays have convenience attributes such that
fields may be accessed through . in additioin to
the field() method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
tr.field('ra')[:] = 0.0
tr.ra
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tr.ra = 3
tr.ra
3
tr.field('ra')
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
I feel this should raise an exception, just as with trying to write
to the size attribute. Any thoughts?
Erin
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Recarray attributes writeable
Erin Sheldon wrote: Hi everyone - (this is my fourth try in the last 24 hours to post this. Apparently, the gmail smtp server is in the blacklist!! this is bad). I doubt it since that's where my email goes through. Sourceforge is frequently slow, so please have patience if your mail does not show up. I can see your 3rd try now. Possibly the others will be showing up, too. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Recarray attributes writeable
Erin Sheldon wrote:
Anyway - Recarrays have convenience attributes such that
fields may be accessed through . in additioin to
the field() method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
tr.field('ra')[:] = 0.0
tr.ra
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tr.ra = 3
tr.ra
3
tr.field('ra')
array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
I feel this should raise an exception, just as with trying to write
to the size attribute. Any thoughts?
I have not used recarrays much, so take this with the appropriate
measure of salt.
I'd prefer to drop the entire pseudo-attribute thing completely before
it gets entrenched. (Perhaps it's too late.)
I've used a similar system in pytables which, although it is convenient
in the short term and for interactive use, there are corner cases that
result in long term headaches. I think you point out one such issue for
recarrays. There will be more. For example:
In [1]:import numpy
In [2]:tr=numpy.recarray(10, formats='i4,f8,f8', names='id,ra,dec')
In [3]:tr.field('ra')[:] = 0.0
In [4]:tr.ra
Out[4]:array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
In [5]:del tr.ra
---
exceptions.AttributeErrorTraceback (most
recent call last)
/home/astraw/console
AttributeError: 'recarray' object has no attribute 'ra'
The above seems completely counterintuitive -- an attribute error for
something I just accessed? Yes, I know what's going on, but it certainly
makes life more confusing than it need be, IMO.
Another issue is that it is possible to have field names that are not
valid Python identifier strings.
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Recarray attributes writeable
The initial bounces actually say, and I quote: Technical details of temporary failure: TEMP_FAILURE: SMTP Error (state 8): 550-rejected because your SMTP server, 66.249.92.170, is in the Spamcop RBL. 550 See http://www.spamcop.net/bl.shtml for more information. On 6/16/06, Robert Kern [EMAIL PROTECTED] wrote: Erin Sheldon wrote: Hi everyone - (this is my fourth try in the last 24 hours to post this. Apparently, the gmail smtp server is in the blacklist!! this is bad). I doubt it since that's where my email goes through. Sourceforge is frequently slow, so please have patience if your mail does not show up. I can see your 3rd try now. Possibly the others will be showing up, too. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
