Raymond Hettinger wrote: >>>No thanks. That is its own can of worms. The obvious solutions (like const >>>declarations, macros, or a syntax to force compile-time expression >>>evaluation) >>>are unlikely to sit well because they run afoul Python's deeply ingrained >>>dynamism. >>> >>> >> >>I think perhaps you haven't been paying close attention to Fredrik's >>proposal. >> > Yes, I have been. That is one of the three options I listed above. > Each has its own issues. > > The static() keyword works like Forth's brackets for forcing > compile-time evaluation. The issue for us is that unlike other Python > expressions, there are inconvenient limitiations on what can be > expressed inside: > > five = 5 > eight = [8] > def f(x, six=6): > seven = 7 > a = static(five + 4) # this is legal > b = static(six + 4) # this is illegal > c = static(seven + 4) # this is illegal > d = static(eight + [4]) # this is illegal Why would the last line be illegal? > > That will be a perpetual maintenance trap and conundrum for newbies. In contrary to other "newbie traps" such as mutable default arguments, if this would give a clear exception message like "function-local name cannot be used in static expression", I can't imagine it would be a bigger problem than e.g. "why is my floating point result incorrect". Georg
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