On 5/3/2012 2:20, alex23 wrote:
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.
The clashing is *inside* the dictionary itself. It contains *all* local
functions and variables.
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.
See above.
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.
That's not the same thing. If a function accepts some optional
callbacks, and you call that function more than once, you will have
problems. You'll need to redefine some callbacks and remove others.
That's total lack of encapsulation.
_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.
Says who? You and some others? Not enough.
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'.
The meaning is clear from the context. I would've come up with something
even better if only Python wasn't so rigid.
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?
Because that would reveal part of the implementation.
Suppose you have a complex visitor. The OOP way is to subclass, while
the FP way is to accept callbacks. Why the FP way? Because it's more
concise.
In any case, you don't want to reveal how the visitor walks the data
structure or, better, the user doesn't need to know about it.
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.
We can do OOP even in ASM, you know?
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?
I just did. It's just that you can't see it.
Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list
