On 20 January 2014 20:16, Larry Hastings <la...@hastings.org> wrote: > > > On 01/19/2014 08:30 PM, Nick Coghlan wrote: > > Guido, Larry and I thrashed out the required semantics for parameter groups > at PyCon US last year (and I believe the argument clinic PEP describes those > accurately). > > They're mainly needed to represent oddball signatures like range() and > slice(). > > However, I'm inclined to say that the affected functions should simply not > support introspection until Python 3.5. > > It's not just a matter of the data model, there's also the matter of > defining the string representation. > > > Au contraire!, says the man writing patches.
When I wrote that, I was thinking we had made inspect.Signature.__repr__ produce a nice string format, but then I noticed in the REPL today that we never got around to doing that - I think because we didn't know how to handle positional-only arguments, which already can't be expressed as Python syntax. (I haven't checked if we have an RFE filed anywhere) However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5. We're already in beta, we're already introducing a lot of code churn to get the C level callables that *can* have their signatures expressed as Python syntax converted, so where's the harm to users in saying that C level callables with non-Python signatures still don't support introspection in Python 3.4? Almost no C level callables support programmatic introspection in Python 3.3, so even what inspect.signature will already provide in beta 3 is a big step forward. While the text string used to communicate between Argument Clinic and inspect.signature will be private, the representation on inspect.Signature objects will be a new *public* API. As the discussions between you, me and Yury show, I don't think there's an immediately obvious best answer of how to do that. Your suggestion of just adding the group numbers to the Parameter objects would *work*, but it's not very Pythonic - we have container types that support nesting, which seems like a more natural structure for indicating parameter groups at the Python level. Essentially, the group number proposal feels like the kind of low level interface returned by getfullargspec(), not the kind of high level interface defined for inspect.Signature in PEP 362. It's going to take a while to come up with a public API for this aspect of C level signatures that feels right to at least you, me and Yury, and the beta period *really* isn't the right time to be doing that. If other changes like the binary interpolation proposals and adding the PEP 451 based target attributes to runpy can wait until Python 3.5 due to feature freeze, then I think adding full C level signature support to inspect.Signature can also wait. That way, you can resurrect PEP 457, recast it as proposing an *output* format for inspect.Signature.__repr__(), add an inspect.Signature.fromstr() API that can use it to create a signature object from __text_signature__ attributes (rather than relying on ast.parse), add the optional group support and do it *right*, rather than trying to squeeze it in as a new public API during the beta period, which may lock us in to supporting an introspection API we later regret. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
