On May 2, 8:52 pm, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>> func(some_args, locals())
>
> I think that's very bad. It wouldn't be safe either. What about name
> clashing
locals() is a dict. It's not injecting anything into func's scope
other than a dict so there's not going to be any name clashes. If you
don't want any of its content in your function's scope, just don't use
that content.
> and how would you pass only some selected functions?
You wouldn't. You would just refer to the required functions in the
dict _in the same way you would in both your "bad python" and code
block versions.
> > But as you're _passing them in by name_ why not just make it
> > func(some_args) and pick them up out of the scope.
>
> Because that's not clean and maintainable. It's not different from using
> global variables.
...I'm beginning to suspect we're not engaging in the same
conversation.
This is very common in Python:
from module1 import func1
def func2(args): pass
def main():
# do something with func1 and func2
And I've never had problems maintaining code like this. I know
_exactly_ the scope that the functions exist within because I added
them to it. They're not _global_ because they're restricted to that
specific scope.
> > _No one_ writes Python code like this. Presenting bad code as
> > "pythonic" is a bit of a straw man.
>
> How can I present good code where there's no good way of doing that
> without my module or something equivalent?
> That was my point.
You haven't presented *any* good code or use cases.
> > This is unintuitive, to say the least. You're effectively replacing
> > the common form of function definition with "with when_odd as 'n'",
> > then using the surrounding context manager to limit the scope.
>
> What's so unintuitive about it? It's just "different".
Because under no circumstance does "with function_name as
string_signature" _read_ in an understandable way. It's tortuous
grammar that makes no sense as a context manager. You're asking people
to be constantly aware that there are two completely separate meanings
to 'with x as y'.
> > More importantly, _you're naming your "anonymous" code blocks_, I'm
> > guessing so that func() can choose which ones to use. But if you're
> > naming them, why not just use a function?
>
> I'm creating a dictionary, not naming my blocks just for the sake of it.
> If you use a function, you end up with the solution that you called
> 'bad' and non-pythonic.
What I considered 'bad' was having a _single_ function that takes
_multiple differing collections_ of named functions. Now you've moved
the onus onto the caller to ensure that the function is provided what
it needs in a specific context to do its thing. Rather than overload
one single function and push the complexity out to the caller, why not
have multiple functions with obvious names about what they do that
only take the data they need to act on?
Then again, it's _really difficult_ to tell if something named
'func()' could have a real use like this.
> The problem is always the same. Those functions are defined at the
> module level so name clashing and many other problems are possible.
So define & use a different scope! Thankfully module level isn't the
only one to play with.
> I remember a post on this ng when one would create a list of commands
> and then use that list as a switch table. My module let you do that very
> easily. The syntax is:
>
> with func() << ':list':
> with 'arg':
> cmd_code
> with 'arg':
> cmd_code
> with '':
> cmd_code
I'm sorry but it is still clear-as-mud what you're trying to show
here. Can you show _one_ practical, real-world, non-toy example that
solves a real problem in a way that Python cannot?
--
http://mail.python.org/mailman/listinfo/python-list
