Paul Prescod wrote: > > Huaiyu Zhu wrote: > > > > ... > > > > I wonder how orthogonal would this be against the main development? Would > > it require a rebuild for each new release. Would it also require a patch > > each time? > > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! 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? On the other hand, if @ is buil-in, it can be overloaded depending on the type of the operands, which seems safer...I am not sure, but it seems that if syntax is module-dependent, things becomes really complex... > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. Well, that kind of change could potentially attract all the numeric community...which is probably a minority (and becoming smaller, based on the evolution of the number of science students in belgium) compared to the rest of the comp world, but still a significant minority. At least, it will attract one person for sure: me :-) 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... 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