[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

R. David Murray added the comment: OK, agreed. The general principle is: if you reference the name, it is looked up in the the builtins namespace at runtime (effectively an indirect reference). If the syntax doesn't explicitly mention the name, then it is going to be (the equivalent of) a di

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Raymond Hettinger added the comment: I agree with the other commenters and recommend this be closed. There doesn't seem to be a a useful issue here. It seems more like a pedantic twisting of words that ignores how Python works (i.e. that you can specify a specific class to inherit from and t

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: > On the other hand, are there any examples *other* than class and except where > this distinction matters? Of course. For example, "for" semantics mentions StopIteration. Of course it doesn't mean "whatever builtins.StopIteration currently refers to". [And in

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: I don't know whether the fix is small, since there is no fix that I see yet. I'd just want to draw your attention to the fact that Python is extremely expressive language: almost nothing is "equivalent" to anything else, if you look hard enough. Surely, in the

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: The two phrases you present are significantly different- one draws an equivalence. The other does not. That in essence is what this is all about. The difference between an indirect and direct reference in the class inheritance syntax is neither implied nor mentio

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: Sorry, I fail to see the big difference. Let's take print as an example: All non-keyword arguments are converted to strings like str() does and written to the stream, separated by sep and followed by end. Both sep and end must be strings; they can also be None

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: You have put that much more precisely than I could have. I'm not aware that it is an issie elsewhere, but given that I only ran into this today I may not the person best qualified to answer that question. -- ___ Python

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

R. David Murray added the comment: I see I didn't specifically address your counter argument ("that would obviously be absurd"). Having thought it it some more, your are right, there *is* a difference between the examples you think it would be absurd to disclaim and your example here. In pyt

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: I really don't see that as a logical extension of what I am saying at all. Sure, shadowing builtins changes what they do, but if you're saying the syntax is equivalent then te effect of the shadowing should be consistent. -- _

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

R. David Murray added the comment: shadowadler, the documentation assumes *throughout* that you have not created any variable that shadows any standard Python entities. There is no other rational way to write the documentation. To change that policy would, as has been pointed out, require di

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: Not at all- what you are talking about is obviously absurd. I am merely asserting that the statement in the docs you point to - that the two statements are equivalent - is untrue, the two statements are not equivalent in their behaviour. --

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: It's not hard to find a link. https://docs.python.org/3.7/reference/compound_stmts.html#class-definitions But trying to change that to incorporate what OP is asking is a wild goose chase. There are numerous instances when a documentation is referring to a built

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Steven D'Aprano added the comment: > the documentation states that the two examples I gave should yield identical > results. Got a link to the specific documentation that says this? And a suggested improvement? -- assignee: -> docs@python components: +Documentation nosy: +docs@python

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: Still not disagreeing with you- I just don't think that this is what the documentation implies. -- ___ Python tracker ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Steven D'Aprano added the comment: I don't think this is a bug, I think it is standard behaviour which should be expected if you think about Python's execution model. If you inherit from object implicitly: class Spam: ... then the interpreter gets to pick the base class, and it uses the g

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: I accept what you are saying as consistent. Nevertheless, the documentation states that the two examples I gave should yield identical results. They do not, they perform different actions, albeit subtly. Ergo, this is unexpected behaviour from a documentation poi

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: Yes, they are obviously not equivalent if you execute object = int before that. :-D And (like I said) "received wisdom" is also that "except:" is equivalent to "except BaseException:", but of course it isn't equivalent if you execute BaseException = Na

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: Out of curiosity, given that you can change every other point in the hierarchy by changing the binding of modules, what is your philosophical objection to being able to change the top of the hierarchy? -- ___ Python tr

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: I don't necessarily disagree with what you are saying- however, the received wisdom (as per my response to the SO question) is that class SomeClass(object): pass and class SomeClass: pass Should do the same thing. They evidently don't. It might be that

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: To me, it seems like obvious behavior. What exactly do you think is inconsistent here? Of course, the default inherit-class is "what's usually known as builtins.object", and it's always the same class. You should not be able to change it just by rebinding built

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Changes by shadowadler : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

New submission from shadowadler: I discovered this while messing about with an unrelated idea, but the issue is that if you inherit explicitly from object, you get different behaviour than when you inherit implicitly. This is duplicated from my SO answer here: https://stackoverflow.com/questio