On Jan 11, 2016, at 04:02, Ram Rachum <ram@rachum.com> wrote:
I've chosen += and -=, despite the fact they're not set operations, because Python doesn't have __inand__.
For a property that acts like a number, and presumably is implemented as a subclass of int, this seems like a horribly confusing idea.
On an unrelated note, maybe we should have __inand__? (I mean x ^~= y)
First, why would you spell inand that way? x ^ ~y is the exclusive or of x and ~y, which is true for ~x and ~y and for x and y. That's completely different from nand, which is true for ~x and ~y, ~x and y, and x and y, but not x and ~y. And neither is what you want, which is true only for x and ~y, which you can easily write as x & ~y. Second, why do you think you need an i-operation for a combined operator? x &= ~y does the same thing you'd expect from x &~= y. And why do you think you need an overridable i-operator in the first place? If you call x |= y and x.__ior__ doesn't exist, it just compiles to the same as x = x | y. And, unless x is mutable (which would be very surprising for something that acts like an int), that's actually the way you want it to be interpreted anyway. All of this implies that adding the 70s bitwise operator syntax for dealing with permissions doesn't help with concise but readable code so much as encourage people who don't actually understand bitwise operations to write things that aren't correct or to misread other people's code. What's wrong with just spelling it "clear"? Or, better, as attribute access ("p.chmod.executable = False" or "p.chmod.group.executable = False") or actual set operations with sets of enums instead of integers? The other advantage of using named operations is that it lets you write things that are useful but can't be expressed in a single bitwise operation. For example, "p.chmod.group = q.chmod.owner" is a lot simpler than "p.chmod = p.chmod & ~0o070 | (q.chmod >> 3) & 0o070". Meanwhile, why are you calling the mode "chmod", which is an abbreviation for "change mode"? That's sort of readable but still weird for the cases when you're modifying it, but completely confusing for cases when you're just reading it off. Have you looked at the existing alternatives on PyPI? If so, why isn't one of them good enough? And meanwhile, why not just put your library on PyPI and see if others take it up and start using it? Is there a reason this has to be in the stdlib (and only available on 3.6+) to be usable?