On 20 Feb 2014, at 08:09, Nick Coghlan <ncogh...@gmail.com> wrote: > 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" :)
I skipped most of that discussion, due to the sheer volume and limited time to add something meaningful to that discussion. > > 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. That much I noticed, and IIRC it was noticed fairly early on in Argument Clinic’s history that there are C functions that have an API that cannot easily be represented in a pure Python function (other than using ‘*args, **kw’ and manually parsing the argument list). I totally agree that changing the signature of functions should wait for 3.5, but that’s the easy bit. > > 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). I can live with that, but don’t really agree that exposing new signature data is a bug fix. But maybe I’m just too conservative :-) To end on a positive not, I do like signature objects, and have added support for them to PyObjC to enrich its introspection capabilities. Ronald > > 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
