<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 8:00 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Every use I've suggested for the magic proxy is similar to:<br>>   NullCoalesce(cfg).user.profile.food<br></blockquote><div><br></div><div>Thanks Steven!  Several things you suggest urge some minor improvements to my slightly-more-than-toy library `coalescing` (<a href="https://pypi.org/project/coalescing/">https://pypi.org/project/coalescing/</a>).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I trust that you don't expect everyone to religiously follow the <br>
exact letter of your examples. Being able to extract out subexpressions <br>
into variables is an important programming technique, and we ought to be <br>
able to do things like this:<br>
<br>
    config = NullCoalesce(cfg)<br>
    process(config)<br>
<br>
    # later...<br>
    user = config.user<br>
    user_records[<a href="http://user.id" rel="noreferrer" target="_blank">user.id</a>] = user<br>
    food = get_preferred_food(user)<br></blockquote><div><br></div><div>Yes, absolutely! In many cases this will JUST WORK because of the magic in wrapt.ObjectProxy.  But it also makes me realize that I should provide a plain old function `unbox()` as well as the method.  In particular, `unbox(obj)` can and will figure out whether the object is really a proxy at all, and if not simply return `obj` itself.  Then you do no harm by scattering unbox() calls in places where they may or may not be needed.</div><div><br></div><div>I also think that even though it was a typo at first, the name NullCoalesce is better than NoneCoalesce.  I'll provide an alias.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">    spam?.attribute<br>
    eggs.attribute<br>One of those is ordinary attribute access that can raise AttributeError <br>
if the object is None, and the other is None-aware "maybe dot" attribute <br>
access that returns None if the object is None.<br></blockquote><div><br></div><div>That is disingenuous, I think.  Can this raise an AttributeError?</div><div><br></div><div>    spam?.eggs?.bacon</div><div><br></div><div>Of course it can! And this is exactly the pattern used in many examples in the PEP and the discussion. So the PEP would create a situation where code will raise AttributeError in a slightly—and subtly—different set of circumstances than plain attribute access will.</div><div><br></div><div>The fact that half the readers of this thread won't immediately see just when that AttributeError might occur (based on lots of prior misunderstandings by smart posters) makes the operator that much more magical.</div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons.  Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div></div>