<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 October 2017 at 21:44, Soni L. <span dir="ltr"><<a href="mailto:fakedme+py@gmail.com" target="_blank">fakedme+py@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 text="#000000" bgcolor="#FFFFFF"><div><div class="h5"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">ORMs use this kind of descriptor
            based composition management extensively in order to
            reliably model database foreign key relationships in a way
            that's mostly transparent to users of the ORM classes.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div></div>
    And this is how you miss the whole point of being able to
    dynamically add/remove arbitrary components on objects you didn't
    create, at runtime.<br></div></blockquote><div><br></div>You can already do that by adding new properties to classes post-definition, or by changing __class__ to refer to a different type, or by wrapping objects in transparent proxy types the way wrapt does.</div><div class="gmail_quote"><br></div><div class="gmail_quote">We *allow* that kind of thing, because it's sometimes beneficial in order to get two libraries to play nicely together at runtime without having to patch one or the other. However, it's a last resort option that you use when you've exhausted the other more maintainable alternatives, not something we actually want to encourage.<br></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>