Re: [Python-Dev] PEP 487: Simpler customization of class creation
Hi Nick, hi List, thanks for the good comments! I'll update the PEP and the implementation soon, as discussed at the end, I'll do it in C this time. For now just some quick responses: > This part isn't entirely clear to me, so you may want to give some > Python pseudo-code that: I will actually give the actual code, it's just 10 lines, that should be understandable. > - is explicit regarding exactly when this new code runs in the type > creation process > - whether the __set_owner__ hooks are called before or after > __init_subclass__ runs, or only when the subclass calls up to > super().__init_subclass__, and the implications of each choice (either > descriptors see a partially initialised class object, or init_subclass > sees partially initialised descriptor objects, or that choice is > delegated to individual subclasses) > - how the list of objects to be checked for "__set_owner__" methods is > retrieved (presumably via "ns.items()" on the class definition > namespace, but the PEP should be explicit) > > For the second point, my personal preference would be for descriptors > to have their owner set first and independently of __init_subclass__ > super calls (as it seems more likely that __init_subclass__ will > depend on having access to fully initialised descriptors than the > other way around). I intuitively programmed it the other way around, but I get your point and will change it. I agree that it should not be done in super().__init_subclass__ as people often forget to call it, or do weird things. > Honestly though, I'm not sure this additional user-visible complexity > is worth it - "The default type metaclass has this new behaviour" is a > lot easier to document and explain than "We added a new opt-in > alternate metaclass that you can use if you want, and in the next > version that will just become an alias for the builtin types again". > We'd also end up being stuck with types.Type and types.Object as > aliases for the type and object builtins forever (with the associated > "How does 'class name:' or 'class name(object)' differ from 'class > name(types.Object)'?" question and "It doesn't, unless you're using > Python 3.6" answer for folks learning the language for the first > time). My idea with a stepped approach was to have a chance to look how people use the feature, so that when we make it standard eventually we actually get it right. In the end, this is a maintainability question. I am fully OK with following experienced core developers here, so if the general idea here is that a two-step approach is not needed, then no problem, let's do it in the Python core directly! Greetings Martin ___ 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
Re: [Python-Dev] When to use EOFError?
On 22.06.16 00:17, Victor Stinner wrote: When loading truncated data with pickle, I expect a pickle error, not a generic ValueError nor EOFError. Many modules raise EOFError when read truncated data. ___ 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
Re: [Python-Dev] When to use EOFError?
On 22.06.16 19:22, André Malo wrote: I often concatenate multiple pickles into one file. When reading them, it works like this: try: while True: yield pickle.load(fp) except EOFError: pass In this case the truncation is not really unexpected. Maybe it should distinguish between truncated-in-the-middle and truncated-because-empty. (Same goes for marshal) This is interesting application, but works only for non-truncated data. If the data is truncated, you just lose the last item without a notice. ___ 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
Re: [Python-Dev] Compact ordered dict is not ordered for split table. (was: PEP XXX: Compact ordered dict
On Jun 21, 2016 11:12 AM, "INADA Naoki" wrote:
>
> I'm sorry, but I hadn't realized which compact ordered dict is
> not ordered for split table.
>
> For example:
> >>> class A:
> ... ...
> ...
> >>> a = A()
> >>> b = A()
> >>> a.a = 1
> >>> a.b = 2
> >>> b.b = 3
> >>> b.a = 4
> >>> a.__dict__.items()
> dict_items([('a', 1), ('b', 2)])
> >>> b.__dict__.items()
> dict_items([('a', 4), ('b', 3)])
>
>
> This doesn't affects to **kwargs and class namespace.
>
> But if we change the language spec to dict preserves insertion order,
> this should be addressed.
Is that really how it works? From my understanding of PEP 412, they should
have different keysets, because one diverged in keys from the other at an
intermediate step.
Another idea (though it has several issues and seems like a step backward):
a split-table dict can have a separate iteration list, indexing into the
entry table. There are ways to share iteration lists, and make it so that
adding the same keys in the same order each time results in the same
iteration list each time, but this costs overhead. There might be ways of
reducing the overhead, or the overhead might be replacing bigger overhead,
but we should decide if the behavior is what we want in the first place.
___
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
Re: [Python-Dev] Compact ordered dict is not ordered for split table. (was: PEP XXX: Compact ordered dict
On Sun, Jun 26, 2016 at 8:40 AM, Franklin? Lee
wrote:
> On Jun 21, 2016 11:12 AM, "INADA Naoki" wrote:
>>
>> I'm sorry, but I hadn't realized which compact ordered dict is
>> not ordered for split table.
>>
>> For example:
>> >>> class A:
>> ... ...
>> ...
>> >>> a = A()
>> >>> b = A()
>> >>> a.a = 1
>> >>> a.b = 2
>> >>> b.b = 3
>> >>> b.a = 4
>> >>> a.__dict__.items()
>> dict_items([('a', 1), ('b', 2)])
>> >>> b.__dict__.items()
>> dict_items([('a', 4), ('b', 3)])
>>
>>
>> This doesn't affects to **kwargs and class namespace.
>>
>> But if we change the language spec to dict preserves insertion order,
>> this should be addressed.
>
> Is that really how it works? From my understanding of PEP 412, they should
> have different keysets, because one diverged in keys from the other at an
> intermediate step.
See here
https://github.com/python/cpython/blob/3.5/Objects/dictobject.c#L3855-L3866
When keys is resized,
1) If refcnt of old keys is one, new keys are shared with instances
created after.
2) Otherwise, sharing key of the class is totally disabled.
> Another idea (though it has several issues and seems like a step backward):
> a split-table dict can have a separate iteration list, indexing into the
> entry table. There are ways to share iteration lists, and make it so that
> adding the same keys in the same order each time results in the same
> iteration list each time, but this costs overhead. There might be ways of
> reducing the overhead, or the overhead might be replacing bigger overhead,
> but we should decide if the behavior is what we want in the first place.
>
I'll test some ideas.
But for now, I'll update http://bugs.python.org/issue27350 to stop key
sharing when
order is different. (a. deletion is not allowed, and insertion order
must be same).
It may reduce key sharing rate, but total memory usage must not increase so
much thanks to compact dict.
--
INADA Naoki
___
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
