syntax for code blocks

[Kiuhnm]

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