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...) Also, not having xor is made more painful by this proposal (or for any proposal for new Boolean operators using variants of and/or/not)... I have been bitten a few times writing xor in my code (not often, because xor is done less often), it already feel like it's missing from python. With additional duplicated operators, including bXOR, the missing xor is annoying like a missing teeth: even if you don't use it so much, you think of it all the time ;-) Greg.___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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 a small fraction of users. There will always be a gap between Python and symbolic equation generation. On Mon, Aug 6, 2018 at 9:03 PM Steven D'Aprano wrote: > 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 > "and" operators. > > Todd is proposing four new operators spelled "bAND", "bOR", "bXOR" and > "bNOT", which aren't short-circuiting and call dunder methods, just like > other operators including "in". > > You seem to be saying that "this" (defining new operators that call > dunder methods) doesn't work because a set of *completely different* > existing operators short-circuit. If that's not what you meant, I > don't understand what you actually did mean. > > > > Your two examples numpy and SQLAlchemy don't want this > > short-circuiting behavior, so you would never want to write anything like > > > > (some_array or some_other_array) > > > > The reader of this code might imagine that there is some short > circuiting > > or conversion to Boolean. > > Fortunately Todd isn't proposing that. > > > -- > Steve > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "python-ideas" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/python-ideas/LgwmlPp6YqM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > python-ideas+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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 "and" operators. Todd is proposing four new operators spelled "bAND", "bOR", "bXOR" and "bNOT", which aren't short-circuiting and call dunder methods, just like other operators including "in". You seem to be saying that "this" (defining new operators that call dunder methods) doesn't work because a set of *completely different* existing operators short-circuit. If that's not what you meant, I don't understand what you actually did mean. > Your two examples numpy and SQLAlchemy don't want this > short-circuiting behavior, so you would never want to write anything like > > (some_array or some_other_array) > > The reader of this code might imagine that there is some short circuiting > or conversion to Boolean. Fortunately Todd isn't proposing that. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntactic sugar to declare partial functions
By the way, these are not "partial functions", and shouldn't be called
that. These are "partial function applications".
On Saturday, August 4, 2018 at 12:03:50 PM UTC-4, Fabrizio Messina wrote:
>
>
> Hello, I would like to propose a new method to create a partial function.
>
> At the moment we have to load the *partial* function from the *functool*
> library, and apply it to an existing function, e.g.
>
> from functools import partial
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
>
> add_2 = partial(add, 2)
>
>
>
> While partial expose the mechanism excellently its instantiation method
> is, at times, not very friendly, I would like to propose a syntactic sugar
> to create partial functions, in the case you create a partial function
> using *curly braces*:
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
> add_2 = add{2}
>
>
> At the moment this causes SyntaxError so the change is retro-compatible.
>
> In the case of key word arguments we could have:
>
> sort_by_x = sort{key=lambda element: element.x}
>
>
> That could be good as it would be an easy way to pre-load functions
> without having to eagerly compute it, but without needing to pass the
> entire function parameters to to other scopes.
>
>
> # prepare the function
> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda
> user: user.creation_date}
>
> # continue with job at hand
> ...
>
> # some where else, maybe another process
> sorted_users = list(get_sorted_users())
>
>
>
> Even create a factory method on the fly:
> @dataclass
> class Product:
> name: str
> category: Category
> price: Decimal
>
>
> smartphone_factory = Product{category=smartphone_category}
>
>
>
> Now all this can already be done with partial, but adding this syntactic
> sugar would reduce the perception of `partial` as an advanced feature,
> alleviating the use of closures created only for the sake of avoiding an
> explicit partial.
>
> In my opinion this syntactic sugar has a lot of potential adoption seen
> the general interest in functional programming.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
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 (some_array or some_other_array) The reader of this code might imagine that there is some short circuiting or conversion to Boolean. The essential problem here is that you want a nicer way to create symbolic graphs with Boolean operators. But the general problem is that Python always has wrinkles when creating symbolic graphs. Besides numpy conditions and SQLAlchemy, sympy and tensorflow also build symbolic graphs. They also struggle with succinctness. You will never get the symbolic graph to look just like pseudocode the way pure Python does. On Friday, August 3, 2018 at 1:48:02 PM UTC-4, Todd Jennings wrote: > > 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 can be overridden in appropriate dunder methods. These operators > would have similar precedence to existing logical operators. The operators > would be: > > bNOT - boolean "not" > bAND - boolean "and" > bOR - boolean "or" > bXOR - boolean "xor" > > With corresponding dunder methods: > > __bNOT__ and _rbNOT__ (or __r_bNOT__) > __bAND__ and _rbAND__ (or __r_bAND__) > __bOR__ and _rbOR__ (or __r_bOR__) > __bXOR__ and _rbXOR__ (or __r_bXOR__) > > The basic idea is that the "b" is short for "boolean", and we change the > rest of the operator to upercase to avoid confusions with the existing > operators. I think these operators would be preferably to the proposals so > far (see [1] again) for a few reasons: > > 1. They are not easy to mistake with existing operators. They are > clearly not similar to the existing bitwise operators like & or |, and > although they are clearly related to the "not", "and", and "or" I think > they are distinct enough that it should not be easy to confuse the two or > accidentally use one in place of the other. > >2. They are related to the operations they carry out, which is also an > advantage over the existing bitwise operators. > >3. The corresponding dunder methods (such as __bAND__ and _rbAND__) are > obvious and not easily confused with anything else. > >4. The unusual capitalization means they are not likely to be used much > in existing Python code. It doesn't fall under any standard capitalization > scheme I am aware of. > >5. At least for english the capitalization means they are not easy to > confuse with existing words. For example Band is a word, but it is not > likely to be capitalized as bAND. > > 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 > operators to define their own boolean operations (for example elementwise > "and" in numpy arrays). This has a variety of problems, such not having > appropriate precedence leading to precedence errors being common, and the > simple fact that this precludes them from using the bitwise operators for > bitwise operations. > > 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. > > So the alternative proposal that has been floating around is to instead > define new operators specifically for this. Although there seemed to be > some support for this in principle, the actually operators so far have not > met with much enthusiasm. So far the main operators proposed so far seem > to be: > > 1. Double bitwise operators, such as && and ||. These have the > disadvantage of looking like they should be a type of bitwise operator. > > 2. the existing operators, with some non-letter character at the front and > back, like ".and.". These have the advantage that they are currently not > valid syntax in most cases, but I think are too similar to existing logical > operators, to easy to confuse, and it is not immediately obvious in what > way they should differ from existing operators. They also mean different > things in other languages. > > So I think my proposal addresses the main issues raised with existing > proposals, but has the downside that it requires new keywords. > > Thoughts? > > [1] > https://mail.python.org/pipermail/python-ideas/2015-November/037207.html > [2] https://www.python.org/dev/peps/pep-0335/ > ___ Python-ideas mailing list Python-ideas@python.org
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 NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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 bitwise operators. > > First, and most important in my opinion, is that the precedence is > significantly off from that of the logical operators. > yes, that's true, and perhaps too bad, but as they are spelled differently, not a killer. if you are switching back and forth between, say, array logical operations > and "normal" logical operations it is easy to mess up. > well, as you generally are working with arrays or not, again, not too bad. > Third is that it allows both boolean and bitwise operations to be carried > out on the same data types. Numpy is a special case where the two > basically are equivalent if you are working with boolean arrays. But that > is a special case. > I kind of muddled my point -- the main trust was that overloading the bitwise operators to do logical operations is a fine idea -- many objects will have no or limited use for bitwise operations. In fact, if I were to re-design the numpy API, I would overload the bitwise operators to do logic, and use the special functions for bitwise operations: np.bitwise_and etc. rather than having to use logical_and and friends the way we do now. So any new class that doesn't already make use of the bitwise operators can do that. (yes, still the precedence issue, but what can you do?) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
