[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping
New submission from Geoffrey Sneddon : The mixin methods on MappingView and its subclasses all rely on the undocumented MappingView._mapping (set in the undocumented MappingView.__init__). This should probably be documented at least insofar as Set._from_iterable is. -- assignee: docs@python components: Documentation messages: 37 nosy: docs@python, gsnedders priority: normal severity: normal status: open title: collections.abc.MappingView mixins rely on undocumented _mapping type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping
Geoffrey Sneddon added the comment: How do you use ItemsView without: * relying on __init__ and _mapping, which are both private implementation details, or * reimplementing __len__, __contains__, and __iter__? Given you can't use the mixin implementations of __len__, __contains__, and __iter__ without relying on private implementation details, should they actually be considered mixin implementations? Shouldn't they just be abstract methods given you can't actually use them? -- ___ Python tracker <https://bugs.python.org/issue37145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping
Geoffrey Sneddon added the comment: Then I guess what I consider a bug is "__init__ is undocumented". -- ___ Python tracker <https://bugs.python.org/issue37145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping
Geoffrey Sneddon added the comment: You've missed my point: the arguments that MappingView.__init__ takes are undocumented. Nowhere mentions class MappingView(mapping), as I would expect from how initializers are documented elsewhere. -- ___ Python tracker <https://bugs.python.org/issue37145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping
Geoffrey Sneddon added the comment: Like, where in the documentation can I learn that MappingView's initializer takes an argument "mapping"? -- ___ Python tracker <https://bugs.python.org/issue37145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34000] Document when compile returns a code object v. AST
New submission from Geoffrey Sneddon : The compile built-in documentation says: > Compile the source into a code or AST object. It doesn't however go on to say when it returns each! It does however note: > If you want to parse Python code into its AST representation, see ast.parse(). So compile can compile the source into an AST object, but if I want to parse Python code into an AST I should use ast.parse? As far as I can tell, this goes back to Python 2.5: https://docs.python.org/2/whatsnew/2.5.html#build-and-c-api-changes >From the What's New page: > It’s possible for Python code to obtain AST objects by using the compile() > built-in and specifying _ast.PyCF_ONLY_AST as the value of the flags parameter So that would seem to be the case when compile returns an AST! Interestingly, the implementation of ast.parse *literally just calls compile* (https://github.com/python/cpython/blob/58ed7307ea0b5c5aa052291ebc3030f314f938d8/Lib/ast.py#L30-L35). Note, however, this means a further part of the compile documentation is wrong: > The optional arguments flags and dont_inherit control which future statements > (see PEP 236) affect the compilation of source. flags is therefore something more general than just controlling which future statements affect the source, given it also controls the output type of the function. In short, we should: * document the flags argument can take _ast.PyCF_ONLY_AST *or* change the documentation to say it returns a code object (and not an AST object) -- assignee: docs@python components: Documentation messages: 320721 nosy: docs@python, gsnedders priority: normal severity: normal status: open title: Document when compile returns a code object v. AST versions: Python 2.7, Python 3.7 ___ Python tracker <https://bugs.python.org/issue34000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17909] Autodetecting JSON encoding
Changes by Geoffrey Sneddon : -- nosy: +gsnedders ___ Python tracker <http://bugs.python.org/issue17909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
