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

[Nick Coghlan]

On 18 Feb 2014 03:37, "Larry Hastings" <larry at hastings.org> wrote:
>
>
> On 02/16/2014 04:03 PM, Victor Stinner wrote:
>>
>> Hi,
>>
>> The PEP 436 is still a draft and not mentionned in Python 3.4
>> changelog. The PEP proposes to add a DSL, not to modify all modules
>> implemented in C. I think that it should be marked as Final and
>> mentionned in the changelog.
>> http://www.python.org/dev/peps/pep-0436/
>
>
> I need to clean it up and submit it for final inspection.  This is on my
to-do list for before 3.4.0 final.
>
>
>> 2014-02-16 19:31 GMT+01:00 Larry Hastings <larry at hastings.org>:
>>>
>>> 1) We merge the Derby patch for the builtins module into 3.4, simply
because
>>> it will "demo well".
>>
>> Where is the issue to implement this feature? Anyway, I expect a huge
>> patch which is non-trivial and so very risky for such a very important
>> module :-/ It's too late IMO.
>
>
> http://bugs.python.org/issue20184
>
> The point is that it *is* trivial and not particularly risky.  Doing this
right means that we execute essentially the same statements in the same
order, merely split across two functions, and with a slightly different
docstring.  Literally the only detectable runtime difference that should
exist after applying the patch is that the functions now publish docstrings.

(Last "docstrings" should be "introspectable signatures")

The ones which weren't trivial, either won't be changed at all until 3.5
(with a comment in the existing patch explaining why not), or else have had
their automated generation disabled after the initial conversion so I could
move them back closer to their existing behaviour.

I also discovered that gdb depends on the *exact* signature of the id() C
API, but Argument Clinic was able to handle that.

That said, I still recommend leaving this particular change until 3.4.1 at
this stage of the release cycle - it's a nice-to-have, not a must have, and
I think there are more important things to focus on right now (like
handling any identified regressions relative to 3.3, since the release
candidates see a higher level of third party testing than any of the
earlier pre-releases).

The current patch also can't be applied as is - it needs to be regenerated
to account for the signature format change and to move the argument parsing
helpers out to a separate file.

Something I think we *should* do (and I'm willing to take care of) is
update the What's New to say explicitly that adding programmatic
introspection support to a function implemented in C is now considered a
bug fix (as long as it can be done without changing semantics and the
inspect module can handle it), and so more builtin and extension module
APIs will start supporting that over the course of the 3.4.x series. I'll
also find some already converted examples to include in the What's New
description (relying on the converted builtin slots if I have to, but I
suspect some better examples are already available, even without the
builtins converted).

Cheers,
Nick.

>
>
> /arry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140218/572b4755/attachment-0001.html>