On Fri, Aug 3, 2018 at 2:26 PM, Jonathan Fine <jfine2...@gmail.com> wrote:
> Hi Todd > > Thank you for your contribution! I've got a couple of comments. The > experts, I hope, will have more to say. > > Thanks for your reply, Jonathan. > You wrote: > > > As to why this is useful, the overall problem is that the current logical > > operators, like and, or, and not, cannot be overloaded, which means > projects > > like numpy and SQLAlchemy instead have to (ab)use bitwise operator > > > There was a proposal to allow overloading boolean operators in Pep-335 > [2], > > but that PEP was rejected for a variety of very good reasons. > > The key thing is, I think, the wish for a domain specific language. I > find this to be a wholesome wish. But I'd rather create a broad > solution, than something that works just for special cases. And if at > all possible, implement domain specific languages without extending > the syntax and semantics of the language. > 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. 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. 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. There is the problem of short-circuiting evaluation, as in the 'and' > and 'or' operators (and elsewhere in Python). This has to be a syntax > and semantics feature. It can't be controlled by the objects. > 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.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
