Nick Coghlan added the comment: Stefan is suggesting that rather than emulating the Python signature line (which is a concise human readable notation that with the PEP 457 tweaks will handle even the most obscure custom argument parsing, whether that parsing is implemented in C or in Python), it would make more sense to instead emulate the confusing jumble of CPython implementation details exposed by Python level function and code objects. That ducktyping has been the traditional way to support signature introspection for anyone that didn't have the ability to change how the inspect module works.
However, I'm not sure *how* generating and storing an assortment of hard to interpret lists and strings and mappings would qualify as being simpler than generating and storing a single string that is only converted into real signature data if requested. Once __text_signature__ becomes a public API in 3.5 (as part of PEP 457), inspect shouldn't need to special case any type ever again: it will be up to the type to set __text_signature__ properly instead. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17159> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
