Re: [Python-Dev] RFC: PEP 509: Add a private version to dict
> From Armin Rigo > Sent: Thursday, April 14, 2016 4:42 PM > To: Victor Stinner > Cc: Python Dev > Subject: Re: [Python-Dev] RFC: PEP 509: Add a private version to dict > > Hi Victor, > > On 14 April 2016 at 17:19, Victor Stinner wrote: > > Each time a dictionary is created, the global > > version is incremented and the dictionary version is initialized to the > > global version. > > A detail, but why not set the version tag of new empty dictionaries to > zero, always? Same after a clear(). This would satisfy the > condition: equality of the version tag is supposed to mean "the > dictionary content is precisely the same". >From Victor's original post: "Globally unique identifier is a requirement for Yury's patch optimizing method calls ( https://bugs.python.org/issue26110 ). It allows to check for free if the dictionary was replaced." I think it's a good design idea, and there's no chance that this counter will ever overflow (I think Victor is using 64-bit unsigned integer). I don't think there's really any drawback to using a global vs per-dict counter (but Victor is better placed to answer that :)) -Emanuel ~Ducks lay where no programmer has ever been~ ___ 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] C99
> From: Python-Dev [mailto:python-dev- > bounces+vgr255=live...@python.org] On Behalf Of tritium- > l...@sdamon.com > Sent: Sunday, June 05, 2016 10:35 PM > To: 'Sturla Molden'; python-dev@python.org > Subject: Re: [Python-Dev] C99 > > > -Original Message- > > From: Python-Dev [mailto:python-dev-bounces+tritium- > > list=sdamon@python.org] On Behalf Of Sturla Molden > > Sent: Sunday, June 5, 2016 10:29 PM > > To: python-dev@python.org > > Subject: Re: [Python-Dev] C99 > > > > Guido van Rossum wrote: > > > > > I'm talking about 3rd party extensions. Those may require source > > > compatibility with older Python versions. All I'm asking for is to not > > > require source-level use of C99 features. > > > > This of course removes a lot of its usefulness. E.g. macros cannot be > > replaced by inline functions, as header files must still be plain C89. > > > > > > Sturla Molden > > > > I share Guido's priority there - source compatibility is more important than > smoothing a few of C's rough edges. Correct me if I'm wrong, but I think that Guido meant that the third-party extensions might require their own code (not CPython's) to be compatible with versions of CPython < 3.6, and so PEP 7 shouldn't force them to break their own backwards compatibility. Either way I'm +1 for allowing (but not enforcing) C99 syntax. > Maybe the next breaking change release > this should be considered (python 4000... python 5000?) Let's not! -Emanuel ___ 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] Proper way to specify that a method is not defined for a type
> From: Ethan Furman
> Sent: Tuesday, June 07, 2016 1:38 PM
> To: Python Dev
> Subject: [Python-Dev] Proper way to specify that a method is not defined
for
> a type
(Just so everyone follows, this is a followup of
http://bugs.python.org/issue27242 )
> For binary methods, such as __add__, either do not implement or return
> NotImplemented if the other operand/class is not supported.
>
> For non-binary methods, simply do not define.
>
> Except for subclasses when the super-class defines __hash__ and the
> subclass is not hashable -- then set __hash__ to None.
Should I mention the __hash__ special case in the
NotImplemented/NotImplementedError docs? If people are looking for a way to
declare this specific operation undefined, they'd find it there as well as
the hash() documentation.
> Question:
>
> Are there any other methods that should be set to None to tell the
> run-time that the method is not supported? Or is this a general
> mechanism for subclasses to declare any method is unsupported?
There was a discussion on one of Python-ideas or Python-dev some time ago
about exactly that, but I don't think any consensus was reached. However, I
think it would make sense for e.g. __iter__ and __reversed__ to tell the
interpreter to *not* fall back to the default sequence protocol (well, in
practice that already works, but it gives an unhelpful error message). I'm
not sure how useful it would be for arbitrary methods, though. __bytes__
(which originally sparked the issue) may or may not be a good candidate, I'm
not sure.
While I like the `__magic_method__ = None` approach, I think the main reason
__hash__ supports that is because there are legitimate use cases of
disallowing hashing (i.e. mutable objects which may or may not change hash
during their lifetime), but I don't think the same rationale applies to
everything ("accidentally" iterating over a not-meant-to-be-iterable object
will result in nonsensical data, but it won't bite the user later, unlike
changing hashes which definitely will).
> --
> ~Ethan~
Special-cases-aren't-special-enough-but-they're-still-there'ly yrs,
-Emanuel
___
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] PEP: Ordered Class Definition Namespace
> From: Eric Snow
> Sent: Tuesday, June 07, 2016 1:52 PM
> To: Python-Dev
> Subject: [Python-Dev] PEP: Ordered Class Definition Namespace
>
>
> Currently the namespace used during execution of a class body defaults
> to dict. If the metaclass defines ``__prepare__()`` then the result of
> calling it is used. Thus, before this PEP, if you needed your class
> definition namespace to be ``OrderedDict`` you had to use a metaclass.
Formatting nit: ``dict``
> Specification
> =
>
> * the default class *definition* namespace is now ``OrderdDict``
> * the order in which class attributes are defined is preserved in the
> new ``__definition_order__`` attribute on each class
> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
What does this imply? If I define some __dunder__ methods, will they simply
not be present in __definition_order__? What if I want to keep the order of
those? While keeping the order of these might be meaningless in most cases,
I don't think there's really a huge problem in doing so. Maybe I'm
overthinking it.
> * ``__definition_order__`` is a tuple
> * ``__definition_order__`` is a read-only attribute
> * ``__definition_order__`` is always set:
>
> * if ``__definition_order__`` is defined in the class body then it
> is used
> * types that do not have a class definition (e.g. builtins) have
> their ``__definition_order__`` set to ``None``
> * types for which `__prepare__()`` returned something other than
> ``OrderedDict`` (or a subclass) have their ``__definition_order__``
> set to ``None``
I would probably like a ``type.definition_order`` method, for which the
return value is bound to __definition_order__ when the class is created
(much like the link between ``type.mro`` and ``cls.__mro__``. Additionally
I'm not sure if setting the attribute to None is a good idea; I'd have it as
an empty tuple. Then again I tend to overthink a lot.
> The following code demonstrates roughly equivalent semantics::
>
>class Meta(type):
>def __prepare__(cls, *args, **kwargs):
>return OrderedDict()
>
>class Spam(metaclass=Meta):
>ham = None
>eggs = 5
>__definition_order__ = tuple(k for k in locals()
> if (!k.startswith('__') or
> !k.endswith('__')))
Mixing up C and Python syntax here.
> However, using ``OrderedDict`` for ``type,__dict__`` would obscure the
> relationship with the definition namespace, making it less useful.
> Additionally, doing this would require significant changes to the
> semantics of the concrete dict C-API.
Formatting nit: ``dict``
I'm +1 on the whole idea (one of my common uses of metaclasses was to keep
the definition order *somewhere*). Thank you for doing that!
-Emanuel
___
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] PEP: Ordered Class Definition Namespace
> From: Eric Snow > Sent: Tuesday, June 07, 2016 2:52 PM > To: Émanuel Barry > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP: Ordered Class Definition Namespace > > "dunder" names (not just methods) will not be present in > __definition_order__. I'll add an explanation to the PEP. The gist > of it is that they are reserved for use by the interpreter and will > always clutter up __definition_order__. Since needing dunder names > included in __definition_order__ would be rather exceptional, and > there are other options available, leaving them out by default is a > matter of practicality. Good point. I'll assume that if we need that we'll do something in the metaclass. > What is the value of type.definition_order()? If you need a mutable > copy then pass __definition_order__ to list(). I think I explained it backwards. I meant to have a method on ``type`` (which metaclasses can override at will) which will set what is passed to the resulting __definition_order__ attribute. But it might not be needed, as we can probably sneak that inside the namespace in the metaclass' __new__. > > Additionally > > I'm not sure if setting the attribute to None is a good idea; I'd have it as > > an empty tuple. Then again I tend to overthink a lot. > > None indicates that there is no order. An empty tuple indicates that > there were no attributes. Fair enough. > > -eric -Emanuel ___ 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] PEP 468
> From: zr...@fastmail.com > Subject: [Python-Dev] PEP 468 > > Is there any further thoughts on including this in 3.6? Similar to the > recent discussion on OrderedDict namespaces for metaclasses, this would > simplify / enable a number of type factory use cases where proper > metaclasses are overkill. This feature would also be quite nice in say > pandas where the (currently unspecified) field order used in the > definition of frames is preserved in user-visible displays. As stated by Guido (and pointed out in the PEP): Making **kwds ordered is still open, but requires careful design and implementation to avoid slowing down function calls that don't benefit. The PEP has not been updated in a while, though. Python 3.5 has been released, and with it a C implementation of OrderedDict. Eric, are you still interested in this? IIRC that PEP was one of the motivating use cases for implementing OrderedDict in C. Maybe it's time for a second round of discussion on Python-ideas? -Emanuel ___ 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] PEP 520: Ordered Class Definition Namespace (round 3)
> From: Eric Snow > Sent: Saturday, June 11, 2016 10:37 PM > To: Python-Dev; Guido van Rossum > Subject: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round > 3) > The only change to the original proposal > has been that a manually set __definition_order__ must be a tuple of > identifiers or None (rather that using the value as-is). > 1. if ``__definition_order__`` is defined in the class body then it > must be a ``tuple`` of identifiers or ``None``; any other value > will result in ``TypeError`` Why not just any arbitrary iterable, which get converted to a tuple at runtime? __slots__ allows any arbitrary iterable: >>> def g(): ... yield "foo" ... yield "bar" ... yield "baz" >>> class C: ... __slots__ = g() >>> C.__slots__ >>> C.__slots__.gi_running False >>> dir(C) [, 'bar', 'baz', 'foo'] > Use of a tuple reflects the fact that we are exposing the order in > which attributes on the class were *defined*. Since the definition > is already complete by the time ``definition_order__`` is set, the > content and order of the value won't be changing. Thus we use a type > that communicates that state of immutability. Typo: missing leading underscores in __definition_order__ > Compatibility > = > > This PEP does not break backward compatibility, except in the case that > someone relies *strictly* on ``dict`` as the class definition namespace. > This shouldn't be a problem. Perhaps add a mention that isinstance(namespace, dict) will still be true, so users don't get unnecessarily confused. > .__dict__ as OrderedDict > --- looks weird to me. I tend to use `cls` (although `klass` isn't uncommon). `C` might also not be a bad choice. Thanks! -Emanuel ___ 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] PEP 520: Ordered Class Definition Namespace (round 3)
> From: Eric Snow > Sent: Saturday, June 11, 2016 11:02 PM > To: Émanuel Barry > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace > (round 3) > > On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry wrote: > >> From: Eric Snow > >> 1. if ``__definition_order__`` is defined in the class body then it > >> must be a ``tuple`` of identifiers or ``None``; any other value > >> will result in ``TypeError`` > > > > Why not just any arbitrary iterable, which get converted to a tuple at > > runtime? > > An arbitrary iterable does not necessarily infer a definition order. > For example, dict is an iterable but the order is undefined. Also, > I'd rather favor simplicity for this (most likely) uncommon corner > case of manually setting __definition_order__, particularly at the > start. If it proves to be a problematic restriction in the future we > can loosen it. Point. This can always be revised later (I'm probably overthinking this as always ;) > > -eric -Emanuel ___ 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
