Steven D'Aprano wrote:
# --- Untested ---
# Automatically call each __new__ constructor method, starting from
# the most fundamental (object) and ending with the current class.
stack = []
for c in cls.__mro__:
if hasattr(c, '__new__'):
stack.append(c.__new__)
while stack:
stack.po
On Monday, 3 February 2014, Chris Angelico wrote:
> On Tue, Feb 4, 2014 at 12:50 AM, Nicholas Cole
> >
> 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 refe
On Tue, Feb 4, 2014 at 12:50 AM, Nicholas Cole 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
On Mon, Feb 3, 2014 at 6:44 AM, Dennis Lee Bieber wrote:
> On Sun, 02 Feb 2014 18:40:59 -0500, Roy Smith 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 clear
On Mon, Feb 3, 2014 at 12:07 AM, Chris Angelico wrote:
> On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith 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
On 02/02/2014 09:12 PM, Roy Smith wrote:
In article ,
Dave Angel wrote:
Skip Montanaro Wrote in message:
On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel 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 answe
On Mon, Feb 3, 2014 at 4:12 PM, Roy Smith 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 0x02B52
In article ,
Dave Angel wrote:
> Skip Montanaro Wrote in message:
> > On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel 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
Skip Montanaro Wrote in message:
> On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel 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
On Sun, Feb 2, 2014 at 9:14 PM, Dave Angel 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
--
https://mail.python.org/mailman/listinfo/python-list
Roy Smith Wrote in message:
> In article ,
> Dave Angel wrote:
>
>> Chris Angelico 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.
>> >
On Sun, Feb 2, 2014 at 5:37 PM, Chris Angelico 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
On Mon, Feb 3, 2014 at 12:24 PM, Devin Jeanpierre
wrote:
> On Sun, Feb 2, 2014 at 4:07 PM, Chris Angelico wrote:
>> On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith wrote:
>>> I'm reasonably sure you posted this as humor, but there is some truth in
>>> what you said. In the crypto/security domain, yo
On Sun, Feb 2, 2014 at 4:07 PM, Chris Angelico wrote:
> On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith 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
In article ,
Dave Angel wrote:
> Chris Angelico 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 ke
On Mon, 03 Feb 2014 12:38:00 +1300, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> (In hindsight, it was probably a mistake for Python to define two
>> create- an-object methods, although I expect it was deemed necessary
>> for historical reasons.
>
> I'm not sure that all of the reasons are hi
Chris Angelico 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 some
On Mon, Feb 3, 2014 at 10:40 AM, Roy Smith 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
On 1 February 2014 14:42, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> On Fri, 31 Jan 2014 14:52:15 -0500, Ned Batchelder wrote:
>
> (In hindsight, it was probably a mistake for Python to define two create-
> an-object methods, although I expect it was deemed necessary for
> hi
In article ,
Chris Angelico 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 re
Steven D'Aprano wrote:
(In hindsight, it was probably a mistake for Python to define two create-
an-object methods, although I expect it was deemed necessary for
historical reasons.
I'm not sure that all of the reasons are historical. Languages
that have a single creation/initialisation method
In article ,
Gregory Ewing wrote:
> Generally I think it would be better to talk about "the
> __new__ method" and "the __init__ method", and not call
> either of them a constructor.
+1
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 3, 2014 at 10:15 AM, Gregory Ewing
wrote:
> Roy Smith wrote:
>>
>> In article <52ec84bc$0$29972$c3e8da3$54964...@news.astraweb.com>,
>> Steven D'Aprano wrote:
>>
>>> A dubious analogy, since there are artists who would say that attacking
>>> the canvas with a knife and setting the re
Mark Lawrence wrote:
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base class has an __init__()
method, the derived class’s __init__() method, if any, must explicitly
call it to ensure proper initialization of the base class part o
Roy Smith wrote:
In article <52ec84bc$0$29972$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano 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__(
Ned Batchelder writes:
> My summary of our two views is this: I am trying to look at things
> from a typical programmer's point of view.
Do you think the typical programmer will be looking in the language
reference? I don't.
> The existence of __new__ is an advanced topic that many programmers
On Sun, 02 Feb 2014 07:09:14 +1100, Tim Delaney wrote:
> On 1 February 2014 23:28, Ned Batchelder wrote:
>>
>> You are looking at things from an accurate-down-to-the-last-footnote
>> detailed point of view (and have provided some footnotes!). That's a
>> very valuable and important point of view
On 1 February 2014 23:28, Ned Batchelder wrote:
>
> You are looking at things from an accurate-down-to-the-last-footnote
> detailed point of view (and have provided some footnotes!). That's a very
> valuable and important point of view. It's just not how most programmers
> approach the language.
> On 01/02/2014 14:40, Roy Smith wrote:
> > In article ,
> > Ned Batchelder wrote:
> >
> >> The existence of __new__ is an
> >> advanced topic that many programmers never encounter. Taking a quick
> >> scan through some large projects (Django, edX, SQLAlchemy, mako), the
> >> ratio of __new__ i
On 01/02/2014 14:40, Roy Smith wrote:
In article ,
Ned Batchelder wrote:
The existence of __new__ is an
advanced topic that many programmers never encounter. Taking a quick
scan through some large projects (Django, edX, SQLAlchemy, mako), the
ratio of __new__ implementations to __init__ imp
In article ,
Ned Batchelder wrote:
> The existence of __new__ is an
> advanced topic that many programmers never encounter. Taking a quick
> scan through some large projects (Django, edX, SQLAlchemy, mako), the
> ratio of __new__ implementations to __init__ implementations ranges from
> 0%
On 1/31/14 10:42 PM, Steven D'Aprano wrote:
On Fri, 31 Jan 2014 14:52:15 -0500, Ned Batchelder wrote:
Why can't we call __init__ the constructor and __new__ the allocator?
__new__ constructs the object, and __init__ initialises it. What's wrong
with calling them the constructor and initialise
On 01/31/2014 09:51 PM, Steven D'Aprano wrote:
On Sat, 01 Feb 2014 15:35:17 +1100, Chris Angelico wrote:
The two methods could have been done as a single method, __construct__,
in which you get passed a cls instead of a self, and you call
self=super().__construct__() and then initialize stuff.
On Sat, 01 Feb 2014 15:05:34 +1100, Chris Angelico wrote:
> On Sat, Feb 1, 2014 at 1:52 PM, Steven D'Aprano
> wrote:
>> "Constructor" is three syllables; "ctor" isn't readily pronounceable in
>> English at all, rather like Cthulhu. (I can't think of any standard
>> English words with a "CT" in th
On Sat, 01 Feb 2014 15:35:17 +1100, Chris Angelico wrote:
> On Sat, Feb 1, 2014 at 2:42 PM, Steven D'Aprano
> wrote:
>> I've met people who have difficulty with OOP principles, at least at
>> first. But once you understand the idea of objects, it isn't that hard
>> to understand the idea that:
>>
On 01/31/2014 08:35 PM, Chris Angelico wrote:
On Sat, Feb 1, 2014 at 2:42 PM, Steven D'Aprano wrote:
Thus, two methods. __new__ constructs (creates, allocates) a new object;
__init__ initialises it after the event.
Yes, but if you think in terms of abstractions, they're both just
steps in the
On Sat, Feb 1, 2014 at 1:52 PM, Steven D'Aprano
wrote:
> "Constructor" is three syllables; "ctor" isn't readily pronounceable in
> English at all, rather like Cthulhu. (I can't think of any standard
> English words with a "CT" in them at all, let alone at the start of the
> word). The best I can c
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 parti
In article <52ec84bc$0$29972$c3e8da3$54964...@news.astraweb.com>,
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
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 du
On Sat, Feb 1, 2014 at 2:42 PM, Steven D'Aprano
wrote:
> I've met people who have difficulty with OOP principles, at least at
> first. But once you understand the idea of objects, it isn't that hard to
> understand the idea that:
>
> - first, the object has to be created, or constructed, or alloca
Not any direct comments on this... Just some thoughts around a couple
of questions
1. Declarative and Imperative Terminology
2. Is OOP declarative or imperative
1. Python is an imperative language. It does a good amount of
functional stuff. Are its terms neutral? Look at sort
sort -- imperativ
On 01/31/2014 06:28 PM, Terry Reedy wrote:
Construct a house:
Clear and grade house site.
Bring in power and water.
Built temporary structures.
Built foundation.
Built house on foundation.
For most classes, __new__ stops with the foundation -- the bare object object
(with the cl
On 01/31/2014 07:16 PM, Terry Reedy wrote:
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
On Fri, 31 Jan 2014 14:52:15 -0500, Ned Batchelder wrote:
> Why can't we call __init__ the constructor and __new__ the allocator?
__new__ constructs the object, and __init__ initialises it. What's wrong
with calling them the constructor and initialiser? Is this such a
difficult concept that the
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.
On 2014-02-01 02:52, Steven D'Aprano wrote:
On Fri, 31 Jan 2014 20:10:46 -0500, Roy Smith wrote:
In article ,
Ethan Furman wrote:
I found calling __init__ the constructor very confusing.
I've heard many people say this, and it's always sort of befuddled me.
In C++, a constructor is reall
On 1/31/14 9:28 PM, Terry Reedy wrote:
Most classes have __init__, only very very few have __new__.
*Every* class has .__new__. Mutable builtins and almost all user classes
inherit .__new__ from object. Every class also has .__init__, but it is
mainly inherited from object by immutable builtin
On Fri, 31 Jan 2014 20:10:46 -0500, Roy Smith wrote:
> In article ,
> Ethan Furman wrote:
>
>> I found calling __init__ the constructor very confusing.
>
> I've heard many people say this, and it's always sort of befuddled me.
>
> In C++, a constructor is really an initializer too. By the ti
On 1/31/2014 7:13 PM, Ethan Furman wrote:
On 01/31/2014 03:47 PM, Ben Finney wrote:
I would prefer it to be clear that “__init__” is called automatically,
*during* the constructor's operation. So, instead of:
Called when the instance is created.
I suggest:
Called automatically by t
Terry Reedy writes:
> User classes lacking .__init__ usually inherit it from something other
> than object. So objects are constructed by first calling .__new__ and
> then passing the result to .__init__. The Python 3 doc should say so.
That matches my understanding, and I agree the docs should
On 01/31/2014 05:10 PM, Roy Smith wrote:
In article ,
Ethan Furman wrote:
I found calling __init__ the constructor very confusing.
I've heard many people say this, and it's always sort of befuddled me.
I have never learned C++, so I don't know its screwy semantics. ;)
Nor Java, for tha
On 1/31/2014 3:41 PM, Ethan Furman wrote:
On 01/31/2014 11:52 AM, Ned Batchelder wrote:
On 1/31/14 2:33 PM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__
which states:-
"
Called when the instance is created. The arguments are those passed to
the c
Ben Finney writes:
> My apologies, you're right and that's made clear at
> .
And that's a URL to my local filesystem.
Clearly it's time for me to step away from the discussion for a while
:-)
--
\ “I went to the cinema, it said ‘Adults: $5.00, Children $2.50’. |
`\ So I said ‘
Ethan Furman writes:
> On 01/31/2014 03:47 PM, Ben Finney wrote:
> > I suggest:
> >
> > Called automatically by the constructor “__new__” during
> > instance creation, to initialise the new instance.
>
> But __new__ does not call __init__, type does [1].
My apologies, you're right and
In article ,
MRAB wrote:
> You could argue that construction is not complete until the instance
> has been initialised. In the case of C++, all you have is the
> initialiser, so doesn't really matter, but Python has __new__ and
> __init__, so it _does_ matter.
C++ has operator new (which you ca
On 2014-02-01 01:10, Roy Smith wrote:
In article ,
Ethan Furman wrote:
I found calling __init__ the constructor very confusing.
I've heard many people say this, and it's always sort of befuddled me.
In C++, a constructor is really an initializer too. By the time C++'s
Foo::Foo() or Pytho
In article ,
Ethan Furman wrote:
> I found calling __init__ the constructor very confusing.
I've heard many people say this, and it's always sort of befuddled me.
In C++, a constructor is really an initializer too. By the time C++'s
Foo::Foo() or Python's Foo.__init__() get called, memory ha
On 01/02/2014 00:13, 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. I
On 01/31/2014 03:47 PM, Ben Finney wrote:
I would prefer it to be clear that “__init__” is called automatically,
*during* the constructor's operation. So, instead of:
Called when the instance is created.
I suggest:
Called automatically by the constructor “__new__” during instance
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 constructo
Ned Batchelder writes:
> On 1/31/14 6:05 PM, Ben Finney wrote:
> > Here we disagree. I think the meaning “… and that returns the new
> > instance” is entailed in the meaning of “constructor”.
> > […]
>
> You say these terms already have meanings, and that constructor means
> a function that retur
Cameron Simpson writes:
> > On 01/31/2014 12:48 PM, MRAB wrote:
> > >The advantage of calling it the "initialiser" is that it explains
> > >why it's called "__init__".
>
> On this basis, would it suffice to change the opening sentence from:
> Called when the instance is created.
>
> to
> Call
On 1/31/14 6:05 PM, Ben Finney wrote:
Ned Batchelder writes:
On 1/31/14 2:33 PM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__
[…]
Should the wording of the above be changed to clearly reflect that
we have an initialiser here and that __new__ is
On 01Feb2014 10:05, Ben Finney wrote:
> Ned Batchelder writes:
> > Why can't we call __init__ the constructor and __new__ the allocator?
>
> Because those terms already have meanings, and “__new__” fits the
> meaning of “constructor” better.
+1 on not giving new conflicting meanings to terms al
Ned Batchelder writes:
> On 1/31/14 2:33 PM, Mark Lawrence wrote:
> > From http://docs.python.org/3/reference/datamodel.html#object.__init__
> > […]
> > Should the wording of the above be changed to clearly reflect that
> > we have an initialiser here and that __new__ is the constructor?
>
> I'm
On 31Jan2014 12:57, Ethan Furman wrote:
> On 01/31/2014 12:48 PM, MRAB wrote:
> >On 2014-01-31 19:52, Ned Batchelder wrote:
> >>Why can't we call __init__ the constructor and __new__ the allocator?
> >
> >The advantage of calling it the "initialiser" is that it explains why
> >it's called "__init_
On 1/31/14 3:57 PM, Ethan Furman wrote:
On 01/31/2014 12:48 PM, MRAB wrote:
On 2014-01-31 19:52, Ned Batchelder wrote:
Why can't we call __init__ the constructor and __new__ the allocator?
The advantage of calling it the "initialiser" is that it explains why
it's called "__init__".
Hm, yes
On 01/31/2014 12:48 PM, MRAB wrote:
On 2014-01-31 19:52, Ned Batchelder wrote:
Why can't we call __init__ the constructor and __new__ the allocator?
The advantage of calling it the "initialiser" is that it explains why
it's called "__init__".
Hm, yes, good point. Also, __init__ initializes
On 01/31/2014 11:52 AM, Ned Batchelder wrote:
On 1/31/14 2:33 PM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__
which states:-
"
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base clas
On 2014-01-31 19:52, Ned Batchelder wrote:
On 1/31/14 2:33 PM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__
which states:-
"
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base class h
On 01/31/2014 11:33 AM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__ which
states:-
"
Called when the instance is created. The arguments are those passed to the
class constructor expression. If a base class
has an __init__() method, the derived c
On Sat, Feb 1, 2014 at 7:17 AM, Mark Lawrence wrote:
> To clarify the situation I think we should call __new__ "the thing that
> instanciates an instance of a class" and __init__ "the thing that isn't
> actually needed as you can add attributes to an instance anywhere in your
> code" :)
With a ty
On 31/01/2014 19:52, Ned Batchelder wrote:
On 1/31/14 2:33 PM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__
which states:-
"
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base class h
On 1/31/14 2:33 PM, Mark Lawrence wrote:
From http://docs.python.org/3/reference/datamodel.html#object.__init__
which states:-
"
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base class has an __init__()
method, the derived class’s
From http://docs.python.org/3/reference/datamodel.html#object.__init__
which states:-
"
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base class has an __init__()
method, the derived class’s __init__() method, if any, must explici
76 matches
Mail list logo
