>>>>> "MAL" == M -A Lemburg <mal@lemburg.com> writes: MAL> [pre-PEP] This will break code... I'm not sure whether it's MAL> worth going down this path just for the sake of being able to MAL> define functions within functions. How will this break code? Any code written to use the scoping rules will not work today. Python already allows programs to define functions within functions. That's not at issue. The issue is how hard it is to use nested functions, including lambdas. MAL> Wouldn't it be a better idea to somehow add native acqusition MAL> to Python's objects ? No. Seriously, I don't see how acquistion addresses the same issues at all. Feel free to explain what you mean. MAL> We already have a slot which implements the "contains" MAL> relationship. All we'd need is a way for a contained object to MAL> register itself with the container in a way that doesn't MAL> produce cycles. The contains relationship has to do with container objects and their contents. A function's environment is not a container in the same sense, so I don't see how this is related. As I noted in the PEP, I don't see a compelling reason to avoid cycles. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4