Antoon Pardon <[EMAIL PROTECTED]> writes: > On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote: >> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>>On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: >>>> Antoon Pardon wrote: >>>I think one could argue that since '[]' is normally evaluated when >>>the expression containing it is excuted, it should also be executed >>>when a function is called, where '[]' is contained in the expression >> ^^^^^^^^^^^^^^^^^^^^^^^[1] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>determining the default value. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^[2] >> Ok, but "[]" (without the quotes) is just one possible expression, so >> presumably you have to follow your rules for all default value expressions. >> Plain [] evaluates to a fresh new empty list whenever it is evaluated, > Yes, one of the questions I have is why python people whould consider > it a problem if it wasn't.
That would make [] behave differently from [compute_a_value()]. This doesn't seem like a good idea. > Personnaly I expect the following pieces of code > a = <const expression> > b = <same expression> > to be equivallent with > a = <const expression> > b = a > But that isn't the case when the const expression is a list. It isn't the case when the const expression is a tuple, either: x = (1, 2) >>> (1, 2) is x False >>> or an integer: >>> a = 1234 >>> a is 1234 False >>> Every value (in the sense of a syntactic element that's a value, and not a keyword, variable, or other construct) occuring in a program should represent a different object. If the compiler can prove that an value can't be changed, it's allowed to use a single instance for all occurences of that value. Is there *any* language that behaves differently from this? > A person looking at: > a = [1 , 2] > sees something resembling > a = (1 , 2) > Yet the two are treated very differently. As far as I understand the > first is translated into somekind of list((1,2)) statement while > the second is build at compile time and just bound. No, that translation doesn't happen. [1, 2] builds a list of values. (1, 2) builds and binds a constant, which is only possible because it, unlike [1, 2], *is* a constant. list(1, 2) calls the function "list" on a pair of values: >>> def f(): ... a = [1, 2] ... b = list(1, 2) ... c = (1, 2) ... >>> dis.dis(f) 2 0 LOAD_CONST 1 (1) 3 LOAD_CONST 2 (2) 6 BUILD_LIST 2 9 STORE_FAST 0 (a) 3 12 LOAD_GLOBAL 1 (list) 15 LOAD_CONST 1 (1) 18 LOAD_CONST 2 (2) 21 CALL_FUNCTION 2 24 STORE_FAST 2 (b) 4 27 LOAD_CONST 3 ((1, 2)) 30 STORE_FAST 1 (c) 33 LOAD_CONST 0 (None) 36 RETURN_VALUE > This seems to go against the pythonic spirit of explicit is > better than implicit. Even if "[arg]" were just syntactic sugar for "list(arg)", why would that be "implicit" in some way? > It also seems to go against the way default arguments are treated. Only if you don't understand how default arguments are treated. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list