[issue32752] no information about accessing typing.Generic type arguments
Jared Deckard added the comment: typing_inspect is now filled with python version checks for 3.7. The implementation got significantly more complex when differentiating generics at runtime. 3.6 was undocumented, but the OO API was intuitive: >>> T = typing.Union[int, float] >>> assert T.__class__ == typing.Union >>> assert T.__args__ == (int, float) 3.7 is less convenient and less consistent: >>> T = typing.Union[int, float] >>> assert T.__class__ == typing._GenericAlias >>> assert T.__origin__ == typing.Union >>> L = typing.List[int] >>> assert L.__class__ == typing._GenericAlias >>> assert L.__origin__ == list -- nosy: +Jared Deckard ___ Python tracker <https://bugs.python.org/issue32752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Jared Deckard added the comment: That is correct. (Thank you for whipping up a repro script from my description). I appreciate the work around, but it is nearly as verbose as manually duplicating the parameters on the child and I would have to type up a large comment block to educate future developers on the hack. Is there some documentation I am missing or is the "resolve" conflict handler broken? > The parents= argument takes a list of ArgumentParser objects, collects all > the positional and optional actions from them, and adds these actions to the > ArgumentParser object being constructed. https://docs.python.org/3.6/library/argparse.html#parents It would be nice if the "error" conflict handler ignored conflicts when the actions are identical. It should be expected that the "resolve" conflict handler would not modify the parents. It is exhibiting undocumented and undesirable side effect, which indicates to me that it is a bug not a missing feature. As for the patch, I'm not sure why you would ever want "action_copy" to be False. It seems like creating copies to insulate the originals ignores the underlying issue that these parents are being mutated when the operation implies a union of properties with no side effects. I don't think the fix for this should be behind an optional flag, I think the fix is to update "resolve" to take into consideration multiple parents like the custom conflict handler in your sample. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Jared Deckard added the comment: Adding back components and version data I unintentionally removed in http://bugs.python.org/msg262314 -- components: +Documentation, Tests versions: +Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Jared Deckard added the comment: This behavior is preventing me from using more than one parent parser. My use case is a convenience subcommand that performs two existing subcommands, therefore logically its subparser is required to support the arguments of both subparsers. The only conflict is the "help" argument, which is annoying, but setting the conflict handler to "resolve" on the child subparser should just ignore the first parent's "help" argument in favor of the second parent. Instead the "resolve" conflict handler breaks the first parent and causes it to output the help info no matter what arguments are given to it. I am forced to only include one parent and manually duplicate the arguments for any additional parents. -- components: -Documentation, Tests nosy: +deckar01 versions: +Python 2.7 -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
