Showing content from http://mail.python.org/pipermail/python-dev/attachments/20180217/a913d259/attachment.html below:
<div dir="ltr">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).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 17, 2018 at 5:59 PM, Ben Lewis <span dir="ltr"><<a href="mailto:benlewisj@gmail.com" target="_blank">benlewisj@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Why can'y you make `name` on `NamedObjectItem` a property that returns `<a href="http://self.obj.name" target="_blank">self.obj.name</a>`? Why store a duplicate copy of the name?<br></div></div></blockquote><div> </div></span><div>Agreed, it's probably a better design not to store a duplicate reference to name. But when I tried that, the property clashed with the inherited field. This caused the creation of the dataclass to fail as it thought that the property was the default value for the field 'name'. Even if I set a default for the obj field, it crashed as it tried to set the default value for name to the read-only property.  </div><div><br></div><div>Although I can think of situations where properties wouldn't be sufficent as you only want to calculate the value once per instance on creation. My thought is that m<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">ost dataclasses would still be sensible and useful even if all mutation ability was removed from them. </span>Taking an example directly from the PEP:</div><div><br></div>@dataclass<br>class C:<br>  i: int<br>  j: int = None<br>  database: InitVar[DatabaseType] = None<br><br>  def __post_init__(self, database):<br>    if self.j is None and database is not None:<br>      self.j = database.lookup('j')</div><div class="gmail_quote"><br></div><div class="gmail_quote">Maybe I'm thinking of dataclasses wrong but this still make complete sense and is useful even if its declared as frozen. </div><div class="gmail_quote"><br></div><div class="gmail_quote"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">My thought is that initialisation logic and immutability is orthogonal to each other. Possibly initialisation logic like this should occur before the instance is created so it would work for immutable types as well.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">A possible idea could be, instead of __post_init__, there is __pre_init__ which allows altering of fields before the instance is created. It would take a dict as first argument which contain the field values passed into the 'constructor' and default values would also be filled out.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div>@dataclass<br>class C:<br>  i: int<br>  j: int = None<br>  database: InitVar[DatabaseType]<br><br>  @classmethod<br>  def __pre_init__(cls, fields: Dict[str, Any], database: DatabaseType):<br>    if fields['j'] is None and database is not None:<br>      fields['j'] = database.lookup('j')</div><div class="gmail_quote"><br></div><div class="gmail_quote">I personally see two problems with this idea:</div><div class="gmail_quote">1. This isn't as ergonomic as __post_init__ is as its modifing a dictionary instead of its instance.</div><div class="gmail_quote">2. To implement this, it would require a metaclass. <br></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4