Re: [Python-Dev] Replacement proposal for PEP 557 Data Classes
On 18 February 2018 at 09:14, Ramazan POLAT wrote: > Hi, I have been working on a new way to use Python classes as enhanced dict > object(I called it Prodict). > My solution is (IMHO) more concise and brings more features. > So I wanted to make it a PEP until I saw PEP 557 Data Classes. > With my proposed enhancement, I can do everything Data Classes can do plus > some neat features. > Since 3.7b1 is out and already integrates data classes, how do I proceed? > Propose a replacement for PEP 557 or prepare a new PEP? The introduction of data classes was prompted by the popularity of the 3rd party attrs library, so the first step would be to achieve that level of popularity. However, with instances being dict instances, there are quite a few attrs/dataclasses features that I expect you would find difficult to replicate (hashability, immutable instances, ordered comparison support), so your library strikes as being more an advanced alternative to types.SimpleNamespace rather than an alternative to data classes. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses, frozen and __post_init__
On 18 February 2018 at 14:10, Guido van Rossum wrote:
> Agreed the __pre_init__ idea is no improvement. I think we're back where you
> started -- just use `object.__setattr__` to set the attribute in
> `__post_init__`. That's what the PEP says is used by the generated
> `__init__`, so I think it is reasonable to copy that pattern. Presumably the
> situation doesn't occur that frequently in real code (__post_init__ feels
> like a last resort hack anyway).
FWIW, if someone really wanted to create a 3rd party context manager
to assist with this they can do:
@contextmanager
def mutable(obj):
cls = obj.__class__
obj.__class__ = object
try:
yield obj
finally:
obj.__class__ = cls
@dataclass(frozen=True)
class C:
i: int
j: int = None
database: InitVar[DatabaseType] = None
def __post_init__(self, database):
if self.j is None and database is not None:
with mutable(self):
self.j = database.lookup('j')
Using object.__setattr__ explicitly would be clearer, though.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses, frozen and __post_init__
The underlying issue here is that we don't want an extra state flag in the
object to indicate "this object is currently [im]mutable". Using __class__
assignment to signal this is clever way to add this state, though not
without risks.
On Sun, Feb 18, 2018 at 4:34 PM, Nick Coghlan wrote:
> On 18 February 2018 at 14:10, Guido van Rossum wrote:
> > Agreed the __pre_init__ idea is no improvement. I think we're back where
> you
> > started -- just use `object.__setattr__` to set the attribute in
> > `__post_init__`. That's what the PEP says is used by the generated
> > `__init__`, so I think it is reasonable to copy that pattern. Presumably
> the
> > situation doesn't occur that frequently in real code (__post_init__ feels
> > like a last resort hack anyway).
>
> FWIW, if someone really wanted to create a 3rd party context manager
> to assist with this they can do:
>
> @contextmanager
> def mutable(obj):
> cls = obj.__class__
> obj.__class__ = object
> try:
> yield obj
> finally:
> obj.__class__ = cls
>
> @dataclass(frozen=True)
> class C:
>i: int
>j: int = None
>database: InitVar[DatabaseType] = None
>
>def __post_init__(self, database):
>if self.j is None and database is not None:
>with mutable(self):
>self.j = database.lookup('j')
>
> Using object.__setattr__ explicitly would be clearer, though.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | [email protected] | Brisbane, Australia
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
