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
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
Robert Kern 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.
And of course that's utterly bogus since I usually use GMane. Apologies. However, *this* is a real email to numpy-discussion. -- 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
Is it possible that gmail mails get through when they are sent by *l ists.sourceforge.net *while they are blocked when the outgoing server is gmail.com ? My situation is that I can't post a new discussion to the list, although replies seem to get through. David 2006/6/16, Robert Kern <robert.kern@gmail.com>:
Robert Kern 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.
And of course that's utterly bogus since I usually use GMane. Apologies.
However, *this* is a real email to numpy-discussion.
-- 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
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 <robert.kern@gmail.com> 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
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.AttributeError Traceback (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.
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 "-"
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 <faltet@carabos.com> 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
On 6/17/06, Francesc Altet <faltet@carabos.com> 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
participants (7)
-
Andrew Straw -
David Huard -
Erin Sheldon -
Erin Sheldon -
Fernando Perez -
Francesc Altet -
Robert Kern