Hello, On Tue, 16 Jun 2020 14:21:55 +0900 "Stephen J. Turnbull" <turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Paul Sokolovsky writes: > > > I'd encourage everyone who thinks "I need a very special operator > > just for me", > > I don't think anybody who posts here thinks that, though. Sure, everyone thinks that they invented the next best thing since sliced bread. So, the natural turn of the discussion is that maybe it's not. And then maybe, the turn of the discussion is how to let different people do what they want, without forcing their ideas on everyone else. > They think > "wow, I could really use this, and I bet other people too." > math.isclose probably tempts somebody somewhere in the world about > once a minute. Of course they often find out differently -- and > mostly when they do, they're OK with that. (There are also joke or > half-joke proposals, but that's a different thing, and we're all in on > those jokes.) > > > instead think in terms "Python needs ability to define custom > > operators". > > Reading that *literally* (I take it seriously, below): Python has that > ability already. It's just that the set of operator *symbols* is > fixed (in a given version of Python), and almost exhausted for > numerical types (but see below ;-). This has an important implication > for readability: the associativity and precedence order of the symbols > is also fixed, and only needs to be learned once.[1] 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. Take the recent example - "number-crunching people" came by to claim the "~=" operator, but "everyone else" knows that that operator is related to regexp/pattern matching. > Python has that ability already. It absolutely has. It's just requires more legwork than it really should take, and that needs to be changed. > operator *symbols* is fixed > and almost exhausted > the associativity and precedence order of the symbols is also fixed Well, operators, their associativity and precedence are fixed in *the language core*. But Python is multi-level structure. So, if you want to introduce a new operator symbol: 1. You subclass a tokenizer, and add lexing for your operator. Simple usages can also be handled on the level of tokenizer. Literally if you're interested in simple things like "a ~= b", you just turn it into "isclose(a, b)". 2. More general and complex cases require subclassing an AST parser. That will allow to deal with arbitrary precedence/associativity of new operators. 3. Then, you just use subclassed tokenizer and parser for your sources. To make it all easy, easiness of p.3 is important. There's a PEP on that: https://www.python.org/dev/peps/pep-0511/ , which fell victim of Python politburo self-censorship, but its usefulness is not less because of that. [] > > Recent example: implementation of "from __future__ import braces": > > https://github.com/NeKitDS/braces.py . > > I strongly recommend the idiom: > > import __future__ as __watch_out_for_jokes__ > > (Recent? Isn't that more than a decade old? Hmmm: > > >>> from __future__ import braces > File "<stdin>", line 1 > SyntaxError: not a chance > > Different implementation, I guess. :-D :-þ :-D :-þ :-D :-þ :-D) I'm not sure who didn't get a joke here. Let me just say that it's indeed a very old and buggy implementation of that feature from the proverbial Python politburo. Such old, that's it's not funny any more. There's a reason why even projects otherwise largely written in Python, use a different language (like JavaScript) when they need easy-for-users scripting capabilities. A random example is https://github.com/frida/frida . That's because such projects want to let their users write one-liners like: for_each_kaboom(function (kaboom) {print("here's kaboom", saboom); for (sub in kaboom) print(sub); }) And while majority of people just leave Python behind in such cases, some people spent so much time with Python, that they refuse to (for they know that outside there's only bigger mess). Instead, they look how to extend Python to do what they want (without necessary stuffing it all back in the core). > > Steve > [] -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/MMALRODWDR3W24ALSOLD4LGIFNSYFKUM/ Code of Conduct: http://python.org/psf/codeofconduct/
