> > Greg Wilson wrote: > > > > .... Saying, "But you don't have to use these new operators if > > you don't want to," is a red herring --- if I want to understand/modify > > other people's code, I'll have to learn 'em (just as I've had to learn > > most of Perl's syntax, one painful special case at a time, in order to use > > the LDAP, XML, CGI, and imaging libraries). > > > > So: I would like this (linear algebra, min/max, other notation) to happen, > > but only if there's an extensible, scalable framework for user-defined > > libraries to add operators to Python, in the same way that they can now > > add new classes. > Paul Prescod wrote: > > I don't want to come to someone else's code and have to learn a bunch > of operators that they invented, for the same reason that you don't > want to learn all of Perl's built-in special cases. Greg Wilson writes: I strongly agree. If there isn't a "new operator definition" mechanism that maintains Python's simplicity, then I believe we should stick to functions and methods, rather than introducing "just a few" new operators for linear algebra (or regular expressions, or [your favorite topic goes here]). > Eric Raymond wrote: > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. > > The design question becomes: what undefined binary tokens do we want > to add the the language core? With what precedence? What is the > compiler to assume about associativity? This is an interesting alternative I hadn't thought of --- add operators, with associated special methods and in-place assignment forms, but do not provide a "standard" definition (i.e. leave all functionality open to the user). Thanks, Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4