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

[Jelte Fennema]

On 24 November 2015 at 06:35, Andrew Barnert via Python-ideas <
python-ideas at python.org> wrote:

> -0 on actually adding a general custom-infix syntax, come to think of it.
> Any solution to the problems above should work just as well here. And it
> means that in the future, libraries don't have to cram things into
> inappropriate symbols or be stuck with prefix or dot-method notation. And I
> don't think it would be any harder to learn than a few special cases. And I
> think ".between." would be just as useful in an ORM as ".in.". More
> generally, the whole point of "@" was that everyone agreed that it was the
> only new operator anyone would need (except maybe "@@") for a decade or
> two; if that's not true, infinity is a better number than 4.


This seems like an interesting idea, but I think it would be hard finding a
notation that does not conflict with current operations. For the and/or
almost any symbol would work, since they are keywords and the operators
have no meaning on them, but if any name can be used operations on
variables will become unclear. So another symbol would probably have to be
used that isn't used yet, like the $ symbol. Also, I think there are
probably some other issues that I haven't thought of, since this would add
a pretty big language feature.

PS. I didn't include the dollar convention in my last options list for the
new and operator, but it is ofcourse also a possibility: $and$, or maybe
$and.

On 24 November 2015 at 06:35, Andrew Barnert via Python-ideas <
python-ideas at python.org> wrote:

> (Top-posting because this is really a reply to a combination of three
> earlier posts, not to Greg Ewing's post, except at the very end.)
>
> -1 on "&&" and "||". To anyone familiar with C and friends, it seems like
> they ought to be like C (short-circuiting, and more generally the same
> thing we already spell "and" and "or"); to anyone else, it would make no
> sense for them to have different precedence than "&" and "|".
>
> -0.5 on ".and." and ".or." for multiple reasons, most of which apply just
> as well to anything similar:
>
> * That looks like a general custom-infix syntax. Anyone coming to Python
> (including Python 2 users) will expect that they can just as easily define
> ".spam." (and then be disappointed that they can't...), or will be worried
> that 3.7 will add a bunch of new dot operators they'll have to learn. Not a
> _huge_ negative, but already enough to turn me off the idea.
>
> * What would you call the dunder methods (and operator module functions),
> and how would you deal with the fact that any novice/transplant is going to
> assume "__and__" means ".and." rather than "&"?
>
> * Operators starting with "." are ambiguous with float literals and/or
> attribute access ("spam.and.eggs" looks like a member of a member of spam),
> at least to humans, if not to the parser.
>
> * Operators starting and/or ending with "." are hard to talk about because
> of natural-language punctuation (and even harder on a mobile keyboard, or
> an overly clever text editor or word processor).
>
> -0 on actually adding a general custom-infix syntax, come to think of it.
> Any solution to the problems above should work just as well here. And it
> means that in the future, libraries don't have to cram things into
> inappropriate symbols or be stuck with prefix or dot-method notation. And I
> don't think it would be any harder to learn than a few special cases. And I
> think ".between." would be just as useful in an ORM as ".in.". More
> generally, the whole point of "@" was that everyone agreed that it was the
> only new operator anyone would need (except maybe "@@") for a decade or
> two; if that's not true, infinity is a better number than 4.
>
> +1 on the idea if someone can come up with a good spelling that avoids all
> the above problems and reads as naturally as "@".
>
> > On Nov 23, 2015, at 20:55, Greg Ewing <greg.ewing at canterbury.ac.nz>
> wrote:
> >
> > Bruce Leban wrote:
> >> If this idea were to fly, a better name would be something that doesn't
> have that problem, e.g., .and. .or. .not.
> >
> > Dots are a bit on the ugly side.
> >
> > Some other possibilities:
> >
> > AND, OR, NOT
> >
> > And, Or, Not
> >
> > en, of, nlet
>
> Is that last one supposed to be "niet"? When I try "nlet", Google assumes
> it's a typo for "net", which I guess could be a unary boolean identity
> operator, but I don't think we need that. :)
>
> Anyway, that pattern is a bit hard to extend to an overloadable "in"
> operator, because Dutch for "in" is "in".
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151124/7199f23b/attachment.html>