> it was using decorators to mutate some global state
It isn't. The original version was doing that, but the "decorator" one wasn't. The data variable is internal to the closure, so different invocations of the decorator would have different data variables.
> didn’t find the closure stuff that insightful
It's used to attach state to a function. Different invocations of the function would have different state. IME, I'd rather use an explicit class for that, but it's useful with decorators.
This is about Python decorators: https://docs.python.org/3/glossary.html#term-decorator. In summary, they are functions that return functions, which allow you to wrap their behaviour (e.g. add a cache, transform a function into an HTTP API handler, etc.)
As far as I can tell, they're not related to the design pattern, but I never had to use that.
Yes, please. Given I'm forced to use Python, I'd welcome any "compile time" tools I can get. These days, it's using pyright with strict mode, which is pretty good, but there's still a long way to go.
> Does modern, production-level python code use types everywhere?
I don't know about code inside companies, but most new open source projects I encounter use typing. Many old ones have been converted too.
> Is duck typing frowned upon?
No. You can use Protocols to define what shape you expect your duck to be. There's some discussion about whether you should use abstract classes or protocols, though.
Parent's example had a direct `iter(thing)`. Even if you had to use `iter(thing, sentinel)`, you'd still use `for val in iter(thing, sentinel)`, not while.
First of all, it takes a minute to search "python :=", and the construct itself is pretty simple. It's been part of the language since 2018[0]. I don't think "not knowing the language" is a good reason to avoid it.
Second, the walrus operator limits the variable's scope to the conditional, which can reduce certain bugs. It also makes some scenarios (like if/elif chains) clearer.
I recommend checking out the PEP for some real-world examples.
That's exactly my point. Having to search for the meaning of the operator at all makes the code less readable. I recommend reading the Zen of Python, which covers the design principles of the language.
I don’t write code to the level of someone who has just finished Hello, World. This isn’t something esoteric, it’s an extremely basic and useful part of the language. I’ve seen this argument used against multiple languages, and it has never made sense to me.
“I don’t want to use windowing functions in SQL, because most people don’t know what they are.” So you’d rather give up an incredibly powerful part of your RDBMS, and dramatically increase the amount of bandwidth consumed by your DB?
It’s as if the industry is embracing people who don’t want to read docs.
We're discussing Python, not SQL or any other language. Using more arcane elements of a language like Python, which emphasizes readability, often makes your code less understandable, difficult to debug, and harder to maintain. I also suggest you read the Zen of Python for an understanding of the language's design principles.
That is, iterators' execution flow is interspersed, with the `yield` statement explicitly giving control to another coroutine, and then continuing the current coroutine at another yield point, like the call to next(). This is very similar to JS coroutines implemented via promises, with `await` yielding control.
Even though there is only one thread of execution, the parts of the pipeline execute together in lockstep, not sequentially, so there's no need for a previous part to completely compute a large list before the following part can start iterating over it.
I just went to mainland Europe over Easter. The only payment method I ever used was my phone (Google Pay). Not just restaurants, but everything. This matched my observations of other people. I withdrew some Euros just in case, but did not use them.
It isn't. The original version was doing that, but the "decorator" one wasn't. The data variable is internal to the closure, so different invocations of the decorator would have different data variables.
> didn’t find the closure stuff that insightful
It's used to attach state to a function. Different invocations of the function would have different state. IME, I'd rather use an explicit class for that, but it's useful with decorators.
reply