On 20 February 2014 16:42, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > On 17 Feb 2014, at 00:43, Nick Coghlan <ncogh...@gmail.com> wrote: > >> >> On 17 Feb 2014 08:36, "Greg Ewing" <greg.ew...@canterbury.ac.nz> wrote: >> > >> > Larry Hastings wrote: >> > >> >> 3) We hold off on merging the rest of the Derby patches until after 3.4.0 >> >> final ships, then we merge them into the 3.4 maintenance branch so they >> >> go into 3.4.1. >> > >> > >> > But wouldn't that be introducing a new feature into a >> > maintenance release? (I.e. some functions that didn't >> > have introspectable signatures before would gain them.) >> >> From a compatibility point of view, 3.4.0 will already force introspection >> users and tool developers to cope with the fact that some, but not all, >> builtin and extension types provide valid signature data. Additional clinic >> conversions that don't alter semantics then just move additional callables >> into the "supports programmatic introspection" category. >> >> It's certainly in a grey area, but "What's in the best interest of end >> users?" pushes me in the direction of counting clinic conversions that don't >> change semantics as bug fixes - they get improved introspection support >> sooner, and it shouldn't make life any harder for tool developers because >> all of the adjustments for 3.4 will be to the associated functional changes >> in the inspect module. >> >> The key thing is to make sure to postpone any changes that impact >> *semantics* (like adding keyword argument support). > > But there is a semantic change: some functions without a signature in 3.4.0 > would have a signature in 3.4.1. That's unlikely to affect user code much > because AFAIK signatures aren't used a lot yet, but it is a semantic change > non the less :-)
Heh, you must have managed to miss all the Argument Clinic debates - "semantics" there is shorthand for "the semantics of the call" :) It turns out there are some current C signatures where we either need to slightly change the semantics of the API or else add new features to the inspect module before we can represent them properly at the Python layer. So, for the life of Python 3.4, those are off limits for conversion, and we'll sort them out as part of PEP 457 for 3.5. However, there are plenty of others where the signature *can* be adequately represented in 3.4, they just aren't (yet). So the approach Larry has taken is to declare that "could expose valid signature data, but doesn't" counts as a bug fix for Python 3.4 maintenance release purposes. We'll make sure the porting section of the What's New guide addresses that explicitly for the benefit of anyone porting introspection tools to Python 3.4 (having all of the argument introspection in the inspect module be based on inspect.signature and various enhancements to inspect.signature itself has significantly increased the number of callables that now support introspection). Cheers, 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
