You are right — the return thing is very silly. What about this:

  def greet(…, bow=False):
    …
    if bow:
      take_a_bow()

Except imagine take_a_bow() instead as 10 lines of code to perform the post-greeting bow-ceremony. That code takes additional arguments regarding what kind of hand flourish to perform while bowing. The flourish_type has to be an optional argument to greet (because bow is) but inside the bow you have to assert flourish_type is not None because you can’t bow without knowing what flourish to give.

I’ve seen some dark stuff over the years.

Also: Welcome to HN!

  def greet(bow=None):
    ...
    if bow:
      bow()

  def elsewhere(gesture):
    def bow():
      print(gesture)
    greet(bow)

Wrap that.

OMG please leave your dependency injection in your Java project and keep Python clean with its easy to use list of default parameters.

You can use dependency injection in Python while remaining completely pythonic - nothing in the Python I write resembles Java. Dependency injection is not mutually exclusive with using defaults either, so I'm not sure what we're talking about here.

DI is not a pattern to provide the defaults but a pattern that allows you to separate dependency initialisation from your callable's responsibilities, which often is a complex graph of inner dependencies that you would need to provide/initialise in some way, it also can handle whether you want to have single instance of such dependency for your single call, request scope, thread scope or process scope. Also injecting some defaults from configuration object or some properties/setting file is very nice feature.

Also stop being so religious and defensive when somebody mentions things that are not standard in your language of choice as nobody forces you to use this.

I was sucessfully building very testable and maintanable codebases (~50 kloc) in Python while also using very small in-house built DI framework and it was subjectively (by me and my collegues) much better than what we had before while we followed standard Python patterns and ways Python frameworks teach you to follow.

What's the point of a DI framework? I never got the point of even thinking about DI explicitly like it's something special. It's so obvious that it hardly deserves to have a name, let alone a framework.

> (by me and my collegues)

Can I guess you were all Java developers?

No, around 6-7 Python developers including me, we've used it in two different projects. Also it's probably worth mentioning that I'm not author of that lib, my die-hard anti Java collegue created it by just reading about DI, consulting with other collegue that was using Spring more-or-less since high school and researching existing DI libraries. I myself did some programming in Java before that, but it was mainly hobbist gamedev, later commercial Android and light Java backend work using Spring (that's where I've seen it used for first time) intermixed with around 7 years of professional Python backend programming in two different companies. Now after 10 years I'm an Java engineer, I've had enough of using dynamic languages to write moderately complex web applications.

I still love using Python for REPL, small scripts or prototyping, and I think having things like mypy is great as it takes away much of the burden without being a huge obstacle in some situations where you really need to use duck typing. Also I'm thankful that it teached me early that the debugger is one of the developer's best friends and the best documentation is just reading the code.

Thanks yeah I'm just bitter and in a bad mood today. :)

For me, DI is where this happens at the public interface to things. I’m quite happy with subprocess.Popen’s keyword argument salad because they are relatively ergonomic and make good sense.

When that kind of “handy defaults for ya!” programming happens to a function inside a package… that has four call sites… all of which were added by the same team of three people… just refactor your stuff, get functional, and say explicitly what you actually need.