Gregory Lielens wrote: > > ... > > It seems potentially more dangerous than statically adding a new > operator, no? If two modules > install incompatible changes of syntax, for exmaple if they demand both > @ as operator, they will be considered as incompatible? I think that the idea is that one module would be in the Matrix sublanguage and another would be in an XML sublanguage. That way your context shifts are clear. Presumably the first or second line of the file says what sublanguage you are using. > Anyway, it seems that that audience (numeric people) was targeted by > python since the beginning, because why the hell include complex numbers > as built-in type if not? They are of a less general usefullness than > matrices, imho, the last can at least be used for graphic stuff... Okay, but look at the syntactic support complex numbers needed. Just "j". The same for string processing. We just reused most of the existing operators. If you guys made a really kick-ass matrix package that everyone loved and didn't need any new syntax, Guido might be tempted to make matrices a built-in type also! The funny thing is that most of the Python syntax that I don't use today is ALREADY for matrix operations: foo[x,y:a,b] foo()[...] -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html
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