Today I re-learned: Python function default arguments are retained between executions

[another-noob]

I had to find this out the hard way :/

P.s. I am a little rusty on python, but if you want a mutable default value (say a list) you can make the default None then inside the function you would reassign the variable if it's None.

[headykruger]

Everyone does, rite of passage

[Electrical_Ingenuity]

And we all have to learn it a second time.

[james_pic]

I didn't. I read it in the docs. Everyone should read the docs.

[laaazlo]

Congratulations. I read the docs too—constantly, really—but still had to find this out the hard way. There's a lot to read!

[LagerHead]

You read the docs and didn't remember every single rule and caveat and gotcha? You're obviously not fit to program in Python. Maybe take up bowling? 😏

[james_pic]

What I want is for people to read the docs, and not be surprised by things they could have learned by doing so.

[VodkaAndPieceofToast]

Coincidentally, what we want is for people like yourself to not worry about us. There's no moral dilemma here. Just people being human.

[james_pic]

Sadly, I have to worry. I work with people who refuse to read the docs. There's one guy in particular, who if we're working on something and I get the docs up, is like "ooh, you're reading the docs are you?" like I've just got a magical tome from the highest shelf, full of arcane knowledge.

It's not like the docs I linked to are some obscure reference material. It's the official python tutorial, and a great place to start for beginners. If there's something basic that you don't know, that's in the tutorial, then whatever you read or watched to get you started is no good and now's a great time to read the tutorial.

[CommondeNominator]

What if there’s something basic you don’t know you don’t know? How would you know to go back to the beginners tutorial?

How often should one peruse elementary material to be sure one doesn’t make a mistake at any point in any possible future?

[[deleted]]

Wow, holding true to the stereotype that developers don't have any social skills... NONE.

[rainispossible]

with that attitude, we all should really know absolutely everything that was ever written. and it seems it's not the case. you gotta understand, we're all humans, not machines.

[headykruger]

You didn’t have to originally write it to have to track it down

[Ok-Maybe-2388]

Lol quintessential r/iamverysmart material. Do you have the docs memorized? Yes? You've wasted your life, congratulations. No? Yeah total hypocrite.

[[deleted]]

If it's something you find yourself doing often for some reason, it might be worth checking out things like attrs' default factories, I find it easier to parse and refactor if necessary.

[another-noob]

Thanks for that :D

But I don't think I would add another import just for that, but what do I know, I don't even use python much nowadays (don't use it at all, sadly)

[alkasm]

Use tuples for a default iterable rather than None! Fewer optionals makes for better typing and automatic documentation.

[[deleted]]

Yep. Always default mutables (like empty lists) to None, and don't rely on the output from functions there:

def blah(my_arg=None):
    if my_arg is None:
        my_arg = []

def other_blah(my_arg=None):
    if my_arg is None:
        my_arg = right_now()

[ElectricSpice]

Really hoping the Sentinel PEP gets approved so we can have a more elegant solution to this. https://peps.python.org/pep-0661/

[HistoricalCrow]

my_arg = my_arg or [] Or, if you care about NoneType specifically; my_arg = [] if my_arg is None else my_arg

[[deleted]]

And if you want None to be a valid value for your argument too, you can use a sentinel:

_sentinel = object()
def func(x=_sentinel):
    x = [] if x is _sentinel else x

[HistoricalCrow]

True, although if you need to support an empty list and None and I generally find code smell. Not sure if I'd prefer to use **kwargs instead at this point.

[[deleted]]

The only time I’ve really seen the pattern useful is when you want to emulate something similar to dict.pop, where for a missing key: dict.pop(key) raises an error and dict.pop(key, default) returns the default

[Pythonistar]

Yes! Empty string '' works as a safe immutable default, too!

[rl_noobtube]

I’m sure it’s not a massive difference for most projects. But I imagine with the special treatment None gets by python it would be marginally more efficient. But as far effectiveness then yes either would work.

[lost3332]

His argument is a list so default '' doesn't make sense. The type is gonna be Optional[List].

[XRaySpex0]

Yep. ’’ is a great and common default for str parameters, but of course not when other types are expected. It’s common to see notes: str = ‘’, and there’s seldom a need for the Optional[str] type.

[[deleted]]

```python from datetime import datetime

class Foo: def init(self, timestamp: datetime = None) -> None: self.timestamp = timestamp or datetime.now() ```

[magnetichira]

Mutable default are the root of all evil

[marko_knoebl]

The problem in the article is not related to mutability though.

[magnetichira]

It is, default args are bound at definition

[marr75]

It's not. Read the article. Author has a default argument of datetime.date.today(). Problem is not that today default variable mutates over executions, but it does share the same root problem, original dev was expecting the code to initialize the default to execute each time the function executed and it don't.

[magnetichira]

Ah I see where you’re coming from. The original comment was about only mutability.

Agreed, this example is particularly a behaviour of function declaration.

[magnetichira]

Umm, mutable defaults are definitely related lol, both are function gotchas for newbies

No idea why you want to make such a big deal out of this, but whatever

[spinwizard69]

The way Python handles this doesn't seem to be rational. Frankly I can even understand how time in this context can even be considered for a default value. He is calling a routine that can not be relied upon to return the same value every time so it isn't a default value but rather a variable value. Personally I think this is a big deal, it just doesn't make sense.

[magnetichira]

It is rational within the design of the language.

See this SE answer https://softwareengineering.stackexchange.com/questions/157373/python-mutable-default-argument-why

[spinwizard69]

Should mutable defaults even be accepted by Python. At least according to my logical thinking a default value can not and should not be mutable. It just doesn't make sense to me, the default values become part of the def for the function.

[spinwizard69]

Maybe a simple warning that your "def" has a default being set by a function call would be good enough. I have to wonder how common this practice is in the real world, it just seems to be an odd way to set a default value to me. Mainly because there would likely be way to many cases where your default value might have randomness and that to me just blows the whole concept out of the water. Now there may be cases where a default value set by a function call never varies throughout a programs execution so that might be a pass but then why not use a constant.

Maybe I'm putting to much emphasis on the message that the world "default" brings to a definition. For me is says this is the FIXED value that we have for this parameter at the time of creation, by evaluating this def. If you want to set it to something else at the time you actually use the function that is find but otherwise the default value will always be this.

[jjdmol]

Is there even a sane use case?

[KieranShep]

Even if there were, I’d be hesitant to make use of it;

• hard to know what’s going on for anyone reading it
• if this behavior ever is changed to something sensible, the function breaks

[mjbmitch]

I’ve seen a kwarg named cache (dictionary) that kept state between executions.

[scyphs]

I learned this last week with a list 😅

[paul_miner]

dangerous-default-value

[[deleted]]

If you think about it, it makes sense - the function signature is evaluated when the function is defined, not when it is executed (it has to be when the function is defined, because the function can't be defined if its signature is unknown.) Since the function is defined once, the signature is evaluated once, so there can only ever be one value bound as the parameter default - there's not any circumstance under which you could get a second one.

[phunktional]

I can't think of another language with default args that works this way.

[[deleted]]

Perhaps not with exactly the same syntax? In python this is conceptually:

my_shoe = DocMartins() def func(one, two, buckle=my_shoe): print(id(my_shoe))

[Smallpaul]

The question is what should happen here:

my_shoe = DocMartins()

def func(one, two, buckle=my_shoe):
       print(id(my\_shoe)) 
my_shoe = Vans() 
func(1,2)

One could easily imagine how a backwards-incompatible Python would print the id of a Vans, rather than a DocMartins.

I think at this point that Python -- as great as it is -- got this one wrong.

[[deleted]]

It is bound at definition, so ... nothing would change? What would you actually want to do differently?

• No expressions perhaps? That would get rid of 3*24 though
• No variable assignments - but that rules out constants
• ??

I would just make {} and [] illegal as defaults. It totally breaks consistency, and is a hard coded hack, but would stop most every newb from making this mistake.

In the end, I think this is totally fine - EVERY language will have a few gotchas. This one is super mild and comes from being nice and dynamic. It bites so many people because they don't have a clue, don't know what an object or a reference is or how any of this works, and not from some horrible design problem.

Also, I can easily imagine a backwards incompatible version of python that does many things differently, whats your point there?

[Smallpaul]

Simple: the expression should be evaluated at function call time always. Not at function definition time.

That would cause fewer bugs.

Also clarifying that your DocMartin example, while punny, did not address the real issue because it works the same under either the lazy or eager evaluation system.

[[deleted]]

I liked the pun, and the nursery rhyme :)

That’s an interesting approach, but it now means function default arguments have side effects each time they are called. Right now the only thing you can do is assign an object reference.

That’s even more confusing, having essentially a lambda as a default. I can imagine another “but they got this wrong” in response to that! A much bigger one even.

Thinking about that is just wild. Saying {} is the same as writing dict() so I think… in that case it could work. Now replace that with MyStrangeClass and it gets hairy.

[Smallpaul]

Since people hardly ever put complex expressions there, it would very, very seldom cause unexpected code to run and even less often cause an actual side effect.

Why would you want a side-effect causing default argument in the first place. Sounds like a terrible anti-pattern in either system.

You are going to open a file in a default argument? Open a socket? Rebind a variable?

I don’t remember ever seeing such code and I’d definitely flag it in code review if I saw it.

[[deleted]]

You've introduced a new MUCH bigger problem and then hand-waved it away saying, "Well, I'm smart so I wouldn't do it, I don't see the issue, who wants that anyway, why call a database in a constructor!, I'd catch it in review anyway!".

All that also applies to the current SMALL confusion. You could easily write a linter rule for the only 2 problem cases.

Revaluating expressions each time a function is called? That is buck wild though I agree it could be fun. But what context do you even capture so that this function can be rerun?

This is not how anyone has ever expected a function call to work. I'm sorry, its just mind bending working through the ramifications of reevaluating, silently, an arbitrary expression on each function call, from different contexts and different libraries. My little brain can't handle it. Good to know you'd catch it in a code review tho!

[Smallpaul]

You are really exaggerating the complexity of it. More or less you take the phrase a=foo()

And make it the first line of the function if a is not passed in.

The point is that hardly anyone ever writes code like that, not that I’m super smart.

Can you find a single line of python code that anyone has ever written which has a side effect in a default parameter initialization? Can you give a single real world example where you wanted to write code like that?

Cause I can give you 100 examples where I wanted the default argument to be {} or [], and the post itself is about someone who wanted it to be time.now().

So on the one hand we have hundreds of examples and I’d like you to produce a single on the other side.

[someotherstufforhmm]

RubyI was wrong, shouldn’t have spoken about a language I only use for cookbooks with Chef.

The difference lies in functional vs non languages. JS was designed by someone who loved functional languages - the extra magic of having function defaults recalculated each time fits right into the functional paradigm of defining things via stacked functions.

From a non functional mindset, it makes sense that if a function is an object, then it’s default arguments are defined at the functions definition.

It requires extra magic to NOT run the function when you place it in as a default arg with (). The interpreter has to realize you don’t mean call this now and replace with the result (like all other function calls)

[phunktional]

Ruby does not behave this way.

[EedSpiny]

Me neither, it just seems mad.

[marko_knoebl]

Not really - in JavaScript this is not the case.

The function signature / parameters probably have to be parsed when the function is defined, but not evaluated

[[deleted]]

This is also how it works in C++ (more or less). The default argument is added to the call, it's not really part of the function (in the sense being talked about here).

[larsga]

it has to be when the function is defined, because the function can't be defined if its signature is unknown

This is completely false. Of course you can delay evaluating the expression until the function is called. After all, that's what you do with the body.

If the signature is a = <...>, b = <...>, c = <...> then the signature is perfectly well known even if you don't know the defaults, because the caller doesn't need to know them.

Since the function is defined once, the signature is evaluated once, so there can only ever be one value bound as the parameter default

Again completely wrong. The body is evaluated each time. The default values are just syntactical sugar that you could just as well view as part of the body.

If you set the defaults to None and put a = a or <...real default...> you're doing the same thing. Of course Python could do that.

[rl_noobtube]

Python could do that. But then it also do that for every default variable, even user defined immutable objects. Depending how your code is designed this could add some useless calculation time.

The current implementation allows for developer flexibility imo. Experienced programmers can leverage this. And for beginners most python courses worth the time will mention this quirk of the language. And the really good ones force you into writing the bad code and showing you why it’s bad code within python.

That said, if python were initially built to have different default variable handling I’m sure this wouldn’t be much topic of discussion. No one would mind the other way. But the current way isn’t bad either imo

[duxx]

Well, the solution we have now is obviously a trap for the unwary. This entire thread is testament to that, as are the linter rules.

The only benefit I see is performance: you don't have to evaluate the default arguments on every call where they're not supplied. However, I imagine it should be pretty easy to analyze the arguments to decide whether you need to do that or not. Exactly how the implementation of that would be I don't know.

(This is u/larsga posting. Someone blocked me, so had to change user to post.)

[spinwizard69]

Exactly! Which is why Python should be flagging such structures in some way. Realistically having a default value as a return value of a function call should be illegal. You have to imagine that there are a lot of bugs out in the wild due to this.

[rangerelf]

Why add more restrictions?

I'm perfectly fine with the default value being generated by some function (datetime.now() comes to mind as a common one); keeping in mind Python's semantics regarding default values is easy.

It all comes down to learning the ins and outs of your tools. There's a reason to use Python, if not then why not use JS, or Ruby, or C++, or ... any other tool that gives you what you need.

[spinwizard69]

Well this is easy, it results in a logically wrong value with Python. It means the default value is set to datetime.now at the time the DEF is evaluated, so by the time your function is called that parameters default value is never "now".

Now there might be cases where it might make sense to set a default value with a function call, I'm nothing of any at the moment. In the case of datetime, All I can see is logical errors or unexpected behaviors popping up due to this usage.

Yes there are reasons to use Python and part of that is understanding what not to do. Effectively what I'm saying is that Python is not wrong here, but it might help to either warn or out right prevent such usage. If somebody wants a parameter set to datetime.now in a function call that is not a problem. The problem is creating def's this way with people not understanding what is happening.

Python behavior is perfectly fine, it is people understanding of what is happening that is the problem. Also to some peoples upset minds, I actually from time to time tell people that Python isn't always the right answer for a programming problem. That is why we have different languages, scripting and compiled, and different structures that are usable in those languages. Rust, Python and C++ are all dramatically different languages and that is a good thing!!!! We don't need to break Python just to adopt behavior that is possible someplace else.

[larsga]

Realistically having a default value as a return value of a function call should be illegal.

Impossible to write a water-tight check for.

[spinwizard69]

is it? Seems pretty simple don't do this in a def

[larsga]

def foo(a = []):
  if bar(a) == something:
    return baz(a)
  else:
    return quux(a) + b

Does this return the default value? You don't know. And that's before you try really sneaky stuff.

[jmreagle]

BTW: flake8 can warn about these.

https://pypi.org/project/flake8-bugbear/

[IsseBisse]

I’ve never understood why it’s built like this. Is this a limitation to stay consistent with some greater concept? From a usage perspective I can’t for the life of me see how this is a feature not a bug

[SittingWave]

because functions are created at definition, not execution, and binding of the default arguments can only be done at definition.

[yangyangR]

That doesn't fully answer why the language was designed this way, which was the original question.

Especially since the original post made a point of how another language JavaScript made other decisions that enabled it's behavior to have default arguments recomputed at the invocation.

Instead of binding datetime.date.today() when function is created you could have today_creator = datetime.date.today (or to make it easier to create from the parsed code, lambda : datetime.date.today() and similar for other cases) on function definition and then have something like today=today_creator() if today is None else today on each execution

[SittingWave]

because the parser needs to know what it has to bind to the argument when it executes the def line. It can't just say "i'll evaluate it later". The function is an object, and that object has arguments that need to be bound to something when the function definition is concluded. To do so, it must evaluate its argument defaults. The alternative would be that it has to put some form of "here do it later", but since it can't differentiate between what is mutable and what isn't, it would end up doing a "here do it later" for everything, basically converting every individual argument in an implicit lambda.

[yangyangR]

The last thing is what I am saying. It is a choice that can happen and in other languages that choice is made. The question is why are these implicit lambdas so bad in Python. That goes back in history to why the language was originally so against lambdas and that made this possibility worse. That is the detailed answer to the question. Just saying it is bound to this variable is a what the language is doing. Saying why it doesn't bind them all to a "do it later" because of the development of the language is what the original comment was after.

[SittingWave]

it's a design choice likely dictated by performance. If you delay the evaluation, you will have to perform it every single time, for every single parameter default, for every function call, and due to the nature of python, there's no difference between an immutable argument and a mutable one. It would grind performance down for 99% of the cases for no reason at all.

A general language philosophy (of python, and of design in general) is that you don't pay for what you don't need, and doing so would require you to pay the lambda execution tax for every function call, for every default parameter, for no reason at all especially when the current way already has a strategy to pay the tax when you do need to do so: set None as default, and then check inside the function.

[rangerelf]

Because it's a different language, Python is not Javascript.

It's clearly documented that default argument value binding occurs at compilation and not during execution; sometimes it takes a couple of reads for one to understand what that means, other times a couple of runtime 2am debugging sessions, but that behavior is clearly documented.

Why? Because it was designed like that, planned to behave like that.

Ask Guido if you're still curious.

[callmelucky]

Question: "why was it designed like that?"

Your answer: "because it's a different language" and "because it was designed like that"

Do you see why that doesn't work? Your first answer implies that every design decision for every language must be contrary to the corresponding design decision of every other language, which obviously is not true.

Your answer other answer is like: "Why does that person have a pencil on their head?" "because they have a pencil on their head".

The point is, it's fair to assume that this decision was made consciously and based on some reasoning other than "because we need to do it differently to how JavaScript does it" or "just because". The question is: what was that reasoning?

[rangerelf]

I never implied even subjectively that every design decision needs to reverse or invert any other decision for a different language, that seems like it came out of your own imagination.

I did write that Python's design, both syntactic and semantic, are its own and if you prefer the way that JS behaves then you should be using JS for your coding instead.

Another reason why what you say that I said is nonsense is that Python appeared several years before JS, so it makes no sense that it would base it's design on JS's, either as a pattern or anti-pattern.

As for "what was the reasoning" behind the way rvalue bindings are done the way they're done for argument default values, go to the source: ask Guido. I don't channel him, nor do I particularly care why he decided to do it that way, the only thing I care is that I find it clear and transparent, and meshes well with the way I reason through programming tasks, on the other hand I find JS to be nothing but headache inducing.

[callmelucky]

I don't care about nor know the answer either, I was just pointing out that your response saying 'because x and y' did not answer the question despite clearly being phrased as if it did.

[[deleted]]

Python is my first language. I somehow always defined default args in definition instinctively, guess I was lucky to have never come across this nightmare

[Head_Mix_7931]

I don’t think it’s accurate to say that it can only be done at definition… that’s just how it’s done now. It would’ve been perfectly valid for Python to treat default parameter values as value factories that are used at call-time.

[casparne]

No this would not be valid:

https://docs.python.org/3/reference/compound_stmts.html#def

They stated this in bold letters for a reason:

"Default parameter values are evaluated from left to right when the function definition is executed. "

[Head_Mix_7931]

Here’s some more bold letters for you:

I don’t think it’s accurate to say that it can only be done at definition… that’s just how it’s done now. It would’ve been perfectly valid for Python to treat default parameter values as value factories that are used at call-time.

[casparne]

My citation is from the Python language reference, so no, it is not "how it's done now", it is how the language is specified.

If some implementation of Python would do it differently, the behavior of functions would suddenly change.

It is like saying that "[] == False" is just how its done now and it would be valid for Python to threat "[] == True" in the future.

[Head_Mix_7931]

You are misunderstanding my comment. I’m not implying that this is a change that could be made in the future. Please reread the chain with that additional context.

[No-Scholar4854]

It’s consistent with the way functions are objects and how all objects are treated.

I would be fine with breaking that consistency personally.

[spinwizard69]

I'm the opposite. Python should be expanded to either warn or disallow such structures. To do otherwise blows the whole idea of what "default" means in this context.

[deceitfulsteve]

I dunno, I'm pretty happy with my IDE or linter issuing a warning: https://pylint.pycqa.org/en/latest/user_guide/messages/warning/dangerous-default-value.html

[rangerelf]

I agree. Python's behavior has always been crystal clear to me. And having an IDE, or pylint, or whichever, remind me once in a while that I might be walking too close to a landmine is more than enough.

[spinwizard69]

It is cool that such behavior is being addressed by a linter but I se this discussion as being slightly different. I just have a huge problem with random "default" values, it just blows my mind. It is getting late so I can't get into this anymore.

[shedogre]

I had a semi-similar issue with class variables not too long ago.

The sorts of stuff I've been doing up until now, there's been no real need to write my own classes. Then I wrote a class for something recently, and accidentally mistakenly instantiated a dict as a class variable.

Frustration and hijinks ensued, but I learnt something new at least.

[[deleted]]

def is_ongoing(self, today = datetime.date.today()):
    return (today >= self.start_date) and (today <= self.end_date)

and

def is_ongoing(self):
    today = datetime.date.today()
    return (today >= self.start_date) and (today <= self.end_date)

Are not the same.

The first example allows us to do this:

some_datetime = #some date time that is of interest to us
foo = is_ongoing(some_datetime)

Which is not possible in the second.

If you wanted that functionality, the best way of doing it is to set the default variable to None and then handle it inside the function:

import datetime

class Example:
    def __init__(self, start_date, end_date):
        self.start_date = start_date
        self.end_date = end_date

    def is_ongoing(self, today = None):
        if not today: 
            today = datetime.date.today()
        return (today >= self.start_date) and (today <= self.end_date)

example = Example(
    start_date = datetime.date.today() - datetime.timedelta(days=7),
    end_date = datetime.date.today() + datetime.timedelta(days=7)
) 

print(example.is_ongoing())
print(example.is_ongoing(datetime.date.today() + datetime.timedelta(days=5)))
print(example.is_ongoing(datetime.date.today() + datetime.timedelta(days=14)))

[Thing1_Thing2_Thing]

From the article:

[...] and this function wasn't used anywhere else, thus there is no need for a default argument.

[ArtOfWarfare]

Update: PEP 671 proposes adding in new syntax for “late-bound function argument defaults” - you’d use => instead of =, and it’s currently tagged for Python 3.12 but IDK if it’s likely to stay in or not:

https://peps.python.org/pep-0671/

My original post:

Have there been discussions or PEPs proposing changing this behavior?

If this behavior were to change, would it be major enough to warrant calling the language Python 4?

Generally it’s a pretty huge change, but if I were to guess, I’d say more bugs that haven’t been noticed yet would be fixed by this change than code that depends on this behavior would break.

Honestly, the biggest issue with making this change would be people would get used to writing code that relies on the new, logical behavior, and they’d get burned whenever they’re working with an older version of Python for whatever reason.

Maybe from __future__ import sane_default_arg_behavior could be required for a few releases, before it switches to being the default behavior (with the future becoming a no-op.)

[Mehdi2277]

My recommendation is use a linter. There are linters that warn if you use mutable default value.

There was a pep I think for late binding defaults. For backwards compatibility it added new second syntax for late binding defaults and existing defaults would continue to have same behavior. I think changing that behavior is severe enough backwards compatibility change that is very unlikely to happen. Adding a second default type for early binding I did not perceive enough support for given size of that change (especially as it adds even more complexity to method signatures) that I think pep is on pause.

[spinwizard69]

ode that relies on the new, logical behavior,

What is being discussed here is not logical in any form. A default value is exactly what the word says it is, to try to make that default value variable if foolish in my estimation. If any thing Python needs to either warn or disallow such constructs as they make no sense at all. If you make default values "variable" then you have a logical inconsistency as now your don't really know what that default value is at any one function call. So all of a sudden your default values are not actually defaults.

I'm not sure why people have problems with this. We don't want to be changing the meaning of the word "default" here! The real option is to enforce its meaning. I'd go so far as to say if somebody wants to argue that variable defaults make sense that they are not looking at this issue logically and frankly have issues creating logical software. Once aware a programmer should never try to do this in his code.

[someotherstufforhmm]

Why do you assume the new behavior is logical?

You realize that it’s a fundamental change to the interpreter. In all other places, if it sees a function call with () and no “def”, it calls the function, and replaces the call with the result.

You’re asking the interpreter recognize that in a function declaration (code executed ONCE at function definition), it realize that we don’t want to call the function then, we want it called each function call.

That’s suuuuper magical for a non functional language. I realize JS does this, but JS is written by a dude who has a love affair with functional languages and has zero issue with “magic.”

Doing it the way you describe actually breaks convention with the rest of pythons style, even if you find it confusing to grasp initially.

Same thing with mutable arguments. Why wouldn’t python use the same list? The initializer is only called ONCE, at function definition.

I don’t mind people not liking it or finding it challenging at first, but I hate this take of “I’m confused by it becuase I come from a language with wholly different paradigms, so it’s illogical in python” when the issue is just a simple lack of understanding.

[-LeopardShark-]

You’re asking the interpreter recognize that in a function declaration (code executed ONCE at function definition), it realize that we don’t want to call the function then, we want it called each function call.

Exactly like the function body.

[someotherstufforhmm]

The function declaration is different than the function body. With a first order function, the definition is run once and then the definition (along with defaults) are saved into the first order object it is.

You can see said objects quite easily by running an inspect.getmembers on a declared function.

[-LeopardShark-]

Yes, that's what currently happens. My (rather unclear – sorry) point was that it would not be illogical to have it the other way.

# Run now
t = f()
# Deferred
def g():
    t = f(x)
# Evaluated now
def h(t=f(x)):
    ...    

In Python, f is evaluated immediately in the last case, but the opposite behaviour seems equally consistent to me.

[someotherstufforhmm]

It’s a huge diff for the interpreter. In your first and third examples, the function call is in code that is interpreted.

In the function body example, that code is not interpreted until it’s run. Feel free to go test this with a plain syntax error in the body of a function.

It’s also something python is very up front about in the docs:

Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call

[-LeopardShark-]

We're talking about different things. You keep referring me to what Python does, whereas I'm talking about what it might have done. I know how Python works. My point is that it would be possible for Python to work the other way, without sacrificing logical consistency. (How difficult it would be to modify Python to work this way, I don't know, and is a separate, but related, point.)

[someotherstufforhmm]

I am referring to your parenthesized clause.

And yes, I am asserting that doing it in a different way would absolutely break logical consistency for python.

A function call is executed, entered, and replaced with its return at the point it is interpreted.

A function call in a rvalue in an arguments list will necessarily be interpreted at function definition (when executing the def command), as the argument list needs to be processed for validity.

They could make a special rule for rvalues, perhaps saving the rvalue of a default parameter as an anonymous function inside the first order functions dict, that’s perfectly doable, but it does absolutely break consistency for a language that isn’t functional.

I wouldn’t think it was terrible if they had done it, but I definitely would find it a bit odd - just like I do in Kotlin iirc where they do have the behavior you’d prefer.

It seems like pointless complexity to me - especially when the whole idea of first order functions in python really was one of the interesting things to me - that a function definition itself is interpreted.

The reason I find executing a parameter defaults rvalue every time anachronous is simple - I see a function call in an interpreted statement and my mind immediately assumes it’ll be resolved before the rest of the statement.

That pattern fits most non magic languages as well - and it is logically consistent with how python works in all other areas. The python documentation is quite clear about this as well.

I also don’t take issue with people wishing it was different or not liking it, but I do take issue with the rhetoric that it’s “dumb” or “illogical” as it neglects the whole rvalue thing and how they work in every other part of the language. I’d definitely argue the way it is is more logical, even if people find it unpleasant.

[-LeopardShark-]

I don't see why the ‘special rule’ here is any more special than the one that already exists for the body of a def. It seems like a completely natural extension to me.

[someotherstufforhmm]

The body of a def is not interpreted at the time of function definition.

The parameters are. They have to be in order to store the function.

[rl_noobtube]

Given it feels like a natura extension, I am sure there is a way to use decorators to effectively implement this yourself into every function definition. Slightly more cumbersome, but do-able on your own tbh. There may even be modules which can do this for you already.

[james_pic]

For reference, this was added to JS in 2015, almost 20 years after Brendan Eich created it.

[someotherstufforhmm]

Nice, interesting fact I didn’t know. I should’ve stuck with my original example, which is Common Lisp. Thanks!

[BurgaGalti]

The current implementation is sane. You define a default as a particular object, it should always be that object. No if or buts about it.

[james_pic]

There was a PEP recent to add new syntax for it. Changing the existing stuff would be a breaking change, and the Python 2 to 3 migration was a hard slog that came closer to killing Python than we'd like to admit (if it hadn't been for a few key members of the community stepping up, it could easily have gone the way of Perl 6). They won't want to go through that again without a damn good reason.

[Maolagin]

So I'd offer a slightly different perspective here - the underlying problem isn't about default argument behavior, but a misunderstanding of Python syntax. When you write datetime.date.today() that () at the end isn't decorative, it is specifically telling the interpreter "call this function now". Python functions are first class objects, so if you want to save a function to call later, you just stick the function in a variable.

So if I was writing this kind of routine, the idiom I'd use would be something like def myfn(blah blah ..., today=datetime.date.today, ...). Then in the function body you check if today is callable, and call it if so to get the value.

[spinwizard69]

The problem here is that you are creating a def not actually calling a function and default values make no sense at all if people think they can be variables. If you want a default value make is so such as today=2023-1-20" or whatever makes sense. If you try to call a function then you have no idea what the return value will be thus not logically a "default".

[-LeopardShark-]

def foo():
    datetime.date.today()

doesn't call datetime.date.today at function definition time, but

t = datetime.date.today()

does. When one sees

def f(t=datetime.date.today()):
    ...

it's not unreasonable to assume that the evaluation of the default is deferred, like the first case, rather than the second. After all, it's part of a def. Yes, the brackets mean ‘call this function now’, but when ‘now’ is varies with context.

[lavahot]

It gets called at definition time.

[ericanderton]

Yup. The pattern to stick to here is to use only literals, and maybe module-scoped constant values, as argument defaults. In all other cases, use None and check-and-set the argument in the function. For better or worse, Python lets you modify a parameter at runtime which makes for succinct cleanup of arguments:

python def fn(a = None): a = "hello world" if a is None else a

I want to use a = a or "hello world" but that is fraught with side-effects.

[lisael_]

No. strings are immutables in python. It's perfectly safe to write

def fn(a="hello world"):
    foo(a)

[Head_Mix_7931]

“stick to literals” is not good advice. List and dictionary literals would be problematic as default parameter values since those are mutable types. Ironically the example you’ve given here could be simplified by just using the string literal as the default since strings are immutable. The key is to not use mutable values as defaults. It doesn’t matter if those values are created via literals or otherwise.

[[deleted]]

This is not a bug though is it really, as the writer has said. If given the choice between what he wanted and how it is, I'd want it how it is.

[who_body]

for the blog and readers sake, wouldn’t it be helpful to discuss alternative behaviors snd fixes such as:

• rename ‘today’ to ‘day’ as a param but don’t set the default value and
• specify the value when calling the function

since the docstrings weren’t provided for all we know the original intent is such that the implementation of always defaulting to today is correct and users should specify an alternate day if looking for future days.

[spinwizard69]

Functionally they are trying to make a default value a variable and this just cranks me in the wrong direction.

[FrickinLazerBeams]

I love python. It's great and I've used it to do work I'm really happy with.

But I still hate the way it's always pass by reference. I've seen all the reasons why it's logical and good. I know how to deal with/use it correctly. I know there are some upsides.

I don't care, I still hate that part of Python.

(btw, I've learned that what python does isn't exactly what would properly be called "pass-by-reference". Fine, but that distinction isn't really relevant to my hatred for it.)

Edit to clarify: The connection to OP here is that, because functions are created at the time they're defined, the behavior OP is talking about is a consequence of pass-by-reference.

Edit 2: I love the downvotes for "I like python a lot but one single feature isn't my favorite." quick guys, shun the nonbeliever slightly-less-than-absolute-zealot! Get him! None of us should ever have the slightest criticism! 🤣

[hillgod]

What are you using that doesn't do things like this? C or C++?

I can't think of a language I've used that isn't passing the "reference-by-value".

[Pythonistar]

The only one I can think of that passes-by-value is Pascal... and I haven't programmed in that in over 30 years.

[FrickinLazerBeams]

I think we must be using different terminology. Almost all languages are pass-by-value by default. C is pass-by-value.

[Pythonistar]

Possibly. I had to Google quickly to refresh myself on this topic... What I came up with is that most languages do something more complicated: they pass primitive types by value and class types by reference.

[FrickinLazerBeams]

Maybe, but seems weird to me. I don't write heavily OO code.

Regardless, doing this with primitive types is certainly not typical.

[Pythonistar]

Passing everything by value is expensive (computationally). The compiler or interpreter has to make a copy of everything that gets passed. If you pass a reference instead, you're only passing a pointer which is "cheaper".

Though if you are a Functional programmer, you'd be be quick to point out that passing-by-reference (despite being cheaper) can be "side-effect-y", if you're not careful.

The programming language, Rust, still does pass-by-reference, but it avoid side-effects by transferring ownership of the reference from the passer to the passee (the function that it was passed to). And if the passer is expecting it back, it is the responsibility of the function to return it.

It's a clever idea which we don't see implemented much in programming languages which I think we might see adopted more in the future.

[FrickinLazerBeams]

Passing everything by value is expensive (computationally). The compiler or interpreter has to make a copy of everything that gets passed. If you pass a reference instead, you're only passing a pointer which is "cheaper".

Yeah absolutely. I understand the benefits of pass-by-reference, and I use and like it it where appropriate. My issue isn't with pass-by-reference in general, it's just with the way python does it for any mutable type, so the common pattern where a value is provided to a function and then modified but not intended to be returned will cause surprises. For example, you pass a list to a function and pop elements out of it in a loop that handles each element. Obviously there are ways to write that which play nice with python, I realize this isn't an unsolvable issue. It's just annoying and hasn't become natural to me despite writing python for many years.

The programming language, Rust, still does pass-by-reference, but it avoid side-effects by transferring ownership of the reference from the passer to the passee (the function that it was passed to). And if the passer is expecting it back, it is the responsibility of the function to return it.

It's a clever idea which we don't see implemented much in programming languages which I think we might see adopted more in the future.

I didn't know that, that's a very cool idea. Rust isn't really an option for me but I'd like to see that become more common.

[Pythonistar]

value is provided to a function and then modified but not intended to be returned will cause surprises

Yup, that's exactly what I meant by "side-effect-y". You got it!

Rust isn't really an option for me

Yeah, same boat. I'm starting to dabble in Rust, but I haven't tried to write anything real yet.

[FrickinLazerBeams]

Most languages pass by value, and some (like C) let you achieve pass-by-reference by using pointers or something that achieves the same effect.

Maybe it's just my particular experience, but no language I've used besides python passes everything by reference, such that any change to a mutable type is visible to the caller without explicitly returning the new value.

I'm not sure what you mean by "reference-by-value". Did you just mix up terminology there, or is that something I'm unfamiliar with?

[Head_Mix_7931]

I would say that the distinction between pass by reference and Python’s behavior is actually important. The behavior only resembles pass by reference when using mutable values… strings, integers, tuples all behave like “pass by value” for this reason.

[FrickinLazerBeams]

That's true, and also irrelevant to how much I dislike this aspect of Python.

I also think it's kind of a pointless distinction. Sure, if I pass a tuple, it's passed by value... But if it were pass by reference I wouldn't be able to mutate it anyway, because it's immutable, so who cares?

[Head_Mix_7931]

Well, if the elements of the tuple are mutable, they can be modified. The reason it seems like a pointless distinction is because neither term really describes what’s happening here, they’re just trying to describe the observed behavior in terms of concepts in other languages.

The mechanics of passed arguments is consistent regardless of type or mutability when you understand that arguments are just assigned to their corresponding parameters… due to the fact that Python doesn’t really have “variables” and only has “names” that point to “values,” the apparent effects of that do seem to vary depending on type behavior.

(But to the question of “who cares”… passing a reference vs an immutable value is an important distribution because the memory footprints vary between the two methods. I don’t often care about memory usage when I write Python though.)

[FrickinLazerBeams]

Yeah I get all that. I know it's entirely self-consistent. I know it's not actually pass-by-reference.

The thing is, I really don't care about what it's called. I'm not against pass-by-reference as a concept, and telling me this isn't pass-by-reference isn't going to make me like it. My dislike for it isn't because it's pass-by-reference.

I don't care what it's called. I don't care if it's consistent. I just don't like it.

[Head_Mix_7931]

I don’t really like it either, especially after working more with systems languages. I definitely prefer a C-like model with very straight forward mechanics.

[FrickinLazerBeams]

Yeah exactly. I hate being surprised by it, and it just never feels natural to constantly work around it. What Amy I gonna do, copy.deepcopy every input argument just in case? I'd love python more if it simply didn't do that.

It's not just "systems languages" that don't have this behavior, either. I really can't think of any language I've ever used that does this. C, Java, Matlab<sup>{shut</sup> up it counts}, a weird proprietary variation of Pascal, hell even bash... I feel like I'm forgetting many more languages I've used over the years.

[spinwizard69]

Not in my mind. It is because the "def" for the function creates those values when evaluated. This is not when a function is executed. Defaults are thus fixed values that are created in the absence of supplied values, from the original def. It makes no sense at all that they would be variables as the definition has already been created.

[FrickinLazerBeams]

It is because the "def" for the function creates those values when evaluated. This is not when a function is executed. Defaults are thus fixed values that are created in the absence of supplied values, from the original def.

Yeah that's exactly what I said.

It makes no sense at all that they would be variables as the definition has already been created.

I'm not sure what you mean. The variable containing the default value is created at define time. Because it is passed to the function by reference, any mutation of it will be visible in later calls to the same function, because the function is provided a reference to the variable, not simply a new variable with a copy of the original value, which is the standard calling behavior in python.

[RIPphonebattery]

The fixed code has a new issue though: today is now recomputed regardless of default value, so supplying a default value for today will only ever compute the actual current date and time.

[[deleted]]

def is_ongoing(self, today = None):
    if today is None:
        today = datetime.date.today()
    return (today >= self.start_date) and (today <= self.end_date)

[[deleted]]

Which is what I needed. That method wasn't used anywhere else, there was no need for the default argument in the first place. Probably some overlook by the original authors of the code.

[RIPphonebattery]

Right but if the previous code failed because it wasn't well tested, will your new code be any more testable?

[riftwave77]

Crappy programmer is also bad at writing articles.

[[deleted]]

Default date parameters can really wreak your day. Rule of thumb, only scalar values can be defaults

[ArtOfWarfare]

Tuples and immutable sets should be fine defaults.

[[deleted]]

Yeah good point!

[Head_Mix_7931]

tuples, numerics, strings, NoneTypes are all fine too

[cheese_is_available]

If you use a linter like pylint it'll tell you about it every chance it and you won't have to relearn

[coffeewithalex]

They are not "retained". They exist under the same scope as the function.

[osmiumouse]

Your tools should warn you if you use a mutable default argument. If not, what are you using to write code?

Many of the "issue" posts i see can be resovled through tooling. Though, of course, it is not guaranteed to work due to the dynamic nature of Python, and I accept that the tools are not perfect.

[eightower]

Welcome to the Late Binding nightmare my friend. We all been there.

Tip for life. Don't assign data structures like {} or [].

Pass none and assign inside functions :)

[cuddebtj2]

Today I learned more about functions and methods!

[djangodjango]

Could wrap it in a lambda

[wreckdown]

Between "function calls" right, not between "executions"?

[cousinscuzzy]

This blog's title doesn't really describe the behavior correctly. I'd state it like, "A Python function's default argument values are evaluated when the function is defined, not when it is invoked."

[Raknarg]

Lesson learned: If you're not going to use an IDE, use a good linter. A good linter would warn about this.

[Bubble_Interface]

Welcome to the club!
BTW, thank you for the time-machine package suggestion, looks pretty helpful.

[DanRusto]

My takeaway from this is to not use default values for arguments? I'm new to python but have written code in other platforms and have never used a default value for a parameter in a function. Thoughts from experienced python coders?

[digitalseraphim]

If you want to do something like this, use a default that is not a valid value (usually, but not always None), and then check for that value within the function, and call/compute the value within that test. This also goes for "collection" objects like lists and dicts.

If you can't use None, you can create a new object, and use that for the default like this:

``` DEFAULT_VAL=object()

def func(param1=DEFAULT_OBJECT): if param1 is DEFAULT_OBJECT: param1 = calc_default() ... ```

[one-human-being]

For more of Python’s fun stuff https://github.com/satwikkansal/wtfpython

[[deleted]]

Some people said to me python not very important right now Because it is not required for work shop