[Python-ideas] More friendly access to chmod

[Andrew Barnert]

On Jan 11, 2016, at 08:53, Chris Angelico <rosuav at gmail.com> wrote:
> 
>> On Tue, Jan 12, 2016 at 3:49 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> On Jan 11, 2016, at 04:02, Ram Rachum <ram at 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.
> 
> I would expect it NOT to be a subclass of int, actually - just that it
> has __int__ (and maybe __index__) to convert it to one.

If you read his proposal, he wants oct(path.chmod) to work. That doesn't work on types with __int__. 

Of course it does work on types with __index__, but that's because the whole point of __index__ is to allow your type to act like an actual int everywhere that Python expects an int, rather than just something coercible to int. The point of PEP
357 was to allow numpy.int64 to act as close to a subtype of int as possible without actually being a subtype.

It would be very surprising for, say, IntEnum (which subclasses int), or numpy.int64 (which uses __index__), to offer an __add__ method that actually did an or instead of an add. It will be just as surprising here. 

And the fact that he wants to make it possible (in fact, _encouraged_) to directly assign an int to the property makes it even more confusing.

For example, "p.chmod = q + 0o010" does one thing if q is an integer, and another thing if it's the chmod of another path object.

(Of course he also wants to be able to assign a string, but that's not a problem; if you mix up str and int, you get a nice TypeError, as opposed to mixing up int and an int subclass or __index__-using class, where you silently get incorrect behavior.)