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 1 of 2  [1] 2  Next page →

#65175 — Re: __init__ is the initialiser

On 1/31/2014 7:13 PM, Ethan Furman wrote:
> On 01/31/2014 03:43 PM, Ned Batchelder wrote:
>> On 1/31/14 6:05 PM, Ben Finney wrote:
>>> Ned Batchelder writes:
>>
>> I'm not hoping to change any official terminology. I just think that
>> calling __init__ anything other than a constructor
>> is confusing pedantry.  It is a constructor, and Python constructors
>> work differently than those in C++ and Java.
>
> And I would say the opposite.  __init__ is not creating anything,

As you pointed out in a different response, Python has one default, 
two-phase constructor. type.__call__. Typically, .__new__ allocates a 
generic object (with one customization as to class). .__init__ creates, 
from that mostly generic object, a customized instance of class C with 
the minimal attributes needed to be an instance of C, with value 
specific to the instance.

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?

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#65182

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



-- 
Steven

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

#65183

In article <52ec84bc$0$29972$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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 :-)

That's __del__()

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

#65292

Roy Smith wrote:
> In article <52ec84bc$0$29972$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>>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 :-)
> 
> That's __del__()

But it only works if the canvas is not referenced
anywhere in any art catalogues. Otherwise the
canvas fails to catch fire, and gets put on a
list of list of artworks to be considered for
manual incineration.

-- 
Greg

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

#65294

On Mon, Feb 3, 2014 at 10:15 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Roy Smith wrote:
>>
>> In article <52ec84bc$0$29972$c3e8da3$5496439d@news.astraweb.com>,
>>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>>
>>> 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 :-)
>>
>>
>> That's __del__()
>
>
> But it only works if the canvas is not referenced
> anywhere in any art catalogues. Otherwise the
> canvas fails to catch fire, and gets put on a
> list of list of artworks to be considered for
> manual incineration.

What you see here is proof that Python really does need an explicit
destroy() function. It would need to recycle the object [1], forcing
all references to it to dangle:

>>> a = object()
>>> b = a
>>> destroy(a)
>>> c = b

Traceback (most recent call last):
  File "<pyshell#89>", line 1, in <module>
    c = b
SegmentationError: dereferencing a dangling pointer

It's a serious lack in Python. Currently it's not possible to do this
without fiddling around in ctypes.

ChrisA

[1] Scrub the RAM clean and return it to the computer, put the 1 bits
onto the stack for subsequent reuse, and throw all the useless 0 bits
out onto the heap.

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

#65297

In article <mailman.6313.1391383680.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> What you see here is proof that Python really does need an explicit
> destroy() function. It would need to recycle the object [1], forcing
> all references to it to dangle:
> 
> >>> a = object()
> >>> b = a
> >>> destroy(a)
> >>> c = b
> 
> Traceback (most recent call last):
>   File "<pyshell#89>", line 1, in <module>
>     c = b
> SegmentationError: dereferencing a dangling pointer
> 
> It's a serious lack in Python. Currently it's not possible to do this
> without fiddling around in ctypes.
> 
> ChrisA
> 
> [1] Scrub the RAM clean and return it to the computer, put the 1 bits
> onto the stack for subsequent reuse, and throw all the useless 0 bits
> out onto the heap.

I'm reasonably sure you posted this as humor, but there is some truth in 
what you said.  In the crypto/security domain, you often want to keep a 
key or cleartext around only for the time it's needed, and scrub the 
memory it was occupying as soon as it is no longer in use.

I don't know how you would do that in Python.

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

#65300

On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith <roy@panix.com> wrote:
> I'm reasonably sure you posted this as humor, but there is some truth in
> what you said.  In the crypto/security domain, you often want to keep a
> key or cleartext around only for the time it's needed, and scrub the
> memory it was occupying as soon as it is no longer in use.
>
> I don't know how you would do that in Python.

I did, but you're right.

It's fundamentally not possible in pure Python, because there's no way
to flag a block of memory as "do not page this to disk". For what
you're talking about to be at all possible, you would need support
from the language, from the OS, and possibly from the CPU as well. I'm
sure this sort of thing exists, but if it does, it'll probably be
something that Python itself wouldn't concern itself with - you'd get
it via openssl or something.

There have been occasional times I've wanted an "explicit destruction"
feature. Rather than the facetious exception I listed above, it'd be
better to have all those references (including the original one in a,
since there's nothing special about that) turn into some kind of "null
state" - either None, or a special object that marks itself as a
destructed/destroyed (terminology debates aside) object. With custom
types, I can mark them off with a special flag, and check that all the
time; but I can't, for instance, have a dict that maps some lookup
keyword to its output file, and then destroy output files to remove
all their references from everywhere in the dict. (I have had
something along these lines, a bit more complicated than this, but not
in Python.)

But I do like the idea of an arsonist being unable to destroy a
painting because of the reference loop between its catalog number on
the back and the catalog itself.

ChrisA

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

#65308

On Sun, Feb 2, 2014 at 4:07 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith <roy@panix.com> wrote:
>> I'm reasonably sure you posted this as humor, but there is some truth in
>> what you said.  In the crypto/security domain, you often want to keep a
>> key or cleartext around only for the time it's needed, and scrub the
>> memory it was occupying as soon as it is no longer in use.
>>
>> I don't know how you would do that in Python.
>
> I did, but you're right.
>
> It's fundamentally not possible in pure Python, because there's no way
> to flag a block of memory as "do not page this to disk". For what
> you're talking about to be at all possible, you would need support
> from the language, from the OS,

mlock on linux, VirtualAlloc (?) on windows. This can be done in
CPython after the fact, but you'd want the memory to be unpageable
before it has contents put in it, not after.

Destroying memory is comparatively easy, as you say -- just make the
object's internal state "invalid", rather than adding anything to the
language.

-- Devin

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

#65309

On Mon, Feb 3, 2014 at 12:24 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Sun, Feb 2, 2014 at 4:07 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith <roy@panix.com> wrote:
>>> I'm reasonably sure you posted this as humor, but there is some truth in
>>> what you said.  In the crypto/security domain, you often want to keep a
>>> key or cleartext around only for the time it's needed, and scrub the
>>> memory it was occupying as soon as it is no longer in use.
>>>
>>> I don't know how you would do that in Python.
>>
>> I did, but you're right.
>>
>> It's fundamentally not possible in pure Python, because there's no way
>> to flag a block of memory as "do not page this to disk". For what
>> you're talking about to be at all possible, you would need support
>> from the language, from the OS,
>
> mlock on linux, VirtualAlloc (?) on windows. This can be done in
> CPython after the fact, but you'd want the memory to be unpageable
> before it has contents put in it, not after.

Yeah, like I said it needs language and OS support. There's no way to
call those APIs from pure Python code. (And I'm not sure whether those
functions work without appropriate CPU-level support; for instance,
what happens if your OS is running inside a VM?)

> Destroying memory is comparatively easy, as you say -- just make the
> object's internal state "invalid", rather than adding anything to the
> language.

Yeah. Works fine if you have a cooperative system that checks that
state every time; otherwise, it'd need at least some language support
(the goal is to have its destructor called and all its references
wiped, so resources get released).

ChrisA

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

#65311

On Sun, Feb 2, 2014 at 5:37 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Mon, Feb 3, 2014 at 12:24 PM, Devin Jeanpierre
>> Destroying memory is comparatively easy, as you say -- just make the
>> object's internal state "invalid", rather than adding anything to the
>> language.
>
> Yeah. Works fine if you have a cooperative system that checks that
> state every time; otherwise, it'd need at least some language support
> (the goal is to have its destructor called and all its references
> wiped, so resources get released).

I guess my point is that I don't see what you need on top of extension
modules. Same for previous paragraph.

-- Devin

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

#65332

On Sun, 02 Feb 2014 18:40:59 -0500, Roy Smith <roy@panix.com> declaimed the
following:

>I'm reasonably sure you posted this as humor, but there is some truth in 
>what you said.  In the crypto/security domain, you often want to keep a 
>key or cleartext around only for the time it's needed, and scrub the 
>memory it was occupying as soon as it is no longer in use.
>
>I don't know how you would do that in Python.

	Don't store it as text... Use a numeric array of byte values, which can
then be run through a clearing procedure (overwrite with random values,
overwrite with ones complement of same random values, overwrite with new
random values).

	Python may be caching the individual byte values, but the are unlikely
to be in any sequence indicative of a key.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#65334

On Mon, Feb 3, 2014 at 12:07 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith <roy@panix.com> wrote:
>> I'm reasonably sure you posted this as humor, but there is some truth in
>> what you said.  In the crypto/security domain, you often want to keep a
>> key or cleartext around only for the time it's needed, and scrub the
>> memory it was occupying as soon as it is no longer in use.
>>
>> I don't know how you would do that in Python.
>
> I did, but you're right.
>
> It's fundamentally not possible in pure Python, because there's no way
> to flag a block of memory as "do not page this to disk". For what
> you're talking about to be at all possible, you would need support
> from the language, from the OS, and possibly from the CPU as well. I'm
> sure this sort of thing exists, but if it does, it'll probably be
> something that Python itself wouldn't concern itself with - you'd get
> it via openssl or something.
>
> There have been occasional times I've wanted an "explicit destruction"
> feature. Rather than the facetious exception I listed above, it'd be
> better to have all those references (including the original one in a,
> since there's nothing special about that) turn into some kind of "null
> state" - either None, or a special object that marks itself as a
> destructed/destroyed (terminology debates aside) object. With custom
> types, I can mark them off with a special flag, and check that all the
> time; but I can't, for instance, have a dict that maps some lookup
> keyword to its output file, and then destroy output files to remove
> all their references from everywhere in the dict. (I have had
> something along these lines, a bit more complicated than this, but not
> in Python.)

Can't you get close to that using weakrefs?  I'll admit that care is required.

N.

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

#65350

On Mon, Feb 3, 2014 at 6:44 AM, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Sun, 02 Feb 2014 18:40:59 -0500, Roy Smith <roy@panix.com> declaimed the
> following:
>
>>I'm reasonably sure you posted this as humor, but there is some truth in
>>what you said.  In the crypto/security domain, you often want to keep a
>>key or cleartext around only for the time it's needed, and scrub the
>>memory it was occupying as soon as it is no longer in use.
>>
>>I don't know how you would do that in Python.
>
>         Don't store it as text... Use a numeric array of byte values, which can
> then be run through a clearing procedure (overwrite with random values,
> overwrite with ones complement of same random values, overwrite with new
> random values).
>
>         Python may be caching the individual byte values, but the are unlikely
> to be in any sequence indicative of a key.

If Python interns the byte objects though, won't overwriting them lead
to subtle bugs later on as Python attempts to reuse them?  They may
even be reused already from earlier byte objects with the same values,
that may or may not still have references.

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

#65352

On Tue, Feb 4, 2014 at 12:50 AM, Nicholas Cole <nicholas.cole@gmail.com> wrote:
>> There have been occasional times I've wanted an "explicit destruction"
>> feature. Rather than the facetious exception I listed above, it'd be
>> better to have all those references (including the original one in a,
>> since there's nothing special about that) turn into some kind of "null
>> state" - either None, or a special object that marks itself as a
>> destructed/destroyed (terminology debates aside) object. With custom
>> types, I can mark them off with a special flag, and check that all the
>> time; but I can't, for instance, have a dict that maps some lookup
>> keyword to its output file, and then destroy output files to remove
>> all their references from everywhere in the dict. (I have had
>> something along these lines, a bit more complicated than this, but not
>> in Python.)
>
> Can't you get close to that using weakrefs?  I'll admit that care is required.

Weakrefs are a related tool, but solving a different problem. What I
wanted here was an easy way to force all references to a particular
file to be wiped out, based on one of the existing references. Here's
a concocted setup that's broadly similar to what I was doing, which
might illustrate the issue:

log_files = {}

def add_log_file(fn, *keywords):
    f = open(fn, "w")
    for kw in keywords: log_files[kw]=f

for line in process_me_line_generator():
    kw = line.split()[0]
    f = log_files.get(kw)
    if not f: continue
    f.write(line+"\n")
    if 'quit' in line:
        # Okay, let's now close this file.
        destruct(f)


In this particular case, I could use "f.close()" and "if not f or
f.closed: continue", but that requires that the object cooperate in
this way, and I'm not entirely sure about resource usage. (I was
actually working with a database connection object, IIRC, which didn't
offer me a way to inquire if it was still open or not.) To do this
with weak refs, I'd have to have some other source of strong refs, and
closing would be done by digging through that list, disposing of it
from there, and then triggering garbage collection. I suppose it could
be made to work, but it feels like going about everything backwards.

ChrisA

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

#65375

[Multipart message — attachments visible in raw view] — view raw

On Monday, 3 February 2014, Chris Angelico <rosuav@gmail.com> wrote:

> On Tue, Feb 4, 2014 at 12:50 AM, Nicholas Cole <nicholas.cole@gmail.com<javascript:;>>
> wrote:
> >> There have been occasional times I've wanted an "explicit destruction"
> >> feature. Rather than the facetious exception I listed above, it'd be
> >> better to have all those references (including the original one in a,
> >> since there's nothing special about that) turn into some kind of "null
> >> state" - either None, or a special object that marks itself as a
> >> destructed/destroyed (terminology debates aside) object. With custom
> >> types, I can mark them off with a special flag, and check that all the
> >> time; but I can't, for instance, have a dict that maps some lookup
> >> keyword to its output file, and then destroy output files to remove
> >> all their references from everywhere in the dict. (I have had
> >> something along these lines, a bit more complicated than this, but not
> >> in Python.)
> >
> > Can't you get close to that using weakrefs?  I'll admit that care is
> required.
>
> Weakrefs are a related tool, but solving a different problem. What I
> wanted here was an easy way to force all references to a particular
> file to be wiped out, based on one of the existing references. Here's
> a concocted setup that's broadly similar to what I was doing, which
> might illustrate the issue:
>
> log_files = {}
>
> def add_log_file(fn, *keywords):
>     f = open(fn, "w")
>     for kw in keywords: log_files[kw]=f
>
> for line in process_me_line_generator():
>     kw = line.split()[0]
>     f = log_files.get(kw)
>     if not f: continue
>     f.write(line+"\n")
>     if 'quit' in line:
>         # Okay, let's now close this file.
>         destruct(f)
>
>
> In this particular case, I could use "f.close()" and "if not f or
> f.closed: continue", but that requires that the object cooperate in
> this way, and I'm not entirely sure about resource usage. (I was
> actually working with a database connection object, IIRC, which didn't
> offer me a way to inquire if it was still open or not.) To do this
> with weak refs, I'd have to have some other source of strong refs, and
> closing would be done by digging through that list, disposing of it
> from there, and then triggering garbage collection. I suppose it could
> be made to work, but it feels like going about everything backwards.
>
> ChrisA
>

When I have had similar problems, I've wrapped the 'strong' reference to
the thing I might need to destroy inside an object, and had the 'destroy'
method delete it.

I'll admit that it isn't quite as convenient as having something that would
work for arbitrary objects at arbitrary moments, but it works almost
exactly as you describe for the file object above, and it can be quite neat
and tidy.

Best wishes,

N.

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

#65393

On Mon, 3 Feb 2014 10:44:21 -0700, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following:

>
>If Python interns the byte objects though, won't overwriting them lead
>to subtle bugs later on as Python attempts to reuse them?  They may
>even be reused already from earlier byte objects with the same values,
>that may or may not still have references.

	I suspect Python won't intern the /array/ of bytes; just the references
to the individual values -- and overwriting will change the references to
different interned values. I doubt the interning of the individual values
will appear in the order of the initial key -- and even if they did, any
duplicate bytes in the initial key would start by referencing the first
occurrence, while the randomization process would pick other interned
location.

>>> import array
>>> key = array.array("i", [1, 2, 3, 1, 3, 4])
>>> key
array('i', [1, 2, 3, 1, 3, 4])
>>> for i in key:
... 	print id(i)
... 	
3029624
3029600
3029576
3029624
3029576
3029552
>>> for i in range(len(key)):
... 	key[i] = key[i] * 3 - 2	#imagine this is a random production
... 	
>>> for i in key:
... 	print id(i)
... 
3029624
3029552
3029480
3029624
3029480
3029408
>>> key
array('i', [1, 4, 7, 1, 7, 10])
>>> 

	Interesting: the IDs for 1, 2, 3, 4 -- if memory addresses -- are in
descending address order. And that continues through the replacement
values.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#65301

 Chris Angelico <rosuav@gmail.com> Wrote in message:
> 
> 
> [1] Scrub the RAM clean and return it to the computer, put the 1 bits
> onto the stack for subsequent reuse, and throw all the useless 0 bits
> out onto the heap.
> 

But don't you realize,  we have to keep the zero bits around,  so
 the one bits have someone to feel superior to. 

-- 
DaveA

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

#65303

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

>  Chris Angelico <rosuav@gmail.com> Wrote in message:
> > 
> > 
> > [1] Scrub the RAM clean and return it to the computer, put the 1 bits
> > onto the stack for subsequent reuse, and throw all the useless 0 bits
> > out onto the heap.
> > 
> 
> But don't you realize,  we have to keep the zero bits around,  so
>  the one bits have someone to feel superior to.

Just wait until the two bits start showing up.  Then let's how the one 
bits feel, huh?

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

#65316

 Roy Smith <roy@panix.com> Wrote in message:
> In article <mailman.6316.1391387539.18130.python-list@python.org>,
>  Dave Angel <davea@davea.name> wrote:
> 
>>  Chris Angelico <rosuav@gmail.com> Wrote in message:
>> > 
>> > 
>> > [1] Scrub the RAM clean and return it to the computer, put the 1 bits
>> > onto the stack for subsequent reuse, and throw all the useless 0 bits
>> > out onto the heap.
>> > 
>> 
>> But don't you realize,  we have to keep the zero bits around,  so
>>  the one bits have someone to feel superior to.
> 
> Just wait until the two bits start showing up.  Then let's how the one 
> bits feel, huh?
> 

And when the q-bits get entangled up,  we won't know the question
 till after the answer has collapsed. 

-- 
DaveA

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

#65317

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?

Skip

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web