Why Do Python Lists Multiply Oddly? Exploring the CPython Source Code

Post by bmitc » Wed, Apr 10, 2024, 12:18 PM UTC

mapreduce wrote: post #90

bmitc wrote: post #85

Earlier quoted context omitted.

> these people need to roll up their sleeves and just learn the damn language You really have no choice but to do that. But the critique here is that some languages make this hard. And some languages, like Python, appear deceptively simple and consistent, when they are anything but. And as I pointed out, these decisions were not really required or designed to solve certain problems. They just kind of came about in Py…

> What problems is it solving that require the confusion that it generates? I think I answered that already. It keeps the language spec consistent and simpler. Imagine the complexity you have to add to the language spec to say that when we write [] we deal with the reference to this list except in the multiplication syntax a = [[]] * 5 where the inner [] is not a reference to the list but the list value! Such special…

Post by kerkeslager » Wed, Apr 10, 2024, 9:06 PM UTC

klyrs wrote: post #93

kerkeslager wrote: post #89

Earlier quoted context omitted.

The language spec isn't right you just like it. Sure, there are a lot of subjective aesthetics that go into the spec, but in this case, there are objective reasons for not liking this. It's a well-known footgun that causes bugs. And it's almost never what you want, so you end up doing something like this: def f(xs = None): # Are these two lines actually faster than the # interpreter creating defaults at call time? if…

> # Are these two lines actually faster than the # interpreter creating defaults at call time? You're proposing that the interpreter add a check for every default parameter in every function signature; that it should optionally fire off arbitrary code for each and every one. And when you consider that high-performance Python involves writing C extensions, your proposal would be to move that check out of the compiled…

    LIST_OF_X = []

    def foo(xs = LIST_OF_X):
        ...

Post by shiandow » Thu, Apr 11, 2024, 9:49 AM UTC

kerkeslager wrote: post #73

shiandow wrote: post #35

Earlier quoted context omitted.

In that case what would you expect the following to return? a = [] b = [a]*4 a.append(1) print(b) I mean it is possible to change Python and make [...]*n a shorthand for "repeat this statement n times" but that would be odd on its own. Lists pass by reference, tuples pass by value, if you want to understand Python you're just going to have to get used to that distinction. There are other options, but most are worse.

> Lists pass by reference, tuples pass by value, if you want to understand Python you're just going to have to get used to that distinction. Is that true? I haven't looked at the implementation so I can't say it's impossible, but it would be extremely surprising to me if tuples passed by value, because tuples longer than the size operated upon my individual processor instructions would become expensive to pass around…

    t = (1,2)
    def f(x):
        return x is t

   f(t), f((1,2)), (1,2) is (1,2) # -> True, False, True

Post by kerkeslager » Thu, Apr 11, 2024, 3:24 PM UTC

klyrs wrote: post #95

kerkeslager wrote: post #94

Earlier quoted context omitted.

> You're proposing that the interpreter add a check for every default parameter in every function signature No, that's not what I'm proposing. Why would it check anything? Just evaluate the given default expression at call time. If you don't want the overhead of an expression, don't put a default. You can also do defaults like: LIST_OF_X = [] def foo(xs = LIST_OF_X): ... ...if you want the other behavior. This does a…

Your list there is mutable. Isn't that what you meant to solve with this?

    def foo(xs = []):
        xs.append(1)
        print(xs) # always prints [1]

    DEFAULT = []
    def bar(xs = DEFAULT):
        xs.append(1)
        print(xs) # prints [1], [1,1], [1,1,1], etc.

Post by aeonik » Fri, Apr 12, 2024, 10:22 PM UTC

kerkeslager wrote: post #88

aeonik wrote: post #72

Earlier quoted context omitted.

I wouldn't recommend just throwing the idea away, it just needs to be approached with care. You can do it in a type safe way. Research Rank Polymorphism and Array Languages: https://en.m.wikipedia.org/wiki/Array_programming https://arxiv.org/abs/1907.00509

I mean, is there anything there that couldn't just be a library function? Not everything has to be an operator.