Author larry
Recipients benjamin.peterson, eric.araujo, larry, ncoghlan, pitrou, python-dev, scoder, terry.reedy, yselivanov
Date 2014-02-02.10:20:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1391336437.39.0.247680865555.issue17159@psf.upfronthosting.co.za>
In-reply-to
Content
In case a little background would help: while developing support for '__text_signature__' I had to move the test and the from_builtin() call to the top.  It used to be more in the middle-ish.  I don't have notes specifically on why I moved it, but I dimly recall that if I didn't try from_builtin first, there were other approaches that would succeed on the callable, that approach would fail on a builtin, so it'd throw an exception, and from_builtin wouldn't get a chance to try.

Also, I assumed that anything that had a __text_signature__ wasn't going to have any other kind of signature information.  Therefore, if the object had a __text_signature__ attribute, then I already knew that's the best approach and it should definitely be first.

Also also, I remember specifically that the isinstance(type) code would fail builtin classes.  But there's no generic way (that I know of) to tell whether a class is a user class or a builtin class.  So I wanted from_builtin to try handling a class first before the isinstance(type) class.

Are there callables in CPython that have *both* a __text_signature__ *and* have signature information derivable from another source, where you *don't* want to use __text_signature__?


Stefan: yes, you can write any garbage you want after "sig=(" and the C function that detects signatures will still assume you have a text signature.  That reminds me of a good joke.

Patient: Doctor, it hurts whenever I move my arm in this funny way.  *demonstrates*
Doctor: Well, then, don't do that.

I would be very interested if you knew of docstrings in the wild that innocently start with "sig=(" and yet aren't intended to be text signatures compatible with inspect.Signature.
History
Date User Action Args
2014-02-02 10:20:37larrysetrecipients: + larry, terry.reedy, ncoghlan, pitrou, scoder, benjamin.peterson, eric.araujo, python-dev, yselivanov
2014-02-02 10:20:37larrysetmessageid: <1391336437.39.0.247680865555.issue17159@psf.upfronthosting.co.za>
2014-02-02 10:20:37larrylinkissue17159 messages
2014-02-02 10:20:36larrycreate