<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 3, 2018 at 2:26 PM, Jonathan Fine <span dir="ltr"><<a href="mailto:jfine2358@gmail.com" target="_blank">jfine2358@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Todd<br>
<br>
Thank you for your contribution! I've got a couple of comments. The<br>
experts, I hope, will have more to say.<br>
<span><br></span></blockquote><div><br></div><div>Thanks for your reply, Jonathan.<br><div class="gmail_extra"><br></div></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"><span>
You wrote:<br>
<br>
> As to why this is useful, the overall problem is that the current logical<br>
> operators, like and, or, and not, cannot be overloaded, which means projects<br>
> like numpy and SQLAlchemy instead have to (ab)use bitwise operator<br>
<br>
</span><span>> There was a proposal to allow overloading boolean operators in Pep-335 [2],<br>
> but that PEP was rejected for a variety of very good reasons.<br>
<br>
</span>The key thing is, I think, the wish for a domain specific language. I<br>
find this to be a wholesome wish. But I'd rather create a broad<br>
solution, than something that works just for special cases. And if at<br>
all possible, implement domain specific languages without extending<br>
the syntax and semantics of the language.<br></blockquote><div><br></div><div>This proposal isn't domain-specific.  I think the fact that it would benefit projects as diverse as numpy and SQLAlchemy (as well as others such as sympy) demonstrates that.</div><div><br></div><div>Boolean operators like the sort I am discussing have been a standard part of programming languages since forever.  In fact, they are the basic operations on which modern microprocessors are built. <br></div><div><br></div><div>The fact that Python, strictly speaking, doesn't have them is extremely unusual for a programming language.  In many cases they aren't necessary in Python since Python's logical operators do the job well enough, but there are a set of highly diverse and highly prominent cases where those logical operators won't work.  There are workarounds, but they are less than optimal for the reasons I describe, and the previous discussion I linked to goes into much more detail why these new operators are important.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There is the problem of short-circuiting evaluation, as in the 'and'<br>
and 'or' operators (and elsewhere in Python). This has to be a syntax<br>
and semantics feature. It can't be controlled by the objects.<br></blockquote><div><br></div><div>Yes, sorry, I left that out.  The consensus from the previous discussion is that this wouldn't be short-circuiting.  I can imagine ways to support short-circuiting as well (such as a second set of dunder methods with one set overriding the other), but it isn't really relevant to my proposal.  This proposal is assuming the semantics from the previous discussion.  All I am trying to address here is how the operators would be spelled.</div></div></div></div>