Fredrik Lundh wrote:
> "flupke" wrote:
>
>
>>>Then i got a tip that you can register a function that needs to be
>>>called when the object is going to be deleted.
>>>For instance to register a function __exit, you do this:
>
>
>>>class line:
>>>def __init__(s,glob,argl,color=''):
>>>
>
> do you (or whoever gave you the tip) have the slightest idea what atexit does?
>
Yeah, I got the tip on this group. researched and found it was
for when program ends!
I was trying to treat it like a destructor. darn.
--
http://mail.python.org/mailman/listinfo/python-list
"phil" <[EMAIL PROTECTED]> wrote:
>> Then i got a tip that you can register a function that needs to be
>> called when the object is going to be deleted.
>> For instance to register a function __exit, you do this:
>
> Here is the complete line class with your suggestion:
>
> Below is the output.
>
"flupke" wrote:
>> Then i got a tip that you can register a function that needs to be
>> called when the object is going to be deleted.
>> For instance to register a function __exit, you do this:
>> class line:
>> def __init__(s,glob,argl,color=''):
>> atexit.register(s.__exit)
> I d
phil wrote:
>
>> Then i got a tip that you can register a function that needs to be
>> called when the object is going to be deleted.
>> For instance to register a function __exit, you do this:
>>
>
>
> Here is the complete line class with your suggestion:
>
> Below is the output.
>
> Nice id
> Then i got a tip that you can register a function that needs to be
> called when the object is going to be deleted.
> For instance to register a function __exit, you do this:
>
Here is the complete line class with your suggestion:
Below is the output.
Nice idea, maybe I did something wrong
André Roberge wrote:
> Scott David Daniels wrote:
>
>> André Roberge wrote:
>>
>>> ... Each time I refresh the screen, I could
>>> force that call, then check to see if Evil has been
>>> destroyed by Python, which would give me the information
>>> I need to destroy Evil_twin behind the scene myse
Fredrik Lundh wrote:
> André Roberge wrote:
>>If I need to have the user call Evil.destroy() as Evil
>>is getting out of scope, it would miss the whole point
>>of teaching about the natural way scope and namespace
>>work.
>
>
> well, if you insist on using finalizers to keep track of what's in th
André Roberge wrote:
> If I need to have the user call Evil.destroy() as Evil
> is getting out of scope, it would miss the whole point
> of teaching about the natural way scope and namespace
> work.
well, if you insist on using finalizers to keep track of what's in the current
scope, I'd say that
=?ISO-8859-1?Q?Andr=E9_Roberge?= <[EMAIL PROTECTED]> wrote:
>If I need to have the user call Evil.destroy() as Evil
>is getting out of scope, it would miss the whole point
>of teaching about the natural way scope and namespace
>work.
The problem, it seems to me, is that in Python "scope" applies
phil wrote:
> I'm probably dense and don't quite get the point, even though I
> have coded about 200,000 lines of Python and coded .5 million lines of
> C before there was a C++
>
> A class instance based language doesn't have to BE C++ to have a
> destructor method.
Very true. But meaningful fin
phil wrote:
> A class instance based language doesn't have to BE C++ to have a
> destructor method.
>
> All I wanted to know is: is the apparent treatment of __del__
> which SEEMS to work fine for me in 2.3.4 deprecated or mangled
> in some later release or future plans.
> If someone doesn't kno
stasz wrote:
> On Mon, 09 May 2005 22:49:06 -0300, André Roberge wrote:
>
>
>>Scott David Daniels wrote:
>>
>>>André Roberge wrote:
>>>
>>>
... Each time I refresh the screen, I could
force that call, then check to see if Evil has been
destroyed by Python, which would give me the inf
On Mon, 09 May 2005 22:49:06 -0300, André Roberge wrote:
> Scott David Daniels wrote:
>> André Roberge wrote:
>>
>>>... Each time I refresh the screen, I could
>>>force that call, then check to see if Evil has been
>>>destroyed by Python, which would give me the information
>>>I need to destroy
"phil" wrote:
> If someone doesn't know the answer to this question or if noone
> knows the answer to this question
there is no answer to your question. Python works as specified in
the language specification, and the language specification makes
no guarantees. changes in the CPython interpreter
Scott David Daniels wrote:
> André Roberge wrote:
>
>>... Each time I refresh the screen, I could
>>force that call, then check to see if Evil has been
>>destroyed by Python, which would give me the information
>>I need to destroy Evil_twin behind the scene myself -
>>which is what I am really af
>
> Fredrik Lundh wrote:
>
>>Python is not C++.
>>
Praise the Lord.
>>
>
> I dunno if this makes QOTW, but I vote we put this in our list text that
> goes out with each and every list message.
>
> There will still be a lot of people who don't read it, but at least
> we'll get to say, "We t
phil <[EMAIL PROTECTED]> writes:
> By the way, I understand that __del__ is only called when the last
> reference to an instance is deled. That's fine, if consistent.
Actually, __del__ is called when the instance is garbage
collected. Exactly when that is is implementation dependent. In the
impl
Hi All--
Fredrik Lundh wrote:
>
> Python is not C++.
>
I dunno if this makes QOTW, but I vote we put this in our list text that
goes out with each and every list message.
There will still be a lot of people who don't read it, but at least
we'll get to say, "We told you so."
-ly y'rs,
Ivan;-)
André Roberge wrote:
> ... Each time I refresh the screen, I could
> force that call, then check to see if Evil has been
> destroyed by Python, which would give me the information
> I need to destroy Evil_twin behind the scene myself -
> which is what I am really after.
What might work is to keep
Fredrik Lundh wrote:
> André Roberge wrote:
>
>
>
>>This morning I had the following thought:
>>I can, when I create a Jekyll object, update
>>an outside_list.
>>If, somehow, I could update that list when
>>a Jekyll object disappears
>>(perhaps by using __del__, which I have never touched)
>
>
"phil" wrote:
> > Python makes no guarantees whatsover about when and how to
> > run __del__, so relying on it to remove user-visible resources is a
> > rather bad idea.
> What does that mean? Is it a destructor or not?
it's a finalizer.
most Python implementations do a reasonable attempt to c
André Roberge wrote:
> This morning I had the following thought:
> I can, when I create a Jekyll object, update
> an outside_list.
> If, somehow, I could update that list when
> a Jekyll object disappears
> (perhaps by using __del__, which I have never touched)
Python makes no guarantees whatsov
Suppose I have two classes: 'Jekyll' and 'Hyde' that are
related in a particular way.
When I create a Jekyll object, a Hyde one gets automatically
created (and displayed on a screen).
drum roll to announce Python script ===
Nice = Jekyll()# Nice_twin, a Hyde object, gets created.
Nice.
24 matches
Mail list logo
