[issue36144] Dictionary addition. (PEP 584)
Aaron Hall added the comment:
Another obvious way to do it, but I'm +1 on it.
A small side point however - PEP 584 reads:
> To create a new dict containing the merged items of two (or more) dicts, one
> can currently write:
> {**d1, **d2}
> but this is neither obvious nor easily discoverable. It is only guaranteed to
> work if the keys are all strings. If the keys are not strings, it currently
> works in CPython, but it may not work with other implementations, or future
> versions of CPython[2].
...
> [2] Non-string keys: https://bugs.python.org/issue35105 and
> https://mail.python.org/pipermail/python-dev/2018-October/155435.html
The references cited does not back this assertion up. Perhaps the intent is to
reference the "cool/weird hack" dict(d1, **d2) (see
https://mail.python.org/pipermail/python-dev/2010-April/099485.html and
https://mail.python.org/pipermail/python-dev/2010-April/099459.html), which
allowed any hashable keys in Python 2 but only strings in Python 3.
If I see {**d1, **d2}, my expectations are that this is the new generalized
unpacking and I currently expect any keys to be allowed, and the PEP should be
updated to accurately reflect this to prevent future misunderstandings.
--
nosy: +Aaron Hall
___
Python tracker
<https://bugs.python.org/issue36144>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36927] traceback docstrings should explicitly state return values instead of referring to other functions
New submission from Aaron Hall : I've written three (or more) answers on Stack Overflow about how to use the functions in the traceback module, and I code Python all day long. Embarrassing confession: I just recommended the wrong traceback function in email to fix the incorrect usage of another of these functions after pulling up the docs because. I corrected myself before anyone else could correct me, but I find these docstrings incredibly frustrating and problematic. May I please give them a little more verbiage about their return values? e.g.: def format_tb(tb, limit=None): """A shorthand for 'format_list(extract_tb(tb, limit))'.""" return extract_tb(tb, limit=limit).format() should be: def format_tb(tb, limit=None): """A shorthand for 'format_list(extract_tb(tb, limit))', which returns a list of strings ready for printing'. """ return extract_tb(tb, limit=limit).format() In fact, perhaps the "shorthand" part is an implementation detail that may not even be correct (it doesn't immediately seem to be) and should be removed. -- assignee: docs@python components: Documentation messages: 342588 nosy: Aaron Hall, docs@python priority: normal severity: normal status: open title: traceback docstrings should explicitly state return values instead of referring to other functions versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue36927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34648] Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5
Change by Aaron Hall : -- nosy: +Aaron Hall ___ Python tracker <https://bugs.python.org/issue34648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36551] Optimize list comprehensions with preallocate size and protect against overflow
Change by Aaron Hall : -- nosy: +Aaron Hall ___ Python tracker <https://bugs.python.org/issue36551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35625] Comprehension doc doesn't mention buggy class scope behavior
Change by Aaron Hall : -- nosy: +Aaron Hall ___ Python tracker <https://bugs.python.org/issue35625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
Aaron Hall added the comment: No need to keep this open, I agree with the core developers this shouldn't be changed. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue31753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Change by Aaron Hall : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions
Change by Aaron Hall : -- nosy: +Aaron Hall ___ Python tracker <https://bugs.python.org/issue35059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12154] PyDoc Partial Functions
Aaron Hall added the comment: Should pydoc treat a partial object like a function? Should a partial be an instance of a function? Should we be able to add all the nice things that functions have to it? If we want that, should we simply instantiate a function the normal way, with a new function definition? That is, instead of this: >>> from functools import partial >>> basetwo = partial(int, base=2) >>> basetwo.__doc__ = 'convert base 2 string to int' do this: def basetwo(string:str) -> int: 'convert base 2 string to int' return int(string, base=2) Otherwise, either the partial definition or pydoc needs some work. (Cheers and bump!) -- ___ Python tracker <https://bugs.python.org/issue12154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
Change by Aaron Hall : -- nosy: +Aaron Hall ___ Python tracker <https://bugs.python.org/issue30129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32400] inspect.isdatadescriptor false negative
Change by Aaron Hall <aaronch...@yahoo.com>: -- nosy: +Aaron Hall ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25457] json dump fails for mixed-type keys when sort_keys is specified
Aaron Hall <aaronch...@yahoo.com> added the comment:
>From a design standpoint, I'm fairly certain the sort_keys argument was
>created due to Python's dicts being arbitrarily ordered.
Coercing to strings before sorting is unsatisfactory because, e.g. numbers sort
lexicographically instead of by numeric value when strings.
>>> import json
>>> json.dumps({i:i**2 for i in range(15)}, sort_keys=True)
'{"0": 0, "1": 1, "2": 4, "3": 9, "4": 16, "5": 25, "6": 36, "7": 49, "8": 64,
"9": 81, "10": 100, "11": 121, "12": 144, "13": 169, "14": 196}'
>>> json.dumps({str(i):i**2 for i in range(15)}, sort_keys=True)
'{"0": 0, "1": 1, "10": 100, "11": 121, "12": 144, "13": 169, "14": 196, "2":
4, "3": 9, "4": 16, "5": 25, "6": 36, "7": 49, "8": 64, "9": 81}'
Changing the order of operations is just going to create more issues, IMHO.
Now that users can sort their dicts prior to providing them to the function,
e.g.:
>>> json.dumps({str(i):i**2 for i in range(15)})
'{"0": 0, "1": 1, "2": 4, "3": 9, "4": 16, "5": 25, "6": 36, "7": 49, "8": 64,
"9": 81, "10": 100, "11": 121, "12": 144, "13": 169, "14": 196}'
we could deprecate the argument, or just keep it as-is for hysterical raisins.
Regardless, I'd close this as "won't fix".
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25457>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25457] json dump fails for mixed-type keys when sort_keys is specified
Aaron Hall <aaronch...@yahoo.com> added the comment: Now that dicts are sortable, does that make the sort_keys argument redundant? Should this bug be changed to "won't fix"? ------ nosy: +Aaron Hall ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25457> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33498] pathlib.Path wants an rmtree method
Aaron Hall <aaronch...@yahoo.com> added the comment: > What is wrong with just using shutil.rmtree()? 0. It's awkward to import just for demonstrations. 1. It's harder for new pythonists to discover. 2. A method provides discoverability in an object's namespace. 3. rmtree is a method of paths (typical usage is rmtree(path)). 4. rmtree is clearly functionality that is missing from the Path object (which has effectively rm, rm -d, but not rm -r). > You can't deal with files with only using pathlib. You can't read ZIP > archives, open temporary files, import modules, download files from Internet > and open them in the webbrowser, run subprocesses, send files by e-mail, > determine the MIME type of files, read WAV files with only using pathlib. I wasn't suggesting those things. After some thought, I would probably not support those things to be in pathlib either. Maybe they are "file" methods, but to me, they are not semantically "path" methods. That functionality is in much more specialized domain-oriented modules, and easy to discover. We need a recursive rmdir so that users aren't tempted to roll their own - and wind up deleting symlinked things. I *would* support some of those other shutil functions to become Path methods, perhaps move, copy2, and copytree, as they *are* path methods (you just need to supply another destination path), but I'm not finding it to be a pain point yet. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33498] pathlib.Path wants an rmtree method
New submission from Aaron Hall <aaronch...@yahoo.com>: pathlib.Path wants the rmtree method from shutil I think we need this method for a couple of reasons. 1. in shell, rm has the -r flag - In Python, we use shutil.rmtree as a best practice for this. 2. I prefer to teach my students about pathlib.Path as opposed to other ways of dealing with files. It's a great abstraction. But it's somewhat leaky, especially when it comes to recursively deleting a directory with its contents, as I now need to import rmtree from shutil. Perhaps we need this as a method in the abstract base class that recursively uses the methods provided by the concrete implementations. I can look at the rmtree method for a reference implementation. Perhaps we should just give Path.rmdir a default recursive argument? Default would be False, of course, to retain current behavior. -- components: Library (Lib) messages: 316511 nosy: Aaron Hall priority: normal severity: normal status: open title: pathlib.Path wants an rmtree method type: enhancement versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30670] pprint for dict in sorted order or insert order?
Aaron Hall <aaronch...@yahoo.com> added the comment: If/when order is guaranteed (3.7?) we should have a pprint that respects current order, -or- we should get an improved pprint (maybe named pp or print?) that understands mappings and other abstract data types. I had a conversation about pprint at the Python meetup last night. It kinda went like this: https://www.youtube.com/watch?v=NpYEJx7PkWE Maybe now's the time for improved behavior? -- nosy: +Aaron Hall ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
Aaron Hall <aaronch...@yahoo.com> added the comment: New information: I think I have pinpointed at least a contributor to the difference - closure lookups seem to be currently slightly slower (by a few percent) than global lookups (see https://stackoverflow.com/a/46798876/541136). And as we can see, an inner function that references itself is a closure on itself (see LOAD_DEREF): >>> def foo(): ... def bar(): ... return bar ... return bar ... >>> bar = foo() >>> import dis >>> dis.dis(bar) 3 0 LOAD_DEREF 0 (bar) 2 RETURN_VALUE This, at least to me, explains why the performance difference doesn't completely amortize away. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
Aaron Hall <aaronch...@yahoo.com> added the comment:
Static analysis:
My mental model currently says the rebuilt function every outer call is an
expense with no offsetting benefit. It seems that a function shouldn't build a
closure on every call if the closure doesn't close over anything immediately
used by the functionality. But I can't explain why the cost doesn't amortize
toward zero in my testing.
Usage analysis:
On the other hand, this doesn't seem used very much at all in the std lib.
I'm not sure what the entire global benefit is to moving the closure to be a
global instead - but there are about 88000 potential uses of the code on
github: https://github.com/search?p=3=literal_eval=Code=%E2%9C%93
One use seems to be scanning Python code - so potentially it gets a lot of use?
Alternatively: - to echo Serhiy ("Maybe it is worth to spend some time for
optimizing closure creation."), perhaps the matter could be made irrelevant by
looking at how we handle closures. I'm not sure why the difference didn't
amortize to nearly nothing in my testing - I used Anaconda's Python 3.6.1
distribution on Linux - if that matters.
Potential improvement:
So to be clear, the suggested change would probably be to move _convert to a
global, maybe named _literal_eval_convert (this is less half-baked than my
first code post, which I somewhat regret. Note that the recursive calls would
need to be edited as well as the move and dedent.):
def literal_eval(node_or_string):
"""
Safely evaluate an expression node or a string containing a Python
expression. The string or node provided may only consist of the following
Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
sets, booleans, and None.
"""
if isinstance(node_or_string, str):
node_or_string = parse(node_or_string, mode='eval')
if isinstance(node_or_string, Expression):
node_or_string = node_or_string.body
return _literal_eval_convert(node_or_string)
def _literal_eval_convert(node):
if isinstance(node, Constant):
return node.value
elif isinstance(node, (Str, Bytes)):
return node.s
elif isinstance(node, Num):
return node.n
elif isinstance(node, Tuple):
return tuple(map(_literal_eval_convert, node.elts))
elif isinstance(node, List):
return list(map(_literal_eval_convert, node.elts))
elif isinstance(node, Set):
return set(map(_literal_eval_convert, node.elts))
elif isinstance(node, Dict):
return dict((_literal_eval_convert(k), _literal_eval_convert(v)) for k,
v
in zip(node.keys, node.values))
elif isinstance(node, NameConstant):
return node.value
elif isinstance(node, UnaryOp) and isinstance(node.op, (UAdd, USub)):
operand = _literal_eval_convert(node.operand)
if isinstance(operand, _NUM_TYPES):
if isinstance(node.op, UAdd):
return + operand
else:
return - operand
elif isinstance(node, BinOp) and isinstance(node.op, (Add, Sub)):
left = _literal_eval_convert(node.left)
right = _literal_eval_convert(node.right)
if isinstance(left, _NUM_TYPES) and isinstance(right, _NUM_TYPES):
if isinstance(node.op, Add):
return left + right
else:
return left - right
raise ValueError('malformed node or string: ' + repr(node))
Note that I am not strongly committed to this issue, and won't feel badly if it
is closed. It just seemed to be some low-hanging fruit in the standard library
that I happened across.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
Aaron Hall <aaronch...@yahoo.com> added the comment: So... moving the closure (which may be called recursively) to the global scope actually does improve performance (for small cases, about 10% - larger cases amortize the cost of the closure being built, but in a 100 item dictionary, still about 4% faster to extricate the closure). So I'm reopening. Also suggesting we consider doing this with other functions if they are unnecessarily closures in the module. `fix_missing_locations` appears to be another such function with an unnecessary closure. the closure in `dump` cannot be removed without some rewriting of the signature, as it uses variables it closes over. Not sure this would be worth it. -- resolution: rejected -> status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
Aaron Hall <aaronch...@yahoo.com> added the comment: Rejecting and withdrawing with apologies. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
New submission from Aaron Hall <aaronch...@yahoo.com>:
Removing the closure seems to make the function about 10% faster.
Original source code at:
https://github.com/python/cpython/blob/3.6/Lib/ast.py#L40
Empirical evidence: astle.py
import timeit
from ast import literal_eval as orig_literal_eval
from ast import *
def new_literal_eval(node_or_string):
"""
Safely evaluate an expression node or a string containing a Python
expression. The string or node provided may only consist of the following
Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
sets, booleans, and None.
"""
if isinstance(node_or_string, str):
node_or_string = parse(node_or_string, mode='eval')
if isinstance(node_or_string, Expression):
node_or_string = node_or_string.body
node = node_or_string
if isinstance(node, Constant):
return node.value
elif isinstance(node, (Str, Bytes)):
return node.s
elif isinstance(node, Num):
return node.n
elif isinstance(node, Tuple):
return tuple(map(_convert, node.elts))
elif isinstance(node, List):
return list(map(_convert, node.elts))
elif isinstance(node, Set):
return set(map(_convert, node.elts))
elif isinstance(node, Dict):
return dict((_convert(k), _convert(v)) for k, v
in zip(node.keys, node.values))
elif isinstance(node, NameConstant):
return node.value
elif isinstance(node, UnaryOp) and isinstance(node.op, (UAdd, USub)):
operand = _convert(node.operand)
if isinstance(operand, _NUM_TYPES):
if isinstance(node.op, UAdd):
return + operand
else:
return - operand
elif isinstance(node, BinOp) and isinstance(node.op, (Add, Sub)):
left = _convert(node.left)
right = _convert(node.right)
if isinstance(left, _NUM_TYPES) and isinstance(right, _NUM_TYPES):
if isinstance(node.op, Add):
return left + right
else:
return left - right
raise ValueError('malformed node or string: ' + repr(node))
def main():
print('orig first, then new')
print("'1.01'")
print(min(timeit.repeat(lambda: orig_literal_eval('1.01'
print(min(timeit.repeat(lambda: new_literal_eval('1.01'
print("""'"1.01"'""")
print(min(timeit.repeat(lambda: orig_literal_eval('"1.01"'
print(min(timeit.repeat(lambda: new_literal_eval('"1.01"'
print("'1'")
print(min(timeit.repeat(lambda: orig_literal_eval('1'
print(min(timeit.repeat(lambda: new_literal_eval('1'
if __name__ == '__main__':
main()
Shell:
$ python -m astle
orig first, then new
'1.01'
3.518230145502848
3.274753015923377
'"1.01"'
3.189016693752965
2.906869704238048
'1'
3.40557457956146
3.157061471625788
--
components: Library (Lib)
messages: 304089
nosy: Aaron Hall
priority: normal
severity: normal
status: open
title: Unnecessary closure in ast.literal_eval
type: performance
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28972] Document all "python -m" utilities
Aaron Hall added the comment: I like this idea too, but perhaps it should just be a multi-column bulleted list (under the -m flag at https://docs.python.org/3/using/cmdline.html#interface-options) with links to the respective Standard Library doc? Then we just ensure the documentation for the module is complete with examples for the command line usage. -- nosy: +Aaron Hall ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Aaron Hall added the comment: Serhiy, Not sure what else needs to be done to wrap this up. All checks are passing on the pull request. Thoughts? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31319] Rename idlelib to just idle
Changes by Aaron Hall <aaronch...@yahoo.com>: -- nosy: +Aaron Hall ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31333] Implement ABCMeta in C
Changes by Aaron Hall <aaronch...@yahoo.com>: -- nosy: +Aaron Hall ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31333> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12154] PyDoc Partial Functions
Aaron Hall added the comment:
It seems that this issue is still properly open. (Another open issue seems be
related: http://bugs.python.org/issue30129)
In the docs on partial, we have:
>>> from functools import partial
>>> basetwo = partial(int, base=2)
>>> basetwo.__doc__ = 'convert base 2 string to int'
But the help function doesn't find that __doc__:
>>> help(basetwo)
class partial(builtins.object)
| partial(func, *args, **keywords) - new function with partial application
...
Perhaps this could be solved by having PyDoc check for isinstance of a Callable
or making partial an instance of a Function?
>>> type(basetwo)
>>> basetwo.__dict__
{'__doc__': 'convert base 2 string to int'}
>>> type(basetwo)
>>> isinstance(basetwo, partial)
True
>>> from types import FunctionType; from collections import Callable
>>> isinstance(basetwo, FunctionType)
False
>>> isinstance(basetwo, Callable)
True
The partial repr seems to get us close:
>>> repr(basetwo)
"functools.partial(, base=2)"
I haven't dug much further into this, but I'm interested in doing the work to
finish it, and I don't think the patch submitted 6 years ago quite gets us
there. Any other thoughts before I decide to give it a go?
--
nosy: +Aaron Hall
versions: +Python 3.7 -Python 3.3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12154>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Aaron Hall added the comment: I tweaked the docs a little more this morning, but I believe I am done making any further changes unless so requested. This issue doesn't say it's assigned to anyone. Is there anything else that needs to happen here? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Aaron Hall added the comment: > Please also add yourself to Misc/ACKS. Done! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Aaron Hall added the comment: Added news, working on tests -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Changes by Aaron Hall <aaronch...@yahoo.com>: -- pull_requests: +2030 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
Aaron Hall added the comment: Bumping this - I intend to work on this next, if no objections. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30463] Add __slots__ to ABC convenience class
Changes by Aaron Hall <aaronch...@yahoo.com>: -- pull_requests: +1908 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30449] Improve __slots__ datamodel documentation
Aaron Hall added the comment: I created a new PR based on rhettinger's feedback (which on consideration was quite correct) with a fresh branch from master. Terseness is retained, and I think this revision makes the documentation more correct and complete. The rewording makes the behavior more clear (IMHO). No example code is needed for this revision, so I didn't give any, but one or two class definitions might be desirable. Feedback is quite welcome! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30449] Improve __slots__ datamodel documentation
Changes by Aaron Hall <aaronch...@yahoo.com>: -- pull_requests: +1905 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30463] Add __slots__ to ABC convenience class
New submission from Aaron Hall: We have __slots__ with other ABC's, see http://bugs.python.org/issue11333 and http://bugs.python.org/issue21421. There are no downsides to having empty slots on a non-instantiable class, but it does give the option of denying __dict__ creation for subclassers. The possibility of breaking is for someone using __slots__ but relying on __dict__ creation in a subclass - they will have to explicitly add "__dict__" to __slots__. Since we have added __slots__ to other ABC's, I will provide a PR soon on this. Diff should look like this (in Lib/abc.py): class ABC(metaclass=ABCMeta): """Helper class that provides a standard way to create an ABC using inheritance. """ - pass + __slots__ = () (I also want to add a test for this, and ensure other ABC's also have this if they don't.) -- messages: 294389 nosy: Aaron Hall priority: normal severity: normal status: open title: Add __slots__ to ABC convenience class ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30449] Improve __slots__ datamodel documentation
Aaron Hall added the comment: I've been working on this section quite a lot, trying to improve the flow of content (which in the prior revision is a bit of a mish-mash of information in the "Notes on using __slots__ section") - I intend to move some of that information into the exposition/introduction. I have also been reviewing my changes and actively working on it with a volunteer at the PyCon sprints, Joshua Goldin. Will submit a pull request soon, tonight or tomorrow morning. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30449] Improve __slots__ datamodel documentation
New submission from Aaron Hall: The __slots__ documentation in the datamodel needs improvement. For example: > When inheriting from a class without __slots__, the __dict__ attribute of > that class will always be accessible, so a __slots__ definition in the > subclass is meaningless. The __slots__ definition for such a subclass is not meaningless: other slots declared will still be used, and the __dict__ will not be instantiated unless it is looked for (although this may be an implementation detail). > The action of a __slots__ declaration is limited to the class where it is > defined. As a result, subclasses will have a __dict__ unless they also define > __slots__ (which must only contain names of any additional slots). That's not quite right either. The action of a __slots__ declaration is not entirely limited to the class where it is defined. They can have implications for multiple inheritance, and child classes will have access to those slots. I have some changes I'd like to make to the entire section on __slots__, and I'll be providing a pull request soon. -- assignee: docs@python components: Documentation messages: 294305 nosy: Aaron Hall, docs@python priority: normal severity: normal status: open title: Improve __slots__ datamodel documentation versions: Python 2.7, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
New submission from Aaron Hall: Based on the data-model documentation (https://docs.python.org/2/reference/datamodel.html#invoking-descriptors) and the dotted lookup behavior, the follow definitions are correct: "If the descriptor defines __set__() and/or __delete__(), it is a data descriptor; if it defines neither, it is a non-data descriptor." def has_data_descriptor_attrs(obj): return set(['__set__', '__delete__']) & set(dir(obj)) def is_data_descriptor(obj): return bool(has_data_descriptor_attrs(obj)) However, the inspect module has the following, which is also reflected in the descriptor how-to (https://docs.python.org/2/howto/descriptor.html#descriptor-protocol): "If an object defines both __get__() and __set__(), it is considered a data descriptor." def isdatadescriptor(object): """Return true if the object is a data descriptor. Data descriptors have both a __get__ and a __set__ attribute...""" if isclass(object) or ismethod(object) or isfunction(object): # mutual exclusion return False tp = type(object) return hasattr(tp, "__set__") and hasattr(tp, "__get__") I'm willing to sign a contributor release and fix myself. -- messages: 258168 nosy: Aaron Hall priority: normal severity: normal status: open title: Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to) type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
