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

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

Basic misunderstanding on object creation

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

Contents

  Basic misunderstanding on object creation andrew cooke <andrew@acooke.org> - 2015-05-13 06:25 -0700
    Re: Basic misunderstanding on object creation Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2015-05-13 16:24 +0200
      Re: Basic misunderstanding on object creation andrew cooke <andrew@acooke.org> - 2015-05-13 07:42 -0700
        Re: Basic misunderstanding on object creation andrew cooke <andrew@acooke.org> - 2015-05-13 07:45 -0700
          Re: Basic misunderstanding on object creation Peter Otten <__peter__@web.de> - 2015-05-13 16:55 +0200
          Re: Basic misunderstanding on object creation Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-13 08:55 -0600
            Re: Basic misunderstanding on object creation andrew cooke <andrew@acooke.org> - 2015-05-13 08:52 -0700
        Re: Basic misunderstanding on object creation Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-13 08:54 -0600
    Re: Basic misunderstanding on object creation Terry Reedy <tjreedy@udel.edu> - 2015-05-13 12:36 -0400
      Re: Basic misunderstanding on object creation andrew cooke <andrew@acooke.org> - 2015-05-13 11:42 -0700
        Re: Basic misunderstanding on object creation Terry Reedy <tjreedy@udel.edu> - 2015-05-13 15:17 -0400
        Re: Basic misunderstanding on object creation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-13 20:45 +0100
          Re: Basic misunderstanding on object creation Ned Batchelder <ned@nedbatchelder.com> - 2015-05-13 13:33 -0700
            Re: Basic misunderstanding on object creation Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-14 11:07 +1000
    Re: Basic misunderstanding on object creation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-13 17:38 +0100
    Re: Basic misunderstanding on object creation Terry Reedy <tjreedy@udel.edu> - 2015-05-13 13:05 -0400
    Re: Basic misunderstanding on object creation Terry Reedy <tjreedy@udel.edu> - 2015-05-13 13:13 -0400
    Re: Basic misunderstanding on object creation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-13 18:43 +0100

#90546 — Basic misunderstanding on object creation

Hi,

The following code worked on Python 3.2, but no longer works in 3.4.  Did something change, or have I always been doing something dumb?

(I realise the code is pointless as is - it's the simplest example I can give of a problem I am seeing with more complex code).

>>> class Foo:
...     def __new__(cls, *args, **kargs):
...         print('new', args, kargs)
...         super().__new__(cls, *args, **kargs)
... 
>>> class Bar(Foo):
...     def __init__(self, a):
...         print('init', a)
... 
>>> Bar(1)
new (1,) {}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __new__
TypeError: object() takes no parameters

What I was expecting to happen (and what happens in 3.2) is that the object.__new__ method passes the argument to the __init__ of the subclass.

Any help appreciated.

Thanks,
Andrew

[toc] | [next] | [standalone]

#90554

Am 13.05.2015 um 15:25 schrieb andrew cooke:

>>>> class Foo:
> ...     def __new__(cls, *args, **kargs):
> ...         print('new', args, kargs)
> ...         super().__new__(cls, *args, **kargs)

> new (1,) {}
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "<stdin>", line 4, in __new__
> TypeError: object() takes no parameters

object's __new__() dosn't take any parameters. So call it without arguments:

class Foo:
     def __new__(cls, *args, **kargs):
         print('new', args, kargs)
         super().__new__(cls)

(at least if we know that we inherit from object. Might be that this one 
doesn't work very good with multiple inheritance...)


Thomas

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

#90555

On Wednesday, 13 May 2015 11:36:12 UTC-3, Thomas Rachel  wrote:
> Am 13.05.2015 um 15:25 schrieb andrew cooke:
> 
> >>>> class Foo:
> > ...     def __new__(cls, *args, **kargs):
> > ...         print('new', args, kargs)
> > ...         super().__new__(cls, *args, **kargs)
> 
> > new (1,) {}
> > Traceback (most recent call last):
> >    File "<stdin>", line 1, in <module>
> >    File "<stdin>", line 4, in __new__
> > TypeError: object() takes no parameters
> 
> object's __new__() dosn't take any parameters. So call it without arguments:
> 
> class Foo:
>      def __new__(cls, *args, **kargs):
>          print('new', args, kargs)
>          super().__new__(cls)
> 
> (at least if we know that we inherit from object. Might be that this one 
> doesn't work very good with multiple inheritance...)
> 
> 
> Thomas

But then nothing will be passed to __init__ on the subclass.

Andrew

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

#90557

> But then nothing will be passed to __init__ on the subclass.
> 
> Andrew

>>> class Foo:
...     def __new__(cls, *args, **kargs):
...         print('new', args, kargs)
...         super().__new__(cls)
... 
>>> class Bar(Foo):
...     def __init__(self, a):
...         print('init', a)
... 
>>> Bar(1)
new (1,) {}

no "init" is printed.

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

#90559

andrew cooke wrote:

>> But then nothing will be passed to __init__ on the subclass.
>> 
>> Andrew
> 
>>>> class Foo:
> ...     def __new__(cls, *args, **kargs):
> ...         print('new', args, kargs)
> ...         super().__new__(cls)
> ...
>>>> class Bar(Foo):
> ...     def __init__(self, a):
> ...         print('init', a)
> ...
>>>> Bar(1)
> new (1,) {}
> 
> no "init" is printed.


That's because yor __new__() returns None. Try

$ cat new_demo.py
class Foo:
    def __new__(cls, *args, **kargs):
        print('new', cls, args, kargs)
        return super().__new__(cls)

class Bar(Foo):
    def __init__(self, a):
        print('init', a)

bar = Bar(42)
$ python3 new_demo.py 
new <class '__main__.Bar'> (42,) {}
init 42
$ 

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

#90561

On Wed, May 13, 2015 at 8:45 AM, andrew cooke <andrew@acooke.org> wrote:
>>>> class Foo:
> ...     def __new__(cls, *args, **kargs):
> ...         print('new', args, kargs)
> ...         super().__new__(cls)
> ...
>>>> class Bar(Foo):
> ...     def __init__(self, a):
> ...         print('init', a)
> ...
>>>> Bar(1)
> new (1,) {}
>
> no "init" is printed.

You're not returning anything from Foo.__new__, so the result of the
constructor is None.  None.__init__ does nothing.

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

#90566

On Wednesday, 13 May 2015 11:56:21 UTC-3, Ian  wrote:
> On Wed, May 13, 2015 at 8:45 AM, andrew cooke <andrew@acooke.org> wrote:
> >>>> class Foo:
> > ...     def __new__(cls, *args, **kargs):
> > ...         print('new', args, kargs)
> > ...         super().__new__(cls)
> > ...
> >>>> class Bar(Foo):
> > ...     def __init__(self, a):
> > ...         print('init', a)
> > ...
> >>>> Bar(1)
> > new (1,) {}
> >
> > no "init" is printed.
> 
> You're not returning anything from Foo.__new__, so the result of the
> constructor is None.  None.__init__ does nothing.

ah, you're right, thanks.  that was a typo.


more generally, it seems that the error is:

  (1) __new__ is called and then __init__ from some other, external code

  (2) in 3.2 anything passed to object's __new__ was silently discarded.

the following code works in 3.2 and 3.4:

class Foo:
    def __new__(cls, *args, **kargs):
        print("new", args, kargs)
        return super().__new__(cls)

class Bar(Foo): 
    def __init__(self, *args, **kargs):
        print("init", args, kargs)

Bar(1)

(while my original code didn't).

thanks everyone,
andrew

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

#90560

On Wed, May 13, 2015 at 8:42 AM, andrew cooke <andrew@acooke.org> wrote:
> On Wednesday, 13 May 2015 11:36:12 UTC-3, Thomas Rachel  wrote:
>> Am 13.05.2015 um 15:25 schrieb andrew cooke:
>>
>> >>>> class Foo:
>> > ...     def __new__(cls, *args, **kargs):
>> > ...         print('new', args, kargs)
>> > ...         super().__new__(cls, *args, **kargs)
>>
>> > new (1,) {}
>> > Traceback (most recent call last):
>> >    File "<stdin>", line 1, in <module>
>> >    File "<stdin>", line 4, in __new__
>> > TypeError: object() takes no parameters
>>
>> object's __new__() dosn't take any parameters. So call it without arguments:
>>
>> class Foo:
>>      def __new__(cls, *args, **kargs):
>>          print('new', args, kargs)
>>          super().__new__(cls)
>>
>> (at least if we know that we inherit from object. Might be that this one
>> doesn't work very good with multiple inheritance...)
>>
>>
>> Thomas
>
> But then nothing will be passed to __init__ on the subclass.

__init__ is not called by __new__. In the object construction, __new__
is called, and *then* __init__ is called on the result.

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

#90567

On 5/13/2015 9:25 AM, andrew cooke wrote:

> The following code worked on Python 3.2, but no longer works in 3.4.

Bugfixes break code that depends on buggy behavior. See
https://bugs.python.org/issue1683368
Your code also fails in 2.7.9 if you inherit Foo from object.
The exact error messages changed for 3.4 in
https://bugs.python.org/issue7963

 > Did something change,

Obviously yes.

 > or have I always been doing something dumb?

You were depending on behavior of object that Guido decided was buggy.

I found the tracker issue by looking for 'object' in the Core and 
Builtins sections of the changelog one can access from What's New, first 
paragraph (using Highlight All in Firefox).

>>>> class Foo:
> ...     def __new__(cls, *args, **kargs):
> ...         print('new', args, kargs)
> ...         super().__new__(cls, *args, **kargs)
> ...
>>>> class Bar(Foo):
> ...     def __init__(self, a):
> ...         print('init', a)
> ...
>>>> Bar(1)
> new (1,) {}
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "<stdin>", line 4, in __new__
> TypeError: object() takes no parameters
>
> What I was expecting to happen (and what happens in 3.2) is that the object.__new__ method passes the argument to the __init__ of the subclass.

-- 
Terry Jan Reedy

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

#90575

On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy  wrote:
> On 5/13/2015 9:25 AM, andrew cooke wrote:
> 
> > The following code worked on Python 3.2, but no longer works in 3.4.
> 
> Bugfixes break code that depends on buggy behavior. See
> https://bugs.python.org/issue1683368
> Your code also fails in 2.7.9 if you inherit Foo from object.
> The exact error messages changed for 3.4 in
> https://bugs.python.org/issue7963
> 
>  > Did something change,
> 
> Obviously yes.

thanks, but why does someone on this group always have to be a dick and make some smart-assed comment like this?

>  > or have I always been doing something dumb?
> 
> You were depending on behavior of object that Guido decided was buggy.
> 
> I found the tracker issue by looking for 'object' in the Core and 
> Builtins sections of the changelog one can access from What's New, first 
> paragraph (using Highlight All in Firefox).
> 
> >>>> class Foo:
> > ...     def __new__(cls, *args, **kargs):
> > ...         print('new', args, kargs)
> > ...         super().__new__(cls, *args, **kargs)
> > ...
> >>>> class Bar(Foo):
> > ...     def __init__(self, a):
> > ...         print('init', a)
> > ...
> >>>> Bar(1)
> > new (1,) {}
> > Traceback (most recent call last):
> >    File "<stdin>", line 1, in <module>
> >    File "<stdin>", line 4, in __new__
> > TypeError: object() takes no parameters
> >
> > What I was expecting to happen (and what happens in 3.2) is that the object.__new__ method passes the argument to the __init__ of the subclass.
> 
> -- 
> Terry Jan Reedy

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

#90577

On 5/13/2015 2:42 PM, andrew cooke wrote:
> On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy  wrote:
>> On 5/13/2015 9:25 AM, andrew cooke wrote:
>>
>>> The following code worked on Python 3.2, but no longer works in 3.4.
>>
>> Bugfixes break code that depends on buggy behavior. See
>> https://bugs.python.org/issue1683368
>> Your code also fails in 2.7.9 if you inherit Foo from object.
>> The exact error messages changed for 3.4 in
>> https://bugs.python.org/issue7963
>>
>>   > Did something change,
>>
>> Obviously yes.
>
> thanks, but why does someone on this group always have to be a dick and make some smart-assed comment like this?

To remind people to ask the question they want answered.

>>   > or have I always been doing something dumb?
>>
>> You were depending on behavior of object that Guido decided was buggy.
>>
>> I found the tracker issue by looking for 'object' in the Core and
>> Builtins sections of the changelog one can access from What's New, first
>> paragraph (using Highlight All in Firefox).

I spent 15 minutes digging around to find the answer that no one else 
gave you, and all your total response is to ignore that, not thank me, 
and call me a dick?  Whose is the dick here?

Being punished for answering questions is one reason I have mostly 
stopped.  I will try to remember not to waste time responding to you again.

-- 
Terry Jan Reedy

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

#90580

On 13/05/2015 19:42, andrew cooke wrote:
> On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy  wrote:
>> On 5/13/2015 9:25 AM, andrew cooke wrote:
>>
>>> The following code worked on Python 3.2, but no longer works in 3.4.
>>
>> Bugfixes break code that depends on buggy behavior. See
>> https://bugs.python.org/issue1683368
>> Your code also fails in 2.7.9 if you inherit Foo from object.
>> The exact error messages changed for 3.4 in
>> https://bugs.python.org/issue7963
>>
>>   > Did something change,
>>
>> Obviously yes.
>
> thanks, but why does someone on this group always have to be a dick and make some smart-assed comment like this?
>

Please don't bother asking again after that response, especially to 
somebody with the stature of Terry Reedy.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#90583

On Wednesday, May 13, 2015 at 3:46:16 PM UTC-4, Mark Lawrence wrote:
> On 13/05/2015 19:42, andrew cooke wrote:
> > On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy  wrote:
> >> On 5/13/2015 9:25 AM, andrew cooke wrote:
> >>
> >>> The following code worked on Python 3.2, but no longer works in 3.4.
> >>
> >> Bugfixes break code that depends on buggy behavior. See
> >> https://bugs.python.org/issue1683368
> >> Your code also fails in 2.7.9 if you inherit Foo from object.
> >> The exact error messages changed for 3.4 in
> >> https://bugs.python.org/issue7963
> >>
> >>   > Did something change,
> >>
> >> Obviously yes.
> >
> > thanks, but why does someone on this group always have to be a dick and make some smart-assed comment like this?
> >
> 
> Please don't bother asking again after that response, especially to 
> somebody with the stature of Terry Reedy.
> 

To my ears, "Obviously yes" is a pedantic smart-ass comment.  It added
nothing to the answer, other than to point out that the question was
obvious. Essentially, it said, "you are silly."  I don't think it's
unreasonable to expect the regulars here to be able to answer politely.

I certainly don't think Andrew's behavior in this thread is cause for
asking him not to return.  I also don't think "people with stature"
should be allowed to behave in ways that others would not be allowed.
And how are newcomers expected to identify "people with stature"?

Email can be a harsh medium, lacking social cues that can soften
interchanges in other arenas.  We all have to try hard to be kind to
each other.  And yes, I expect more of the regulars than I do of
people new to the list.  The regulars set the tone.  They are the
hosts here, and should be doing what they can to make new people
feel welcome.

--Ned.

> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

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

#90596

On Thu, 14 May 2015 06:33 am, Ned Batchelder wrote:

> On Wednesday, May 13, 2015 at 3:46:16 PM UTC-4, Mark Lawrence wrote:
>> On 13/05/2015 19:42, andrew cooke wrote:
>> > On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy  wrote:
>> >> On 5/13/2015 9:25 AM, andrew cooke wrote:
[...]
>> >>   > Did something change,
>> >>
>> >> Obviously yes.
>> >
>> > thanks, but why does someone on this group always have to be a dick and
>> > make some smart-assed comment like this?
>> 
>> Please don't bother asking again after that response, especially to
>> somebody with the stature of Terry Reedy.
>> 
> 
> To my ears, "Obviously yes" is a pedantic smart-ass comment.  It added
> nothing to the answer, other than to point out that the question was
> obvious. Essentially, it said, "you are silly."  I don't think it's
> unreasonable to expect the regulars here to be able to answer politely.

I don't think "Obviously yes" is necessarily intended to be rude, although
it can be read that way. "Obviously yes" goes without saying, just as "Did
something change?" goes without saying. Obviously something changed, and
just as obviously it should be obvious that it changed.

(Ooh, recursive obviousness...)


In face to face communication, a response like "Obviously yes" could be said
with a gentle tone and a smile, or it could be said with a tone that
implies an unstated "dumbarse" following. In email, it is very hard to
avoid coming across as the second without the explicit use of a smiley.


[puts on amateur headology hat to explain the sociology happening here]

I think what some people may be missing is that Andrew's question "Has
something changed?" isn't an actual question about whether something has
changed. It's more of a rhetorical question inviting validation:

"I can see something has changed, but I'm unwilling to come right out and
say so because I might be wrong, or because I'm not assertive, or because
I've been taught not to jump to conclusions (especially on technical
forums), and so I'm posing this as a question and looking for confirmation
of what I can actually see with my own eyes."

In which case, the answer being looked for is along the lines "Correct,
things changed in version <whatever>". An answer like "Obviously yes"
implies "dumb insolence" from an authority figure:

(1) It's dumb insolence because we're expected to understand the question as
a rhetorical device, not an actual question. Of course Andrew can see that
something has changed, he's not an idiot. Since Terry isn't an idiot,
presumably he knows that too, so for him to take the question literally
implies that he sees Andrew as an idiot.

(2) Terry is the authority figure here because Andrew is asking for help.
That makes Andrew the low status individual in this interaction, and Terry
is giving the help, which gives him the power in the interaction.

(This is especially annoying because normally dumb insolence is one of the
few ways that people of low status can fight back against those of high
status: by following the letter of the given instructions and treating
statements and questions literally.)

Note that many of the interactions above are based on getting into the other
person's head and inferring their state of mind. Andrew assumes that Terry
knows that his question wasn't intended literally; Andrew assumes that if
Terry does take it literally, it is because Terry intends the answer to be
a put down. (Terry confirms that with his response of "To remind people to
ask the question they want answered".) But such inferences aren't reliable
in the absence of non-verbal clues such as body language and tone of voice.


> I certainly don't think Andrew's behavior in this thread is cause for
> asking him not to return.  I also don't think "people with stature"
> should be allowed to behave in ways that others would not be allowed.
> And how are newcomers expected to identify "people with stature"?

Well *obviously* they're the ones acting like dicks without being called out
on it :-)


> Email can be a harsh medium, lacking social cues that can soften
> interchanges in other arenas.  We all have to try hard to be kind to
> each other.  And yes, I expect more of the regulars than I do of
> people new to the list.  The regulars set the tone.  They are the
> hosts here, and should be doing what they can to make new people
> feel welcome.

I agree with that. It takes two to be offended: one to give offense, and one
to take it. Nobody can force you to be offended. Either Tim or Terry could
have refused to take offense.

Instead of asking a rhetorical question about people acting like dicks,
Andrew could have thought "Terry's response sounds a bit dickish, but he
probably didn't mean it to come across as rude"; instead of defending his
choice of words in a patronising tone Terry could have said "Hmmm, yes my
response did make me sound a bit rude, but that wasn't intended".

(Unless of course it was intended to be rude. But perhaps that is too
obvious to need saying.) *wink*




-- 
Steven

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

#90568

On 13/05/2015 14:25, andrew cooke wrote:
>
> Hi,
>
> The following code worked on Python 3.2, but no longer works in 3.4.  Did something change, or have I always been doing something dumb?
>
> (I realise the code is pointless as is - it's the simplest example I can give of a problem I am seeing with more complex code).
>
>>>> class Foo:
> ...     def __new__(cls, *args, **kargs):
> ...         print('new', args, kargs)
> ...         super().__new__(cls, *args, **kargs)
> ...
>>>> class Bar(Foo):
> ...     def __init__(self, a):
> ...         print('init', a)
> ...
>>>> Bar(1)
> new (1,) {}
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "<stdin>", line 4, in __new__
> TypeError: object() takes no parameters
>
> What I was expecting to happen (and what happens in 3.2) is that the object.__new__ method passes the argument to the __init__ of the subclass.
>
> Any help appreciated.
>
> Thanks,
> Andrew
>

I'm completely convinced that I've seen a change go through on the bug 
tracker that impacts on this area, but many months if not years ago. 
Unfortunately searching the bug tracker for super, __new__, __init__ and 
so on gets a lot of hits, leaving my Mk1 eyeballs overworked.  At least 
I've tried but sorry, had to give up :(

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#90569

On 5/13/2015 12:38 PM, Mark Lawrence wrote:

> I'm completely convinced that I've seen a change go through on the bug
> tracker that impacts on this area, but many months if not years ago.
> Unfortunately searching the bug tracker for super, __new__, __init__ and
> so on gets a lot of hits, leaving my Mk1 eyeballs overworked.  At least
> I've tried but sorry, had to give up :(

 From my post, sent while you were composing this. (It took me awhile to 
find it.)

Bugfixes break code that depends on buggy behavior. See
https://bugs.python.org/issue1683368
Your code also fails in 2.7.9 if you inherit Foo from object.
The exact error messages changed for 3.4 in
https://bugs.python.org/issue7963

(Found by searching https://docs.python.org/3.4/whatsnew/changelog.html
for 'object'. selecting 'Highlight All', and scanning Core and Builtins 
sections. I believe the change went into some 2.7.x release, as well as 
3.3.0a1)
-- 
Terry Jan Reedy

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

#90570

On 5/13/2015 12:36 PM, Terry Reedy wrote:
> On 5/13/2015 9:25 AM, andrew cooke wrote:
>
>> The following code worked on Python 3.2, but no longer works in 3.4.
>
> Bugfixes break code that depends on buggy behavior. See
> https://bugs.python.org/issue1683368
> Your code also fails in 2.7.9 if you inherit Foo from object.
> The exact error messages changed for 3.4 in
> https://bugs.python.org/issue7963
>
>  > Did something change,
>
> Obviously yes.
>
>  > or have I always been doing something dumb?
>
> You were depending on behavior of object that Guido decided was buggy.
>
> I found the tracker issue by looking for 'object' in the Core and
> Builtins sections of the changelog one can access from What's New, first
> paragraph (using Highlight All in Firefox).
>
>>>>> class Foo:
>> ...     def __new__(cls, *args, **kargs):
>> ...         print('new', args, kargs)
>> ...         super().__new__(cls, *args, **kargs)

I forgot to memtion that it is intended that one remove arguments that 
are specific to a class before passing them on to super. All arguments 
should be consumed (removed) somewhere in the chain before reaching 
object.  The bug that was fixed was not raising when not all args were 
consumed. As other showed, your code works properly in all versions when 
you do so by only passing on cls.

-- 
Terry Jan Reedy

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

#90571

On 13/05/2015 18:05, Terry Reedy wrote:
> On 5/13/2015 12:38 PM, Mark Lawrence wrote:
>
>> I'm completely convinced that I've seen a change go through on the bug
>> tracker that impacts on this area, but many months if not years ago.
>> Unfortunately searching the bug tracker for super, __new__, __init__ and
>> so on gets a lot of hits, leaving my Mk1 eyeballs overworked.  At least
>> I've tried but sorry, had to give up :(
>
>  From my post, sent while you were composing this. (It took me awhile to
> find it.)
>
> Bugfixes break code that depends on buggy behavior. See
> https://bugs.python.org/issue1683368
> Your code also fails in 2.7.9 if you inherit Foo from object.
> The exact error messages changed for 3.4 in
> https://bugs.python.org/issue7963
>
> (Found by searching https://docs.python.org/3.4/whatsnew/changelog.html
> for 'object'. selecting 'Highlight All', and scanning Core and Builtins
> sections. I believe the change went into some 2.7.x release, as well as
> 3.3.0a1)

Yes, I saw your email from the bug tracker roughly five seconds after I 
hit the SEND key for mine above :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [standalone]

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

csiph-web