syntax for code blocks

[alex23]

On May 4, 2:17 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 5/3/2012 2:20, alex23 wrote:
> > 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.

This is nonsense.

locals() produces a dict of the local scope. I'm passing it into a
function. Nothing in the local scope clashes, so the locals() dict has
no "internal clashing". Nothing is injecting it into the function's
local scope, so _there is no "internal clashing"_.

To revise, your original "pythonic" example was, effectively:

    def a(): pass
    def b(): pass

    func_packet = {'a': a, 'b': b}
    func(arg, func_packet)

My version was:

    def a(): pass
    def b(): pass

    func_packet = locals()
    func(arg, func_packet)

Now, please explain how that produces name-clashes that your version
does not.

> >> 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.

This is more nonsense. So calling 'a' in your dict is fine, but
calling a in the locals() returned dict isn't?


> 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.

Hand-wavy, no real example, doesn't make sense.

> > You haven't presented *any* good code or use cases.
>
> Says who? You and some others? Not enough.

So far, pretty much everyone who has tried to engage you on this
subject on the list. I'm sorry we're not all ZOMGRUBYBLOCKS!!!!111
like the commenters on your project page.

> The meaning is clear from the context.

Which is why pretty much every post in this thread mentioned finding
it confusing?

> I would've come up with something even better if only Python wasn't so rigid.

The inability for people to add 6 billion mini-DSLs to solve any
stupid problem _is a good thing_. It makes Python consistent and
predictable, and means I don't need to parse _the same syntax_ utterly
different ways depending on the context.

> 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.

Again, nothing concrete, just vague intimations of your way being
better.

> > 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'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.

"I don't understand this example, can you provide one." "I just did,
you didn't understand it."

Okay, done with this now.  Your tautologies and arrogance are not
clarifying your position at all, and I really don't give a damn, so
*plonk*