[Python-ideas] [Python-ideos] Dedicated overloadable boolean operators

[Jelte Fennema]

On 24 November 2015 at 02:44, Michael Selik <mike at selik.org> wrote:

> Why hasn't SQLAlchemy gone the route of NumPy with overloaded operators?
>
It seems I was wrong about that, they apparently do:
http://stackoverflow.com/a/14185275/2570866

I'd put that in the category of parentheses tax along with the print
> function and old style % string interpolation.

This seems like a bit of a weird argument since the parentheses for the
print function are put there for a reason (see PEP3105) and the old style %
string interpolation will be replaced by the new format string literal.

Adding yet another operator would make Python harder to learn and read.
> Even if you advertise a new operator, many libraries will be slow to change
> and we'll have 3 different techniques to teach.

I don't think that much confusion will arise, since the normal way is to to
use is the short `and` version. Only in libraries where it would be
explicitly told the new operator would be used. It would also do away with
the confusion about why and cannot be overridden and why the precedence of
the & operator is "wrong".

On 24 November 2015 at 02:44, Michael Selik <mike at selik.org> wrote:

> Why hasn't SQLAlchemy gone the route of NumPy with overloaded operators?
> Perhaps whatever reason it is would prevent using any new operators as
> well.
>
> With NumPy I make that mistake constantly:
>     A == a & B == b
> rather than
>     (A == a) & (B == b)
>
> I'd put that in the category of parentheses tax along with the print
> function and old style % string interpolation. Annoying, but it's
> inappropriate to use a gun to swat a fly. (In case my metaphor is unclear,
> creating a new operator is the gun -- risking collateral damage and all
> that)
>
> As Guido said, the real usability problem is that the ``and`` operator is
> a new Python programmer's first instinct. Adding yet another operator would
> make Python harder to learn and read. Even if you advertise a new operator,
> many libraries will be slow to change and we'll have 3 different techniques
> to teach. Let's weigh the benefits against the negative consequences.
>
> On Mon, Nov 23, 2015 at 8:12 PM Jelte Fennema <me at jeltef.nl> wrote:
>
>> On 24 November 2015 at 01:26, Bruce Leban <bruce at leban.us> wrote:
>>
>>> If this idea were to fly, a better name would be something that doesn't
>>> have that problem, e.g., .and. .or. .not. I don't want to bikeshed the
>>> exact syntax**, but I think it should be clear that with something like
>>> this: (1) no one is going to accidentally type them and (2) they are pretty
>>> clearly some variation of the standard and/or/not.
>>
>>
>> I think a naming scheme like that is indeed a good way to solve the
>> confusion issues, since it is also immediately clear that these would be a
>> special version of the normal operators. Another advantage is that it could
>> also be extended to the in operator, if that one is to be included.
>>
>> I'm not sure I like the dots version very much though, but like you said
>> there are lots of syntax error options to choose from.
>>
>> On 24 November 2015 at 01:26, Bruce Leban <bruce at leban.us> wrote:
>>
>>>
>>> On Mon, Nov 23, 2015 at 4:08 PM, Chris Angelico <rosuav at gmail.com>
>>> wrote:
>>>
>>>> I think it's reasonable, except for the potential confusion of having
>>>> *three* "and" operators.
>>>>
>>>
>>> I think using && and || would be an attractive nuisance for people
>>> switching from another programming language. Right now if I accidentally
>>> right && in Python or "and" in another language, I get an immediate syntax
>>> error. With this proposal, I get unexpected results.
>>>
>>> If this idea were to fly, a better name would be something that doesn't
>>> have that problem, e.g., .and. .or. .not. I don't want to bikeshed the
>>> exact syntax**, but I think it should be clear that with something like
>>> this: (1) no one is going to accidentally type them and (2) they are pretty
>>> clearly some variation of the standard and/or/not.
>>>
>>> **Lots of other possibilities that are syntax errors right now: @and, (and),
>>> etc. I like .and. because it's less visual clutter and it's easy to
>>> type.
>>>
>>> --- Bruce
>>> Check out my puzzle book and get it free here:
>>> http://J.mp/ingToConclusionsFree (available on iOS)
>>>
>>>
>>> --
>>>
>>> ---
>>> 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/5bEW_wwNJcM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> python-ideas+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at 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/5bEW_wwNJcM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> python-ideas+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151124/d9fe555b/attachment-0001.html>