Re: [Python-ideas] 'where' statement in Python?
On Thu, Jul 22, 2010 at 3:55 PM, Terry Reedy tjreedy@udel.edu wrote:
On 7/22/2010 4:38 AM, geremy condra wrote:
On Wed, Jul 21, 2010 at 9:21 PM, Terry Reedytjreedy@udel.edu wrote:
e = fe(a,b,c, p1) where: c = fc(a, d, p2 where: d = fd(a, p1) where: a = fa(p1, p2) b = fb(a,p2)
where p1,p2 are input parameters;
looks about as bad (and it was a real effort to write). I would rather something like that were in a branch dialect, Ypthon with its own extension (.yp).
Of course it looks bad. You can make anything look bad. 37 levels of nested 'for' statements look bad. That isn't an argument against this, it's an argument against bad code period.
I think you make an unfair comparison: 3 nested where statememts, which you agree look bad, against 37 nested for statements, which I would agree would be bad, as in unreadable. (I believe auto code generators have done such things.) The fair comparison would be 3 nested where statement, which you agree is bad, against 3 nested for statements, which is routine and not bad. So I think you made my point ;-).
Hmm. I'm pretty sure you know that I don't think 37 levels of for statements is the minimum required number for ugliness, which makes me wonder why you chose to structure an argument around that idea unless you just wanted to score a few easy points on an otherwise valid claim.
I would also argue that the more valid comparison would be nested functions or classes- both perfectly pretty constructs on their own- which would cause me to gnaw on otherwise unoffending office furniture if I encountered them nested 3 deep.
My differently wired brain would tolerate the new construct much better, and might even use it, if nested where/given constructs were not allowed.
Seems easier to work with to me, but I don't see the point in increasing the implementation difficulty just to stop bad programmers from writing bad code.
Geremy Condra
On Thu, Jul 22, 2010 at 10:21 PM, geremy condra debatem1@gmail.com wrote:
I would also argue that the more valid comparison would be nested functions or classes- both perfectly pretty constructs on their own- which would cause me to gnaw on otherwise unoffending office furniture if I encountered them nested 3 deep.
I guess you're not much fond of decorators then; it's common to define them exactly as 3-level deep nested functions:
def decofactory(deco_arg): def decorator(func): def wrapper(*args, **kwargs): if deco_arg: return func(*args, **kwargs) return wrapper return decorator
@decofactory(n) def func(x, y): ...
George
On Fri, Jul 23, 2010 at 6:49 AM, George Sakkis george.sakkis@gmail.com wrote:
On Thu, Jul 22, 2010 at 10:21 PM, geremy condra debatem1@gmail.com wrote:
I would also argue that the more valid comparison would be nested functions or classes- both perfectly pretty constructs on their own- which would cause me to gnaw on otherwise unoffending office furniture if I encountered them nested 3 deep.
I guess you're not much fond of decorators then; it's common to define them exactly as 3-level deep nested functions:
def decofactory(deco_arg): def decorator(func): def wrapper(*args, **kwargs): if deco_arg: return func(*args, **kwargs) return wrapper return decorator
@decofactory(n) def func(x, y): ...
Actually, I think that's the main reason why parameterised decorators can be such a pain to understand - keeping the 3 scopes straight in your head is genuinely difficult. There's a reason the recently added contextlib.ContextDecorator is implemented as a class with a __call__ method rather than using nested functions.
A given clause would let you reorder this code, and I think doing so is genuinely clearer:
def decofactory(deco_arg): return decorator given: def decorator(func): if not deco_arg: return func return wrapper given: @wraps(func) def wrapper(*args, **kwargs): return func(*args, **kwargs)
Reversing the order of some aspects of the execution allows the text flow to match the way you would describe the operation: we have a decorator factory that returns a decorator that returns the function unmodified if deco_arg evaluates to False and returns a wrapper around the decorated function otherwise.
Cheers, Nick.
On 7/22/2010 4:21 PM, geremy condra wrote:
Hmm. I'm pretty sure you know that I don't think 37 levels of for statements is the minimum required number for ugliness,
Of course not, but that is the only number you gave ;-) I would agree to something smaller than 10, but larger than 4.
I would also argue that the more valid comparison would be nested functions or classes- both perfectly pretty constructs on their own- which would cause me to gnaw on otherwise unoffending office furniture if I encountered them nested 3 deep.
For classes I agree. For functions I would allow 3. But in all casses, the number that is ok is usefully larger than 1.
participants (4)
-
George Sakkis -
geremy condra -
Nick Coghlan -
Terry Reedy