3 ms·

Execution time, not parse time. It's a side effect of function declarations being statements that are executed, not the list/dict itself. It would happen with a

• mattclarkdotnet 8mo ago
  Let's not get started on the cached shared object refs for small integers....
  • zahlman 8mo ago
    What realistic use case do you have for caring about whether two integers of the same value are distinct objects? Modern versions of Python warn about doing unpredicatble things with `is` exactly because you are not supposed to do those things. Valid use cases for `is` at all are rare.
    • thaumasiotes 8mo ago
      > Valid use cases for `is` at all are rare. There might not be that many of them, depending on how you count, but they're not rare in the slightest. For example, you have to use `is` in the common case where you want the default value of a function argument to be an empty list.
      • fwip 7mo ago
        Could you expand on this? For example, this works just fine: def silly_append(item, orig=[]): return orig + [item] Edit: Oh, I think you probably mean in cases where you're mutating the input list.
      • zahlman 7mo ago
        I assume you refer to the `is None` idiom. That happens often enough, but I count it as exactly one use case, and I think it's usually poorly considered anyway. Again, you probably don't actually want the default value to be an empty list, because it doesn't make a lot of sense to mutate something that the caller isn't actually required to provide (unless the caller never provides it and you're just abusing the default-argument behaviour for some kind of cache). Using, for example, `()` as a default argument, and cleaning up your logic to not do those mutations, is commonly simpler and more expressive. A lot of the community has the idea that a tuple should represent heterogeneous fixed-length data and a list should be homogeneous; but I consider (im)mutability to be a much more interesting property of types.
    • germandiago 7mo ago
      if v is not None as opposed to if not v is one of those use cases if you store 0 or False or an empty list, etc.
• mattclarkdotnet 8mo ago
  It's still ridiculous. A hypothetical Python4 would treat function declarations as declarations not executable statements, with no impact on real world code except to remove all the boilerplate checks.
  • boxed 8mo ago
    You think so but then you write a function with a default argument pointing to some variable that is a list and now suddenly the semantics of that are... what?
    • codesnik 8mo ago
      you could just treat argument initialization as an executable expression which is called every time you call a function. If you have a=[], then it's a new [] every time. If a=MYLIST then it's a reference to the same MYLIST. Simple. And most sane languages do it this way, I really don't know why python has (and maintain) this quirk.
      • 1718627440 8mo ago
        What are the semantics of the following: b = ComplexObject (...) # do things with b def foo (self, arg=b): # use b return foo Should it create a copy of b every time the function is invoked? If you want that right now, you can just call b.copy (), when you always create that copy, then you can not implement the current choice. Should the semantic of this be any different? : def foo (self, arg=ComplexObject (...)): Now imagine a: ComplexObject = list
        • codesnik 8mo ago
          I wonder, why that kind of ambiguity or complexity even comes to your mind at all. Just because python is weird? def foo(self, arg=expression): could, and should work as if it was written like this (pseudocode) def foo(self, arg?): if is_not_given(arg): arg=expression if "expression" is a literal or a constructor, it'd be called right there and produce new object, if "expression" is a reference to an object in outer scope, it'd be still the same object. it's a simple code transformation, very, very predictable behavior, and most languages with closures and default values for arguments do it this way. Except python.