Message178542
It seems to me that the real issue is not to preserve the original representation. What if the original author specified mode as 438 or calculated it as 0o600|0o60|0o6 ? He might and we should still like to see it as 0o666.
So the real issue is to specify the representation on retrieval. We already have a mechanism for that: subclasses that override __str__ and __repr__! Moreover, that mechanism works for all accesses that do not use an explicit format, not just those functions that are re-written to use some redundant new machinery. It also allows display representations that would *not* be legal input syntax and thus could *not* be the original representation. Two examples:
class octint(int):
'int that displays as octal'
def __str__(self):
return oct(self)
__repr__ = __str__
mode = octint(0o644)
print(mode)
class flags4(int):
'int that displays as 4 binary flags'
def __str__(self):
return '|{:04b}|'.format(self)
__repr__ = __str__
a = flags4(8)
b = flags4(3)
print(a, b, flags4(a|b))
def f(mode=octint(0o666), flags = flags4(0b1011)): pass
print(f.__defaults__)
import inspect
print(inspect.formatargspec(*inspect.getfullargspec(f)))
# prints
0o644
|1000| |0011| |1011|
(0o666, |1011|)
(mode=0o666, flags=|1011|)
So I think this issue should be changed to 'Add octint int subclass to stdlib and use it for default file modes'. The inspect module could be a place to put it. |
|
Date |
User |
Action |
Args |
2012-12-29 22:43:17 | terry.reedy | set | recipients:
+ terry.reedy, georg.brandl, mark.dickinson, larry, Arfrever, r.david.murray, carsten.klein@axn-software.de, serhiy.storchaka |
2012-12-29 22:43:17 | terry.reedy | set | messageid: <1356820997.14.0.388161654392.issue16801@psf.upfronthosting.co.za> |
2012-12-29 22:43:17 | terry.reedy | link | issue16801 messages |
2012-12-29 22:43:16 | terry.reedy | create | |
|