> That's a bug in my proxy too. I'll figure out how to fix it in 0.1.2 soon.
> This is early alpha, and the things you're noting are valuable bug reports.
> But none of this is fundamentally unfixable in a library, nor even
> especially difficult.
If you're going to make that work, then by definition you would be
wrapping up the None, right? Which would mean that every one of the
prints would say "<NullCoalesce proxy for None>". Which, in turn,
means that you cannot do this:
>>> NullCoalesce(spam).nil is None
or rather, it will always be False. With PEP 505, you most certainly
*can* do this check, because it would really truly be None.
This IS fundamentally unfixable in a library.
If your meaning of "fix" is simply "add new syntax", of course that's true. If it's "solve the actual problem that motivates the PEP" I can definitely fix it.
Right now, you can still always call .unbox() at the end to get the underlying value. I agree that's a little ugly, hence why I added the wrapt proxy stuff. Most operations trigger unboxing, but indeed not simply echoing to the shell.
I think I'll add a property spelled '_' to make it less busy (but more cryptic, I know). E.g.
NullCoalesce(spam).nil.nil.nil._ is None'
I also added an unbox() function that will pass through non-proxy objects untouched. So it's safe to unbox anything if you are unsure what it is.
Of course I'm not claiming any library is without a need to work with it's quirks and limits. But they are very few even in this 4-hours-of-work alpha.