Re: [Numpy-discussion] Recarray attributes writeable

2006-06-17 Thread Erin Sheldon
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
> 
> >>> 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


Re: [Numpy-discussion] Recarray attributes writeable

2006-06-17 Thread Fernando Perez
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
> 
> >>> 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

2006-06-17 Thread Francesc Altet
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

>>> 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

2006-06-16 Thread Erin Sheldon
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


Re: [Numpy-discussion] Recarray attributes writeable

2006-06-16 Thread Andrew Straw
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/

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

2006-06-16 Thread Robert Kern
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