Paul Sokolovsky writes: > But that's exactly my point: the core of the language is already > quite comprehensive, well-defined, and even crowded. Stuffing even > more stuff into it just doesn't scale.
Python *arithmetic* is comprehensive, well-defined, even crowded, and adding operators doesn't scale. Otherwise, it's generally quite sparse. Most classes define a very few operators, and mostly use named methods. I can't recall wanting a new operator symbol for any class myself, and the most plausible cases for Python at large we already got not so long ago, the walrus operator (which isn't a customizable operator in the sense we mean here) and the matmul operator. NULL-coalescing operators remain in discussion, but they're still of dubiously large benefit and the proposed syntaxes have yet to converge on a single candidate syntax IIRC. > > Python has [the] ability [to define custom operators] already. > > It absolutely has. It's just requires more legwork than it really > should take, and that needs to be changed. Python is Turing-complete. It doesn't *need* anything. What you mean is that there are features you want that it doesn't have. And you (deliberately?) ignored the crucial distinction I was making between "custom operators" and "custom operator symbols". If there are enough operator symbols available, and there usually are, you just choose them and def dunders. That's hardly excessive legwork, although sometimes the analogy of the arithmetic operators to the operations of your class are somewhat strained. > Folks look how to extend Python to do what they want (without > necessary stuffing it all back in the core). Sure. That's the whole point of a programming language, of course: extending your software's capabilities without creating a monolith. The conflict here is that you want to take advantage of the well- structured Python language, then tweak it in ways that will be less readable to somebody who knows only Python-Dev Python. We in general don't want that -- we want a read-everywhere language. That's what the rejection rationale for PEP 511 says explicitly. We know about the advantages you're extolling, and we just don't want them, given the expected readability cost. If you want support from anybody who matters (I don't matter much :-), you need to provide convincing arguments that the facilities for customization we already have aren't enough. You keep asserting that they aren't, but without concrete evidence. By the way this: > Python politburo self-censorship, in no way helps your case. Python-Dev is very opinionated, and that is reflected in the language. It is not, however, censorship in any sense. Regards, Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MX33BZWIBBYQICBX7QMQRY6QYGUPWCAO/ Code of Conduct: http://python.org/psf/codeofconduct/
