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.

Author ncoghlan
Recipients benjamin.peterson, eric.araujo, larry, ncoghlan, pitrou, python-dev, scoder, terry.reedy, yselivanov
Date 2014-02-03.11:38:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7f0sduwCAKVqCzMU2pphus3PbzZtSZCyR5UAgtw=PiQgQ@mail.gmail.com>
In-reply-to <1391425141.92.0.312721806564.issue17159@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2014-02-03 11:38:41ncoghlansetrecipients: + ncoghlan, terry.reedy, pitrou, scoder, larry, benjamin.peterson, eric.araujo, python-dev, yselivanov
2014-02-03 11:38:41ncoghlanlinkissue17159 messages
2014-02-03 11:38:40ncoghlancreate