Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

Adding one operator is hard in Python. Adding 4 operators, just for the sake of a bit of syntaxic suggar for DSL based projects is never going to fly. And I say that as a long time SQLA user. Le 03/08/2018 à 19:46, Todd a écrit : > Coming back to the previous discussion about a new set of

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

A small remark for Todd's proposal: I think you should treat the new not (bNOT in the original proposal) differently: it's not binary, so it should not have 2 dunders, the right one is not needed (or there is only the right one, in a way, but other unary ops use the classic dunder iirc...)

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

Oh, I see, I thought he wanted to override the original logical operators. I don't like adding more operators just to make symbolic equation generation simpler. I think keeping the language simple and using the "numpy.logical_and" function is better than making the language more complicated for

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Mon, Aug 06, 2018 at 02:44:24PM -0700, Neil Girdhar wrote: > This doesn't work because the logical Boolean operators short circuit in > Python. So you could not even define these operators for the regular > Python types. Todd is not proposing to add dunder methods for the existing "or" and

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

This doesn't work because the logical Boolean operators short circuit in Python. So you could not even define these operators for the regular Python types. Your two examples numpy and SQLAlchemy don't want this short-circuiting behavior, so you would never want to write anything like

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Mon, Aug 6, 2018 at 11:11 AM, Chris Barker wrote: > So any new class that doesn't already make use of the bitwise operators > can do that. > just like set() -- which I think has been mentioned here already. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 3, 2018 at 9:13 PM, Todd wrote: > >> Also, in a common use-case, bitwise-and behaves the same as logical_and, >> e.g. >> >> if (arr > x) & (arr2 == y) >> >> This "works" because both arrays being bitwise-anded are boolean arrays. >> > > There are a few problems with using the

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

You should have a look at old PEP225 "Elementwise operators", that proposed ~ as a modifier for many existing operator, to indicate they do mostly what their "normal counterpart do, but act on the inner/ elements of an object instead of on the whole. This was only a memorisation technique, as

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 04, 2018 at 09:16:35PM -0400, Todd wrote: [Chris said:] > > You say that Python doesn't have them. What aspect of boolean > > operators doesn't Python have? > > > > Python's "and" and "or" don't return "True" or "False" per se, they return > one of the inputs based on their

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 04, 2018 at 02:40:54PM -0400, Todd wrote: > On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote: > > > On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote: > > > > > Boolean operators like the sort I am discussing have been a standard part > > > of programming languages since

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 4, 2018 at 2:48 PM, Chris Angelico wrote: > On Sun, Aug 5, 2018 at 4:40 AM, Todd wrote: > > > > > > On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano > wrote: > >> > >> On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote: > >> > >> > Boolean operators like the sort I am discussing

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sun, Aug 5, 2018 at 4:40 AM, Todd wrote: > > > On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote: >> >> On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote: >> >> > Boolean operators like the sort I am discussing have been a standard >> > part >> > of programming languages since forever.

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote: > On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote: > > > 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

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

That's very nice Stephan. I think I'll add those to my machines. But not everyone uses vim. And although I use vim a lot, I also use other text editors, by choice or compulsion (e.g. editing code in web interface). And even when I have vim, I don't necessarily have the ability to install and test

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

I use these Vim abbreviations, which are derived from LaTeX https://gist.github.com/stephanh42/fc466e62bfb022a890ff2c4643eaf3a5 Stephan Op za 4 aug. 2018 20:03 schreef David Mertz : > On Sat, Aug 4, 2018, 1:24 PM Steven D'Aprano wrote: > >> If you think the uproar over PEP 572 was vicious,

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 4, 2018, 1:24 PM Steven D'Aprano wrote: > If you think the uproar over PEP 572 was vicious, imagine what would > happen if we introduced new operators like ∉ ∥ ∢ ∽ ⊎ etc instead. > > - keyboard support for entering the bulk of Unicode characters is > non-existent or poor; > > -

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 04, 2018 at 02:04:01PM +, Dan Sommers wrote: > On Sat, 04 Aug 2018 23:13:34 +1000, Steven D'Aprano wrote: > > > There are certainly advantages to using binary operators over named > > functions, and a shortage of good, ASCII punctuation suitable for new > > operators. > > Hold

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sun, Aug 5, 2018 at 2:37 AM, Steven D'Aprano wrote: > All this supposes that there is sufficient benefit to allowing custom > infix operators, including overridable or/and/xor, which is not yet > shown. Part of the justification for that is that the bitwise operators have different precedence

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Sat, Aug 04, 2018 at 04:56:56PM +0200, Benedikt Werner wrote: > >I think that before adding more ad hoc binary operators, we ought to > >consider the possibility of custom operators. > > That actually sounds like the most sensible solution so far Thanks :-) Unfortunately there's a flaw, in

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote: > 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

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

The proposal is for new operators.  The operators would be "bNOT", "bAND", "bOR", and "bXOR".  They would be completely independent of the existing "not", "and", and "or" operators, operating purely on boolean values.  It would be possible to overload these operators. I see, I misunderstood

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 3, 2018 at 5:38 PM, Chris Barker wrote: > On Fri, Aug 3, 2018 at 1:02 PM, Nicholas Chammas < > nicholas.cham...@gmail.com> wrote: > >> The project overloaded the bitwise operators &, |, and ~ since they >> could not >> > override the boolean operators and, or, and not. >> >> I

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 3, 2018 at 6:05 PM, Benedikt Werner <1benediktwer...@gmail.com> wrote: > 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. I think >> none of those reasons (besides the conversation fizzling

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On 2018-08-03 23:05, Benedikt Werner wrote: 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.  I think none of those reasons (besides the conversation fizzling out) apply to my proposal. Maybe I am missing

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

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.  I think none of those reasons (besides the conversation fizzling out) apply to my proposal. Maybe I am missing something, but I don't really see how this

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 3, 2018 at 1:02 PM, Nicholas Chammas wrote: > The project overloaded the bitwise operators &, |, and ~ since they > could not > override the boolean operators and, or, and not. > > I actually think that is a good solution to this problem -- the fact is that for most data types

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 3, 2018 at 1:47 PM Todd toddr...@gmail.com wrote: The operators would be: > > bNOT - boolean "not" > bAND - boolean "and" > bOR - boolean "or" > bXOR - boolean "xor" > These look pretty ugly to me. But that could just be a matter of familiarity. For

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

On Fri, Aug 3, 2018 at 2:26 PM, Jonathan Fine 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

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

Hi Todd Thank you for your contribution! I've got a couple of comments. The experts, I hope, will have more to say. 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

[Python-ideas] Revisiting dedicated overloadable boolean operators

Coming back to the previous discussion about a new set of overloadable boolean operators [1], I have an idea for overloadable boolean operators that I think might work. The idea would be to define four new operators that take two inputs and return a boolean result based on them. This behavior