headers
Sebastian Haase | 1 Feb 2007 04:39
Picon

usage of __del__ in python classes

Hi,
Before I start I want to admit that I don't understand much about
this. I just saw that the memmap class defines __del__ and that I had
problems in the past when I added a 'def __del__' to a class of mine.
So here is a quote, I would like to know if this is "standard
knowledge" on this list or not.

    # I found the info originally here: http://arctrix.com/nas/python/gc/
    # Circular references which are garbage are detected when the
optional cycle detector is enabled (it's on by default), but can only
be cleaned up if there are no Python-level __del__() methods involved.
Refer to the documentation for the 'gc' module for more information
about how __del__() methods are handled by the cycle detector,
particularly the description of the garbage value. Notice: [warning]
Due to the precarious circumstances under which __del__() methods are
invoked, exceptions that occur during their execution are ignored, and
a warning is printed to sys.stderr instead. Also, when __del__() is
invoked in response to a module being deleted (e.g., when execution of
the program is done), other globals referenced by the __del__() method
may already have been deleted. For this reason, __del__() methods
should do the absolute minimum needed to maintain external invariants.

Cheers,
Sebastian Haase
Permalink | Reply | 1 comment |
headers
David Cournapeau | 1 Feb 2007 05:04
Picon
Picon

Re: usage of __del__ in python classes

Sebastian Haase wrote:
> Hi,
> Before I start I want to admit that I don't understand much about
> this. I just saw that the memmap class defines __del__ and that I had
> problems in the past when I added a 'def __del__' to a class of mine.
> So here is a quote, I would like to know if this is "standard
> knowledge" on this list or not.
>
>     # I found the info originally here: http://arctrix.com/nas/python/gc/
>     # Circular references which are garbage are detected when the
> optional cycle detector is enabled (it's on by default), but can only
> be cleaned up if there are no Python-level __del__() methods involved.
> Refer to the documentation for the 'gc' module for more information
> about how __del__() methods are handled by the cycle detector,
> particularly the description of the garbage value. Notice: [warning]
> Due to the precarious circumstances under which __del__() methods are
> invoked, exceptions that occur during their execution are ignored, and
> a warning is printed to sys.stderr instead. Also, when __del__() is
> invoked in response to a module being deleted (e.g., when execution of
> the program is done), other globals referenced by the __del__() method
> may already have been deleted. For this reason, __del__() methods
> should do the absolute minimum needed to maintain external invariants.
>
>
This is particularly annoying when using ctypes, and you need to clean 
some ressources. I had this problem with pyaudiolab:

Class A
def __init__(self):
# here call C library open
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 1 Feb 2007 07:03
Picon
Gravatar

Re: [SciPy-user] What it the best way to install on a Mac?

On 1/31/07, Sanjiv Das <srdas <at> scu.edu> wrote:
> OK - will give that a shot as well. Its a good suggestion!
> cheers

Great.  And it looks like the bulk of that work has already been done
for you, as I found out today thanks to the good and trusty Google
Alerts service:

http://mohinish.blogspot.com/2007/01/python-for-matlab-users-on-mac.html

Feel free to open up a page on the ipython wiki:

http://ipython.scipy.org/moin

Just make a login for yourself and type away!

Cheers,

f
Permalink | Reply | 1 comment |
headers
Fernando Perez | 1 Feb 2007 07:05
Picon
Gravatar

Re: [SciPy-user] What it the best way to install on a Mac?

On 1/31/07, Fernando Perez <fperez.net <at> gmail.com> wrote:
> On 1/31/07, Sanjiv Das <srdas <at> scu.edu> wrote:
> > OK - will give that a shot as well. Its a good suggestion!
> > cheers

And I should add: thanks!  Recent discussions on this list indicate
there's a real need for this information, so a complete and step by
step summary of this info in a purely tutorial manner may well help
many.

Having it in a publicly editable format will ensure it can stay up to
date as the problem evolves.

Cheers,

f
Permalink | Reply | 0 comments |
headers
Zachary Pincus | 1 Feb 2007 09:28
Picon
Favicon

array copy-to-self and views

Hello folks,

I recently was trying to write code to modify an array in-place (so  
as not to invalidate any references to that array) via the standard  
python idiom for lists, e.g.:

a[:] = numpy.flipud(a)

Now, flipud returns a view on 'a', so assigning that to 'a[:]'  
provides pretty strange results as the buffer that is being read (the  
view) is simultaneously modified. Here is an example:

In [2]: a = numpy.arange(10).reshape((5,2))
In [3]: a
Out[3]:
array([[0, 1],
        [2, 3],
        [4, 5],
        [6, 7],
        [8, 9]])
In [4]: numpy.flipud(a)
Out[4]:
array([[8, 9],
        [6, 7],
        [4, 5],
        [2, 3],
        [0, 1]])
In [5]: a[:] = numpy.flipud(a)
In [6]: a
Out[6]:
(Continue reading)

Permalink | Reply | 11 comments |
headers
Anne Archibald | 1 Feb 2007 10:07
Picon
Gravatar

Re: array copy-to-self and views

On 01/02/07, Zachary Pincus <zpincus <at> stanford.edu> wrote:

> I recently was trying to write code to modify an array in-place (so
> as not to invalidate any references to that array) via the standard
> python idiom for lists, e.g.:

You can do this, but if your concern is invalidating references, you
might want to think about rearranging your application so you can just
return "new" arrays (that may share elements), if that is possible.

> a[:] = numpy.flipud(a)
>
> Now, flipud returns a view on 'a', so assigning that to 'a[:]'
> provides pretty strange results as the buffer that is being read (the
> view) is simultaneously modified. Here is an example:

> A question, then: Does this represent a bug? Or perhaps there is a
> better idiom for modifying an array in-place than 'a[:] = ...'? Or is
> incumbent on the user to ensure that any time an array is directly
> modified, that the modifying array is not a view of the original array?

It's the user's job to keep them separate. Sorry. If you're worried -
say if it's an array you don't have much control over (so it might
share elements without you knowing), you can either return a new
array, or if you must modify it in place, copy the right-hand side
before using it (a[:]=flipud(a).copy()).

It would in principle be possible for numpy to provide a function that
tells you if two arrays might share data (simply compare the pointer
to the malloc()ed storage and ignore strides and offset; a bit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Emsellem | 1 Feb 2007 13:24
Picon

problem with installation of numpy: undefined symbols

Hi,

after trying to solve an installation problem with scipy, I had to
reinstall everything from scratch, and so I now turned back to numpy the
installation of which does not work for me (which may in fact explain
the pb I had with scipy).

To be clear on what I do:

- I install blas first, and create a libfblas.a which I copy under
/usr/local/lib
(using a g77 -fno-second-underscore -O2 -c *.f, ar r libfblas.a *.o,
ranlib libfblas.a)

- I then define BLAS environment variable accordingly
(/usr/local/lib/libfblas.a)
- I compile lapack-3.1.0, using "make lapacklib"
- I then use a precompiled ATLAS Linux version P4SSE2 (I tried compiling
it but it does have the same result)
- I copy all ATLAS .a and .h in /usr/local/lib/atlas, and define the
ATLAS variable accordingly
- I then merge the  *.o to have an extended liblapack.a by doing the usual:
         cd /usr/local/lib/atlas
         cp liblapack.a liblapack.a_ATLAS
         mkdir tmp
         cd tmp
         ar x ../liblapack.a_ATLAS
         cp
/soft/python/tar/Science_Packages/lapack-3.1.0/lapack_LINUX.a ../liblapack.a
         ar r ../liblapack.a *.o
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Kern | 1 Feb 2007 17:08
Picon
Gravatar

Re: problem with installation of numpy: undefined symbols

Eric Emsellem wrote:

> - I finally get the svn version of numpy, and do the "python setup.py
> install" (no site.cfg ! but environment variables defined as mentioned
> above)

Show us the output of

  $ cd ~/src/numpy  # or whereever
  $ python setup.py config

Most likely, you are having the same problem you had with scipy. You will
probably need to make a site.cfg with the correct information about ATLAS.

--

-- 
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
Permalink | Reply | 0 comments |
headers
Christopher Barker | 1 Feb 2007 18:38
Picon
Favicon

Re: array copy-to-self and views

Zachary Pincus wrote:
> Hello folks,
> 
> I recently was trying to write code to modify an array in-place (so  
> as not to invalidate any references to that array)

I'm not sure what this means exactly.

> via the standard  
> python idiom for lists, e.g.:
> 
> a[:] = numpy.flipud(a)
> 
> Now, flipud returns a view on 'a', so assigning that to 'a[:]'  
> provides pretty strange results as the buffer that is being read (the  
> view) is simultaneously modified.

yes, weird. So why not just:

a = numpy.flipud(a)

Since flipud returns a view, the new "a" will still be using the same 
data array. Does this satisfy your need above?

You've created a new numpy array object, but that was created by flipud 
anyway, so there is no performance loss.

It's too bad that to do this you need to know that flipud created a 
view, rather than a copy of the data, as if it were a copy, you would 
need to do the a[:] trick to make sure a kept the same data, but that's
(Continue reading)

Permalink | Reply | 3 comments |
headers
Zachary Pincus | 1 Feb 2007 19:52
Picon
Favicon

Re: array copy-to-self and views

> Zachary Pincus wrote:
>> Hello folks,
>>
>> I recently was trying to write code to modify an array in-place (so
>> as not to invalidate any references to that array)
>
> I'm not sure what this means exactly.

Say one wants to keep two different variables referencing a single in- 
memory list, as so:
a = [1,2,3]
b = a
Now, if 'b' and 'a' go to live in different places (different class  
instances or whatever) but we want 'b' and 'a' to always refer to the  
same in-memory object, so that 'id(a) == id(b)', we need to make sure  
to not assign a brand new list to either one.

That is, if we do something like 'a = [i + 1 for i in a]' then 'id 
(a) != id(b)'. However, we can do 'a[:] = [i + 1 for i in a]' to  
modify a in-place. This is not super-common, but it's also not an  
uncommon python idiom.

I was in my email simply pointing out that naïvely translating that  
idiom to the numpy case can cause unexpected behavior in the case of  
views.

I think that this is is unquestionably a bug -- isn't the point of  
views that the user shouldn't need to care if a particular array  
object is a view or not? Given the lack of methods to query whether  
an array is a view, or what it might be a view on, this seems like a
(Continue reading)

Permalink | Reply | 2 comments |

Gmane