Skip Montanaro wrote: > >... > > By "right" I mean that we can arrive at a long-term stable numeric model > that will be accepted by both the Python community as a whole *and* by the > decision makers who will vote thumbs up or down on adopting Python in their > organizations. But I don't think that there is any numeric model that will be accepted by the whole Python community. Some will like any change and some will dislike it. Likely there will appear to be equal numbers on either side of any issue because each flame is answered by one or more counter-flames. >... > By having a well-considered overall plan for Python's numeric behavior, if > you have to make an incompatible change today, another next year and a third > two years after that, you can point to the plan that shows people where > you're headed, how you plan to get there, and how they can write their > programs in the meantime so as to be as resilient as possible. I'm not a against such a plan but I don't think it can be designed in a committee. It would be largely the vision of one or two like-minded people with the same weighting of factors such as performance, ease of use, backwards compatibility and so forth. If you put an representation-obsessed engineer in the same committee with a purity-obsessed mathematician you'll find that the only thing they can agree on is to disagree. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
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