[Python-Dev] Python 3.4: What to do about the Derby patches
ronaldoussoren at mac.com
Thu Feb 20 08:24:39 CET 2014
On 20 Feb 2014, at 08:09, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 20 February 2014 16:42, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> On 17 Feb 2014, at 00:43, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On 17 Feb 2014 08:36, "Greg Ewing" <greg.ewing at 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.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev