[Python-Dev] Python 3.4: What to do about the Derby patches

[Nick Coghlan]

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" :)

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   |   ncoghlan at gmail.com   |   Brisbane, Australia