Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #65175 > unrolled thread

Re: __init__ is the initialiser

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: __init__ is the initialiser Terry Reedy <tjreedy@udel.edu> - 2014-01-31 22:16 -0500
    Re: __init__ is the initialiser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-01 05:23 +0000
      Re: __init__ is the initialiser Roy Smith <roy@panix.com> - 2014-02-01 00:25 -0500
        Re: __init__ is the initialiser Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-03 12:15 +1300
          Re: __init__ is the initialiser Chris Angelico <rosuav@gmail.com> - 2014-02-03 10:27 +1100
            Re: __init__ is the initialiser Roy Smith <roy@panix.com> - 2014-02-02 18:40 -0500
              Re: __init__ is the initialiser Chris Angelico <rosuav@gmail.com> - 2014-02-03 11:07 +1100
              Re: __init__ is the initialiser Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-02-02 17:24 -0800
              Re: __init__ is the initialiser Chris Angelico <rosuav@gmail.com> - 2014-02-03 12:37 +1100
              Re: __init__ is the initialiser Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-02-02 17:54 -0800
              Re: __init__ is the initialiser Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-03 08:44 -0500
              Re: __init__ is the initialiser Nicholas Cole <nicholas.cole@gmail.com> - 2014-02-03 13:50 +0000
              Re: __init__ is the initialiser Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-03 10:44 -0700
              Re: __init__ is the initialiser Chris Angelico <rosuav@gmail.com> - 2014-02-04 04:57 +1100
              Re: __init__ is the initialiser Nicholas Cole <nicholas.cole@gmail.com> - 2014-02-03 19:57 +0000
              Re: __init__ is the initialiser Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-03 19:38 -0500
          Re: __init__ is the initialiser Dave Angel <davea@davea.name> - 2014-02-02 19:35 -0500
            Re: __init__ is the initialiser Roy Smith <roy@panix.com> - 2014-02-02 19:45 -0500
              Re: __init__ is the initialiser Dave Angel <davea@davea.name> - 2014-02-02 22:14 -0500
              Re: __init__ is the initialiser Skip Montanaro <skip@pobox.com> - 2014-02-02 21:15 -0600
              Re: __init__ is the initialiser Dave Angel <davea@davea.name> - 2014-02-03 00:06 -0500
                Re: __init__ is the initialiser Roy Smith <roy@panix.com> - 2014-02-03 00:12 -0500
                  Re: __init__ is the initialiser Chris Angelico <rosuav@gmail.com> - 2014-02-03 16:49 +1100
                  Re: __init__ is the initialiser Ethan Furman <ethan@stoneleaf.us> - 2014-02-02 21:34 -0800
      Re: __init__ is the initialiser Rustom Mody <rustompmody@gmail.com> - 2014-01-31 21:31 -0800

Page 2 of 2 — ← Prev page 1 [2]

#65319

 Skip Montanaro <skip@pobox.com> Wrote in message:
> On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel <davea@davea.name> wrote:
>> And when the q-bits get entangled up,  we won't know the question
>> till after the answer has collapsed.
> 
> Won't looking at the answer change it?
> 

No, looking at it is what collapses it. Before that it was just
 another Schroedinger's cat

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#65320

In article <mailman.6325.1391403799.18130.python-list@python.org>,
 Dave Angel <davea@davea.name> wrote:

>  Skip Montanaro <skip@pobox.com> Wrote in message:
> > On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel <davea@davea.name> wrote:
> >> And when the q-bits get entangled up,  we won't know the question
> >> till after the answer has collapsed.
> > 
> > Won't looking at the answer change it?
> > 
> 
> No, looking at it is what collapses it. Before that it was just
>  another Schroedinger's cat

So, what you're saying is when I delete an object, __del__() has both 
been called and not been called?

[toc] | [prev] | [next] | [standalone]

#65321

On Mon, Feb 3, 2014 at 4:12 PM, Roy Smith <roy@panix.com> wrote:
> So, what you're saying is when I delete an object, __del__() has both
> been called and not been called?

>>> class Schrodinger:
    def __init__(self):
        print("Init!")

>>> print(Schrodinger())
Init!
<__main__.Schrodinger object at 0x02B52570>

At this point, __del__ has indeed both been called and not been
called. However, observing its state will force it to collapse:

>>> class Schrodinger:
    def __init__(self):
        print("Init!")
    def __del__(self):
        print("Del!")

>>> print(Schrodinger())
Init!
<__main__.Schrodinger object at 0x02B52830>
Del!

If an object falls off the heap and there's no __del__ method to hear
it, does it call __del__?

ChrisA

[toc] | [prev] | [next] | [standalone]

#65322

On 02/02/2014 09:12 PM, Roy Smith wrote:
> In article <mailman.6325.1391403799.18130.python-list@python.org>,
>   Dave Angel <davea@davea.name> wrote:
>
>>   Skip Montanaro <skip@pobox.com> Wrote in message:
>>> On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel <davea@davea.name> wrote:
>>>> And when the q-bits get entangled up,  we won't know the question
>>>> till after the answer has collapsed.
>>>
>>> Won't looking at the answer change it?
>>>
>>
>> No, looking at it is what collapses it. Before that it was just
>>   another Schroedinger's cat
>
> So, what you're saying is when I delete an object, __del__() has both
> been called and not been called?

That would certainly explain the problems with __del__!

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#65184

On Saturday, February 1, 2014 10:53:08 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 31 Jan 2014 22:16:59 -0500, Terry Reedy wrote:

> > Creating a painting on canvas has two similar phases. Prepare a generic
> > blank canvas stretched on a frame and coated with a white undercoat.
> > Paint a particular picture. Would you say that the second step is not
> > creating anything?

> A dubious analogy, since there are artists who would say that attacking 
> the canvas with a knife and setting the remains on fire count as a form 
> of artistic creation :-)

> "Creation" can mean various things in English. One might argue that the 
> only creation was the guy at the factory who made the canvas, and the 
> people who made the paints. After that comes the preparation stage, 
> followed by the splashing-paint-on-canvas stage.

> If you want to use "creating" to refer to the splashing-paint stage, then 
> I think the closest analogy in Python is the stuff which happens *after* 
> __init__ is called. Using a class often means modifying it as you go (in 
> much the same way that using a canvas requires modifying it as you go), 
> and it's never *completely* prepared until just before you stop using it. 
> One adds data, modifies the data, moves data from one attribute to 
> another, sets up temporary data attributes, calls methods which modify 
> the instance, and finally get the final answer you want, at which point 
> your task is done and the instance is thrown away. Think of a dict:

> d = {}  # Dict is constructed.
> for key in data:
>     key = process(key)
>     if condition():
>         d[key] = something(key)

> Is all that work also not part of the object construction process? If we 
> write it like this:

> d = dict(something(key) for key in map(process, data) if condition())

> you'd probably call it the constructor. But the two bits of code do the 
> same thing.

> While we talk about a constructor as if the process of constructing an 
> object was black and white with a clear and obvious dividing line, in 
> practice its often fuzzy, with a lot of grey. (That's one of the 
> objections the functional crowd has with mutable objects.)

> So to answer your question: no, in context of programming, I would *not* 
> call the putting-paint-to-canvas stage of artist painting to be 
> "creation". I would call it *using* the constructed object (the canvas). 
> Whether that *use* of the canvas happens to be *artistic* creation or 
> mere derivative pap is another story :-)


http://en.wikipedia.org/wiki/Four_causes

[Replace cause by create(ion) ]

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web