[Python-ideas] Revisiting dedicated overloadable boolean operators

[Todd]

On Sat, Aug 4, 2018 at 2:48 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Sun, Aug 5, 2018 at 4:40 AM, Todd <toddrjen at gmail.com> wrote:
> >
> >
> > On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano <steve at pearwood.info>
> 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 microprocessors are built.
> >> >
> >> > The fact that Python, strictly speaking, doesn't have them is
> extremely
> >> > unusual for a programming language.
> >>
> >> I'm rather surprised at this claim.
> >>
> >> Can you give a survey of such overridable boolean operators which are
> >> available on modern microprocessors?
> >>
> >> What programming languages already have them? When you say "forever",
> >> are you going back to Fortran in the 1950s?
> >
> >
> > Sorry I wasn't clear, I didn't mean overloadable boolean operators are
> > standard, but rather boolean operators in general.  I was trying to point
> > out that there is nothing domain-specific about boolean operators.
>
> 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 respective truthiness.  So although they
are logical operators, they are not strictly boolean operators.


> > I am personally very strongly against custom operators.  I just have
> visions
> > of someone not liking how addition works for some particular class and
> > deciding implementing a "＋" operator would be a great idea.
>
> Eww. (Before anyone jumps in and says "uhh you already have __add__",
> that is *not* U+002B PLUS SIGN, it is U+FF0B FULLWIDTH PLUS SIGN,
> which would indeed be a custom operator.)
>
> But ultimately, there is already nothing stopping people from doing this:
>
> def Ien(obj):
>     """Return object size in machine words"""
>     return sys.getsizeof(obj) // (sys.maxsize.bit_length() + 1)
>
> and mixing and matching that with the built-in len function. Give
> people freedom, and some will abuse it horrifically... but others will
> use it usefully and safely.
>

In your example, you are intentionally picking a character purely because
it happens to look similar to a completely different character.  That isn't
the sort of thing that can happen innocently or by accident.  By contrast,
using a valid mathematical symbol for the corresponding mathematical
operation is exactly the sort of thing allowing new operators is meant to
support.  The fact that this symbol happens to look similar in some fonts
to the normal plus operator is something that may not even occur to the
person who chose to use the operator.  It would likely seem obvious to the
developer at the time.

So although we can't generally prevent people from being actively
malicious, I think we should at least try to avoid making it overly easy to
make code an unreadable mess.  And allowing custom operators seems to me to
make it way too easy to produce an unreadable mess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180804/547bbe23/attachment.html>