<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 20 Feb 2014, at 08:09, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 20 February 2014 16:42, Ronald Oussoren <<a href="mailto:ronaldoussoren@mac.com">ronaldoussoren@mac.com</a>> wrote:<br><blockquote type="cite"><br>On 17 Feb 2014, at 00:43, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><br><blockquote type="cite"><br>On 17 Feb 2014 08:36, "Greg Ewing" <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br><blockquote type="cite"><br>Larry Hastings wrote:<br><br><blockquote type="cite">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.<br></blockquote><br><br>But wouldn't that be introducing a new feature into a<br>maintenance release? (I.e. some functions that didn't<br>have introspectable signatures before would gain them.)<br></blockquote><br>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.<br><br>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.<br><br>The key thing is to make sure to postpone any changes that impact *semantics* (like adding keyword argument support).<br></blockquote><br>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 :-)<br></blockquote><br>Heh, you must have managed to miss all the Argument Clinic debates -<br>"semantics" there is shorthand for "the semantics of the call" :)<br></div></blockquote><div><br></div>I skipped most of that discussion, due to the sheer volume and limited time to add something meaningful to that discussion.</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>It turns out there are some current C signatures where we either need<br>to slightly change the semantics of the API or else add new features<br>to the inspect module before we can represent them properly at the<br>Python layer. So, for the life of Python 3.4, those are off limits for<br>conversion, and we'll sort them out as part of PEP 457 for 3.5.<br></div></blockquote><div><br></div>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). </div><div><br></div><div>I totally agree that changing the signature of functions should wait for 3.5, but that’s the easy bit.</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>However, there are plenty of others where the signature *can* be<br>adequately represented in 3.4, they just aren't (yet). So the approach<br>Larry has taken is to declare that "could expose valid signature data,<br>but doesn't" counts as a bug fix for Python 3.4 maintenance release<br>purposes. We'll make sure the porting section of the What's New guide<br>addresses that explicitly for the benefit of anyone porting<br>introspection tools to Python 3.4 (having all of the argument<br>introspection in the inspect module be based on inspect.signature and<br>various enhancements to inspect.signature itself has significantly<br>increased the number of callables that now support introspection).<br></div></blockquote><div><br></div><div>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 :-)</div><div><br></div><div>To end on a positive not, I do like signature objects, and have added support for them to PyObjC to enrich its introspection capabilities.</div><div><br></div><div>Ronald</div><div><br></div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Cheers,<br>Nick.<br><br>--<span class="Apple-converted-space"> </span><br>Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a><span class="Apple-converted-space"> </span> | Brisbane, Australia</div></blockquote></div><br></body></html>