On 12 February 2017 at 14:51, Markus Meskanen <markusmeska...@gmail.com> wrote: > 1. Allowing the class to be used in the method's header, f.e. for typing and > decorators: > > @decorate(MyClass) > def MyClass.method(self, other: MyClass) -> List[MyClass]: > ... > > This is useful since you can't refer the class itself inside of its body. At > the moment the way to use typing is to write the class's name as a string... > It feels awful.
You realize now that if we accept this change, and given your example, any "well behaved" Python code with markup will in a couple months required to be like class MyClass: """Docstring.""" def MyClass.__init__(self: MyClass, ...) -> None: ... # add other methods here. And all it will take is some bureaucratic minded person to put that as default option in some highly used linter, like the one that used-to-be-known-as-pep8. (And hint: what do you think is the mind orientation of contributors to linter code? :-) ) As a developer constrained to silly rules in automatic linters (like nazi-counting the number of blank lines everywhere) due to project manager "it's simples to just stand by the linters defaults" I feel quire worried about that. So, no, strings for type hinting are much less awful than effectively killing the class body in big projects. Not that this is much more serious than the worries about def x["fnord"][5]["gnorts"]method(self, bla): ... Which will never be used in sane code anyways. It is the real, present, danger of of having mandates in whole projects that all methods be defined outside the class body just because of "clean type-hinting". I now am much, much, more scared of this proposal than before, and I was already at -1 . Please, just let this R.I.P. js -><- _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/