Death to tuples!
mwm at mired.org
Fri Dec 2 18:51:39 CET 2005
Antoon Pardon <apardon at forel.vub.ac.be> writes:
> On 2005-12-02, Bengt Richter <bokr at oz.net> wrote:
>> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>>>On 2005-11-30, Duncan Booth <duncan.booth at invalid.invalid> 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
>> ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>determining the default value.
>> 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
or an integer:
>>> a = 1234
>>> a is 1234
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)
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)
> 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 Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
More information about the Python-list