On 18 Feb 2014 03:37, "Larry Hastings" <la...@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 <la...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com >
_______________________________________________ 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