Mailman 3 August 2017 - docs

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by Vedran Čačić Aug. 26, 2017

Aug. 26, 2017

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 docs, in various places it is written that some code is equivalent to some other code, where it's obvious that those are not completely equivalent in your sense. E.g. "a_list += [1, 2, 3] is equivalent to a_list.extend([1, 2, 3])" (https://docs.python.org/3.5/faq/programming.html?highlight=equivalent#why-d…) where it's obvious that the second one is an expression, while the first one is not. Also, the docs are full of "equivalents" to various idioms from _other programming languages_, where again it's obvious that total behavioral equivalence is not what's intended. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by shadowadler Aug. 26, 2017

Aug. 26, 2017

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 mentioned in the documentation. It led me to expect one behaviour and find another. That is the extent of my issue, and the fix seems to be to be small. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by Vedran Čačić Aug. 26, 2017

Aug. 26, 2017

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, which means to use the default values. If no objects are given, print() will just write end. The file argument must be an object with a write(string) method; if it is not present or None, sys.stdout will be used. Is the above so different than writing: print(*args, file=f, sep=s, end=e) is equivalent to f.write(s.join(map(str, args))+e) ? In my head, no. It's just that sometimes we use Python, and sometimes English, to describe the semantics. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by shadowadler Aug. 26, 2017

Aug. 26, 2017

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 tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by R. David Murray Aug. 26, 2017

Aug. 26, 2017

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 python, an entity is identified by an id (which is a memory address in CPython, but that's an implementation detail). A name is just a convenience label used to refer to that id. When you rebind a name, you change what id it points to, but any other piece of python that is already using the original id is not affected. But anything using an indirect reference through another object (such as builtins) *will* see the change. Your argument, then, is that it is not documented that 'class x:' is using a direct reference to object rather than an indirect reference. Our argument is that this is obviously the way Python works (the interpreter itself refers directly to the fundamental entities such as the base of the exception hierarchy and object). The number of places that would need to be changed to make this explicit is much smaller than I was thinking when I closed the issue, but I'm still not convinced it is something that needs to be explicitly documented. It is just part of the way Python works at a fundamental level, and because it is a *statement* that does not refer to a variable, it is intuitive that it is going to reference the original object, not whatever builtins.object is referring to. We do say that explicit is better than implicit, but in this case we're talking about a fundamental part of the language, and the specification of how this works probably belongs in some overview section on statements. On the other hand, are there any examples *other* than class and except where this distinction matters? ---------- resolution: not a bug -> stage: resolved -> status: closed -> open _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by shadowadler Aug. 26, 2017

Aug. 26, 2017

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. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by R. David Murray Aug. 26, 2017

Aug. 26, 2017

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 disclaimers in thousands of places in the documentation. That's not something that is going to be done :) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by shadowadler Aug. 26, 2017

Aug. 26, 2017

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. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

Contribution to the development of Python Modules
by Yogita Bang Aug. 26, 2017

Aug. 26, 2017

Hello Sir/Madam, Can you guide me through the process of How to contribute to the development of a feature in Python modules? Thanks and Regards, Yogita Bang

1 0

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by Vedran Čačić Aug. 26, 2017

Aug. 26, 2017

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 builtin. E.g. (print): All non-keyword arguments are converted to strings like str() does (repr): this function makes an attempt to return a string that would yield an object with the same value when passed to eval() (type): The isinstance() built-in function is recommended for testing the type of an object Of course, all of these must be changed, since they don't work as advertised if you rebind str, eval or isinstance. I claim this is nonsense. If anything, we should educate people that when documentation refers to "the builtin X", it doesn't mean "whatever is current referrent of builtins.X". Never. Only "__import__" kinda works this way (though not in builtins, but in globals), and that's mostly a historic accident. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0