On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote: > That said, and a bit off-tangent to your comment's main thrust, the time > spent on coding that repeated-division-by-2 optimization would, I think, > be better spent googling "Collatz Conjecture" -- avoiding writing > /any/ code. ;-)
That's a strange thing to say. >> Now, it's a different story if you're using the gmpy module. You DON'T >> want to use literals in loops involving gmpy, because they would have >> to be coerced to .mpz's on every pass through the loop. [...] > Yeah, good point. Few languages have compile time evaluation of > logically constant expressions. Surely that's an implementation issue rather than a language issue. > C++0x will have that feature (called > 'constexpr' IIRC) but in Python, current C++ etc. it's just a good idea > to precompute values, and name them, rather than computing them again > and again where they're needed. CPython 2.5 and on has a keyhole optimizer that replaces many constant expressions with pre-computed values. # Python 2.4 >>> dis.dis(compile('1+1', '', 'eval')) 0 0 LOAD_CONST 0 (1) 3 LOAD_CONST 0 (1) 6 BINARY_ADD 7 RETURN_VALUE # Python 2.5 >>> dis.dis(compile('1+1', '', 'eval')) 1 0 LOAD_CONST 1 (2) 3 RETURN_VALUE Unfortunately it doesn't help Mensanator's case, because there's no way to tell the compiler to generate mpz objects instead of int objects, and expressions such as gmpy.mpz(0) are not recognised as compile-time constants. >> Mine does when I use gmpy. Otherwise, the notion that "most names are >> constants" is generally false. > > No, it depends on what you mean by "constant". All names are constant. Always. The Python language does not support renaming names -- as far as I know, no language does. > The problem with Python, > as Google noted, is that the language is so excessively dynamic: even > names of routines are variables, Don't say that, that is confusing the name with the value. The terms "constant" and "variable" refer to the values bound to a name, not the name itself: what you mean is that even routines are variables. Consider the following Pascal declaration: const a = 1; var b: integer; Neither name 'a' nor 'b' ever change; a is always a and b is always b. You wouldn't describe b as a constant because the name never changes, would you? What matters is that the value assigned to the name can, or can't, be changed by the caller. Like any other language, Python *names* are always constant: you can create them at will (without needing a declaration); you can delete them (with the del statement, something Pascal doesn't allow you to do); but there's no way to change a name once it exists. Obviously it would be misleading to claim that Python name/object bindings ("variables") are therefore constant because of this. So how would I say what you are trying to say, but in a less-misleading fashion? Names can always (well, almost -- there are a few exceptions) be rebound, regardless of whether they are currently bound to a data object (string, int, float...) or a routine (function, method...). Since the name by which we refer to a function can be rebound, we refer to the name/object binding as variable rather than constant -- exactly the same as any other name/object binding. Or the shorter way: Since all names can be rebound, regardless of what value they have (int, string, function, whatever) all names are variables and Python has no constants other than special pre-defined names like None. > and there /are/ no named user defined > constants except logically, in the programmer's mind. Yes, that is correct, although there are tricks you can do to make slightly-more-constant-like constants, such as Alex Martelli's "constant module" recipe in the Cookbook, but there are no true constants in Python. > And logically > (that is, at the "in the programmer's mind" level), if you define > "constant" as a name whose value will not change after initialization, > then routine names are constants. Some languages enforce that, and in those languages, it makes sense to describe functions as constants. Python is not one of those languages. > However, if you define "constant" as only a global scope (that is, > module scope) name that denotes a boolean, numerical or string or Null > value and that doesn't change after initialization, then your statement > about the scarcity of constants appears to be true, but using a > practically useless definition. I won't speak for Mensanator, but I wouldn't be so restrictive about the *types* of data that constants can hold. Not in Python, at least, other languages can and do limit the types of constants to a handful of predefined types known to the compiler. Nor would I say that "constants" (note the scare-quotes) can only occur in module scope. There's nothing wrong with naming "constants" in other scopes, although I must admit I'm a tad less consistent about doing so than I should. -- Steven -- http://mail.python.org/mailman/listinfo/python-list