On 2018-06-21 01:33, Serhiy Storchaka wrote:
21.06.18 10:45, Jeroen Demeyer пише:
>On 2018-06-20 19:33, Serhiy Storchaka wrote:
>>20.06.18 12:56, Jeroen Demeyer пише:
>>>Are there any reasons to*not* make staticmethod and classmethod
>>>callable?
>>
>>There were no reasons to make
This request didn't have a lot of traction, but I still consider this is
something that would need to be supported (2 lines of code to be changed; no
regression so far with python 2 and python 3).
My main points are:
- HEAP_TYPE is not really used (as anyone being using it ?)
- HEAP_TYPE
On 2018-06-21 11:00, INADA Naoki wrote:
When Python 4, I think we can even throw away classmethod and
staticmethod object.
PyFunction can have binding flag instead, like METH_CLASS and
METH_STATIC for PyCFunction.
classmethod and staticmethod is just a function which modify the flag.
One issue
>
>
> My question is really: assuming that we redesign
> staticmethod/classmethod anyway, should we make them callable?
>
I think so. staticmethod and classmethod should affect descriptor
behavior.
And it should behave as normal function.
>>> @classmethod
... def foo(cls):
... print(cls)
On 2018-06-21 10:33, Serhiy Storchaka wrote:
Status quo wins.
Well, I'm already planning to make changes to staticmethod/classmethod
(not right now, but it's on my post-PEP-580 roadmap). So the "status
quo" argument doesn't apply.
My question is really: assuming that we redesign
21.06.18 10:45, Jeroen Demeyer пише:
On 2018-06-20 19:33, Serhiy Storchaka wrote:
20.06.18 12:56, Jeroen Demeyer пише:
Are there any reasons to *not* make staticmethod and classmethod
callable?
There were no reasons to make staticmethod and classmethod callable.
You have to compare the
On 2018-06-20 19:33, Serhiy Storchaka wrote:
20.06.18 12:56, Jeroen Demeyer пише:
Are there any reasons to *not* make staticmethod and classmethod callable?
There were no reasons to make staticmethod and classmethod callable.
You have to compare the advantages of making them callable vs.
Ronald Oussoren writes:
> Possibly just for the “cp…” encodings, but IMHO only if we confirm
> that the code to look for the preferred encoding returns a codepage
> number on Windows and changing that code leads to worse results
> than adding numeric aliases for the “cp…” encodings.
Almost