syntax for code blocks

[Kiuhnm]

On 5/4/2012 4:44, alex23 wrote:
> 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.

It doesn't always produce name-clashes but it may do so.
Suppose that func takes some functions named fn1, fn2 and fn3. If you 
only define fn2 but you forget that you already defined somewhere before 
fn1, you inadvertently pass to func both fn1 and fn2.
Even worse, if you write
   def a(): pass
   def b(): pass
   func(arg, locals())
and then you want to call func again with c() alone, you must write this:
   def c(): pass
   a = b = None
   func(arg, locals())
Moreover, think what happens if you add a function whose name is equal 
to that of a function accepted by func.
That's what I call name-clashing.
My solution avoids all these problems, promote encapsulation and let you 
program in a more functional way which is more concise that the OOP way, 
sometimes.

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

Really? Then I don't know what would make sense to you.

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

It's impossible to have a constructive discussion while you and others 
feel that way. You're so biased that you don't even see how biased you are.

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

If I and my group of programmers devised a good and concise syntax and 
semantics to describe some applicative domain, then we would want to 
translate that into the language we use.
Unfortunately, Python doesn't let you do that.
I also think that uniformity is the death of creativity. What's worse, 
uniformity in language is also uniformity in thinking.
As I said in some other posts, I think that Python is a good language, 
but as soon as you need to do something a little different or just 
differently, it's a pain to work with.

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

Sigh.

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

You can do whatever you want by hand: you can certainly define your 
functions inside another function or a class, but that's just more noise 
added to the mix.

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

Your rephrasing is quite wrong. You asked for a practical example and I 
said that I already showed you one. It's just that you can't see it (as 
practical).

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

I don't care if you don't read this post. Now that I've written it I'll 
post it anyway.
Unfortunately, communication is a two-people thing. It's been clear from 
the first post that your intention wasn't to understand what I'm proposing.
There are some things, like what I say about name-clashing, that you 
should understand no matter how biased you are.
If you don't, you're just pretending or maybe you weren't listening at all.

Kiuhnm