Skip Montanaro wrote: > > There are several active or could-be-active PEPs related to Python's numeric > behavior: > > S 211 pep-0211.txt Adding A New Outer Product Operator Wilson > S 228 pep-0228.txt Reworking Python's Numeric Model Zadka > S 237 pep-0237.txt Unifying Long Integers and Integers Zadka > S 238 pep-0238.txt Non-integer Division Zadka > S 239 pep-0239.txt Adding a Rational Type to Python Zadka > S 240 pep-0240.txt Adding a Rational Literal to Python Zadka > S 242 pep-0242.txt Numeric Kinds Dubois > > Instead of implementing them piecemeal, shouldn't we be considering them as > a related group? For example, implementing any or all of PEPs 237, 239 and > 240 might well have an effect on what needs to be done for PEP 238. With > slight modifications, the proposals in PEP 242 might well subsume PEP 238's > functionality in a different way. > > If the semantics of arithmetic are going to change, I think they should > change in the context of expanded capability in the language. May I suggest that these rather controversial changes be carried out on a separate branch of the Python source tree before adding them to the trunk ?! The reasoning here is that numerics are so low-level that porting applications to a new release implementing these changes will cause a lot of work (mostly due to the dynamic nature of Python). Another suggestion I would like to make is that the new semantics are first implemented using alternative subclassed numeric objects (e.g. newint()) which can then live side-by-side with the old semantics types for a few releases until they replace the old types. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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