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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
