[Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

[Nick Coghlan]

On 11 September 2016 at 09:41, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Sep 9, 2016 at 11:39 AM, Barry Warsaw <barry at python.org> wrote:
>> On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote:
>>
>>>Are there any downsides to explicitly specifying that all dicts are ordered?
>>>People will inevitably start relying on this behaviour, and this will
>>>essentially become the *de-facto* spec, so alternative Python implementations
>>>will have to follow suit anyway.
>>
>> It *might* make sense to revisit this once 3.5 is no longer maintained at all,
>> but I think Guido's exactly right in his analysis.  If people start relying on
>> all dicts being ordered now, their code won't be compatible with both 3.5 and
>> 3.6, and I think it's important to emphasize this to developers.
>
> I feel like I'm missing something here... by this reasoning, we should
> *never* change the language spec when new features are added. E.g. if
> people use async/await in 3.5 then their code won't be compatible with
> 3.4, but async/await are still part of the language spec. And in any
> case, the distinction between "CPython feature" and "Python
> language-spec-guaranteed feature" is *extremely* arcane and
> inside-basebally -- it seems really unlikely that most users will even
> understand what this distinction means, never mind let it stop them
> from writing CPython-and-PyPy-specific code. Emphasizing that this is
> a new feature that only exists in 3.6+ of course makes sense, I just
> don't understand why that affects the language spec bit.

To conform with the updated language spec, implementations just need
to use collections.OrderedDict in 3 places:

- default return value of __prepare__
- underlying storage type for __dict__ attributes
- storage type for passing kwargs to functions

They don't *necessarily* have to change their builtin dict type to be
order-preserving, as we're not deprecating collections.OrderedDict,
and we're not adding the additional methods offered by OrderedDict to
the base type.

So for normal development, the guidance is still "use
collections.OrderedDict explicitly if you need to preserve insertion
order", as being more explicit gives compatibility with CPython < 3.6,
and with any alternate implementations that take the path of using
collections.OrderedDict selectively rather than changing the behaviour
of their dict builtin (which was the original plan for CPython).

> (OTOH it doesn't matter that much anyway... the language spec is
> definitely a useful thing, but it's largely aspirational in practice
> -- other implementations target CPython compatibility more than they
> target language spec compatibility.)

The distinction is that there are cases where we *do* convince library
and framework authors to change their code for cross-version and
cross-implementation compatibility - the popularity of explicit
context management being one of the most significant examples of that,
as it's far more necessary on implementations that don't use automatic
reference counting the way CPython does.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia