[Python-Dev] PEP 380
fuzzyman at voidspace.org.uk
Sat Nov 26 14:46:12 CET 2011
On 26/11/2011 07:46, Maciej Fijalkowski wrote:
> On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan<ncoghlan at gmail.com> wrote:
>> On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
>> <fuzzyman at voidspace.org.uk> wrote:
>>> On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
>>>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum<guido at python.org> wrote:
>>>>> Mea culpa for not keeping track, but what's the status of PEP 380? I
>>>>> really want this in Python 3.3!
>>>> There are two relevant tracker issues (both with me for the moment).
>>>> The main tracker issue for PEP 380 is here: http://bugs.python.org/issue11682
>>>> That's really just missing the doc updates - I haven't had a chance to
>>>> look at Zbyszek's latest offering on that front, but it shouldn't be
>>>> far off being complete (the *text* in his previous docs patch actually
>>>> seemed reasonable - I mainly objected to way it was organised).
>>>> However, the PEP 380 test suite updates have a dependency on a new dis
>>>> module feature that provides an iterator over a structured description
>>>> of bytecode instructions: http://bugs.python.org/issue11816
>>> Is it necessary to test parts of PEP 380 through bytecode structures rather than semantics? Those tests aren't going to be usable by other implementations.
>> The affected tests aren't testing the PEP 380 semantics, they're
>> specifically testing CPython's bytecode generation for yield from
>> expressions and disassembly of same. Just because they aren't of any
>> interest to other implementations doesn't mean *we* don't need them :)
>> There are plenty of behavioural tests to go along with the bytecode
>> specific ones, and those *will* be useful to other implementations.
> I'm with nick on this one, seems like a very useful test, just
> remember to mark it as @impl_detail (or however the decorator is
Fair enough. :-)
If other tests are failing (the semantics are wrong) then having a test
that shows you the semantics are screwed because the bytecode has been
incorrectly generated will be a useful diagnostic tool.
On the other hand it is hard to see that bytecode generation could be
"wrong" without it affecting some test of semantics that should also
fail - so as tests in their own right the bytecode tests *must* be
superfluous (or there is some aspect of the semantics that is *only*
tested through the bytecode and that seems bad, particularly for other
All the best,
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
More information about the Python-Dev