This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: unify types for lib2to3.pytree.Base.children
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, JelleZijlstra, benjamin.peterson, jreese, lukasz.langa, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2018-06-27 20:38 by jreese, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 7977 closed jreese, 2018-06-27 20:41
Messages (7)
msg320616 - (view) Author: John Reese (jreese) * Date: 2018-06-27 20:38
When type checking applications using lib2to3, the difference in types for lib2to3.pytree.Base.children versus Node.children makes it difficult to accept both leaves and nodes and programatically work with child nodes/leaves.  Base/Leaf both have `children` defined as an empty Tuple, while Node defines it as an empty list.  It would be more useful for Base/Leaf to also use an empty list, so that the type is the same, regardless of which type of object you are given.
msg320664 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-06-28 12:21
Empty list takes more memory and more time for creating than an empty tuple (the latter is just a singleton). Since all Node and Leaf instances share the same children by default, making it a list is errorprone.

What is the problem of having an empty tuple instead of an empty list?
msg320682 - (view) Author: John Reese (jreese) * Date: 2018-06-28 18:14
The problem I'm trying to solve is around functions that operate on a Union[Leaf, Node], and want to be able to do things like `grandchildren = node.children[0].children + node.children[1].children` (contrived example, but point being tuple+list=TypeError while list+tuple=OK).  There are similar cases around list methods not being available for tuples.  In both cases, as is, the function needs to do some amount of type checking at runtime of each child to determine what operations can be done.  Also, IMO, from a type annotation perspective, having a child class that uses a different type for an attribute from the base class is an anti-pattern, or weird at best.

re. error prone:  Since the expectation in lib2to3 is already that fixers shouldn't be modifying `node.children` directly, I don't see how this makes anything more error prone.  Base/Leaf objects lack those methods for modifications, so unless the code is already being a bad actor, the situation isn't changed.
msg320685 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-06-28 19:47
Concatenating list and tuple (or tuple and list) you can write as:

grandchildren = [*node.children[0].children, *node.children[1].children]

The only list methods not available for tuples are mutating methods (using them with a shared empty list would be a bug), and copy() (a[:] and list(a) work with both lists and tuples).

>>> sorted(set(dir(list)) - set(dir(tuple)))
['__delitem__', '__iadd__', '__imul__', '__reversed__', '__setitem__', 'append', 'clear', 'copy', 'extend', 'insert', 'pop', 'remove', 'reverse', 'sort']
msg351999 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2019-09-11 17:41
Isn't children annotated as List in typeshed?
msg361994 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-02-14 18:23
> Isn't children annotated as List in typeshed?

Yes, lib2to3.pytree.Base.children is annotated as a list of (Node or Leafs)
https://github.com/python/typeshed/blob/ea0a9c2bd6f6a69c3e49b47870e0109d98316fc6/stdlib/2and3/lib2to3/pytree.pyi#L23
msg411440 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2022-01-24 03:09
lib2to3 is deprecated as of Python 3.11, and there's an available workaround. I don't think it still makes sense to change anything here.
History
Date User Action Args
2022-04-11 14:59:02adminsetgithub: 78164
2022-01-24 03:09:05JelleZijlstrasetstatus: open -> closed

nosy: + JelleZijlstra
messages: + msg411440

resolution: wont fix
stage: patch review -> resolved
2020-02-14 18:23:16BTaskayasetnosy: + BTaskaya
messages: + msg361994
2019-09-11 17:41:08benjamin.petersonsetmessages: + msg351999
2018-06-28 19:47:30serhiy.storchakasetmessages: + msg320685
2018-06-28 18:14:49jreesesetmessages: + msg320682
2018-06-28 12:21:11serhiy.storchakasetnosy: + serhiy.storchaka, benjamin.peterson
messages: + msg320664
2018-06-27 20:41:21jreesesetkeywords: + patch
stage: patch review
pull_requests: + pull_request7588
2018-06-27 20:38:19jreesecreate