Re: [Python-ideas] staticmethod and classmethod should be callable
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 staticmethod and classmethod callable. > >You have to compare the advantages of making them callable vs. the >advantages of*not* making them callable. You have also to weight the disadvantages of making them callable and the cost of making them callable. That's what the OP is trying to do. You were just asked if there were any disadvantages or costs. Are there or not? If so, what are they? -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow mutable builtin types (optionally)
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 serves other purposes - extension would benefit for allowing direct access to any of its type attributes Petr, what do you think ? Eloi From: Python-ideas on behalf of Eloi Gaudry Sent: Tuesday, May 8, 2018 9:26:47 AM To: encu...@gmail.com; python-ideas@python.org Subject: Re: [Python-ideas] Allow mutable builtin types (optionally) On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote: > On 05/07/18 11:37, Eloi Gaudry wrote: > > I mean, to my knowledge, there is no reason why a type should be > > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html > > ) to > > be able to change its attributes at Python level. > > One reason is sub-interpreter support: you can have multiple > interpreters per process, and those shouldn't influence each other. > (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor > t) > > With heap types, each sub-interpreter can have its own copy of the > type > object. But with builtins, changes done in one interpreter would be > visible in all the others. Yes, this could be a reason, but if you don't rely on such a feature neither implicitly nor explicitly ? I mean, our types are built-in and should be considered as immutable across interpreters. And we (as most users I guess) are only running one interpreter. In case several intepreters are used, it would make sense to have a non-heap type that would be seen as a singleton across all of them, no ? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
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 with that idea is that staticmethod, classmethod can actually arbitrary objects, not only Python functions. In fact, even this object can be created: >>> staticmethod(42) So in that sense, they behave more like "method" which can also wrap arbitrary callables (in this case, callability is checked). So I'm vaguely thinking of putting "method", "staticmethod" and "classmethod" on top of a common base class for things wrapping callables. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
> > > 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) ... >>> @staticmethod ... def bar(arg): ... print(arg) ... >>> foo(int) # this should work Traceback (most recent call last): File "", line 1, in TypeError: 'classmethod' object is not callable >>> bar(42) # this should work too Traceback (most recent call last): File "", line 1, in TypeError: 'staticmethod' object is not callable 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. But I'm not sure. Calling in Python is too complicated to fully understand. Regards, -- INADA Naoki ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
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 staticmethod/classmethod anyway, should we make them callable? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
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 advantages of making them callable vs. the advantages of *not* making them callable. You have also to weight the disadvantages of making them callable and the cost of making them callable. I think that consistency *is* good to have, so I consider that one reason to make them callable. Are there any reasons for *not* making them callable? Status quo wins. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
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. the advantages of *not* making them callable. I think that consistency *is* good to have, so I consider that one reason to make them callable. Are there any reasons for *not* making them callable? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] [issue33865] [EASY] Missing code page aliases: "unknown encoding: 874"
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 all of the CPxxx encodings have multiple aliases[1], so I just don't see the point unless numeric-only code page designations are baked in to default "locales"[2] in official releases by major OS vendors. And probably not even then, since it should be easy enough to provide a proper "locale" and/or PYTHONIOENCODING setting. Of course we should help the reporter figure out what's going on and help them fix it with appropriate system configuration. If that doesn't work, then (and *only then*) we could think about doing a stupid thing. Footnotes: [1] Granted, "874" only has "windows-874" registered with the IANA, so it's kind of salient. Still, if numeric-only aliases were a "thing", surely we'd have heard about it by now---I first encountered Thai encodings in 1990 (ok, that was TIS 620, but windows-874 is basically TIS plus Microsoft punctuation extensions IIRC), Thais do use computers in their native language a lot. [2] Scare quotes to refer to appropriate platform facilities, as neither Windows nor Mac OS is strictly conformant to POSIX on this. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
