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
--
http://mail.python.org/mailman/listinfo/python-list
