Metaprogramming Example

[bruno.desthuilliers at gmail.com]

On 17 avr, 14:25, andrew cooke <and... at acooke.org> wrote:
> On Apr 17, 7:12 am, "bruno.desthuilli... at gmail.com"<bruno.desthuilli... at gmail.com> wrote:
>
> [...]
>
> Thanks very much!
>
> These are useful pointers.  I'll update my code accordingly.
>
> At one point you pointed out I didn't need parentheses and I agree - I
> was using them to avoid having a line continuation backslash (I think
> I read to do that in a style guide recently).

Ok. I personnaly prefer \ continuations, but that's another
troll^M^discussion !-)

> One other question.  I had "foo is False" and you said I need
> equality, which is a good point.  However, in any other language "not
> foo" would be preferable.

And it's indeed the case in Python.

>  I was surprised you didn't suggest that

I did - even if somewhat implicitly -, as Paul brillantly explained.

> (and I'm unsure now why I didn't write it that way myself).  Is there
> some common Python standard that prefers "foo == False" to "not foo"?

Definitively not.

FWIW, True and False are later additions to Python, which has a much
more generic concept of what's true or false (notice the lowercase) in
the context of a boolean expression, that is:
- False, None, numeric zero are false
- an object that has a __nonzero__ method has the truth value of the
result of calling this method
- a "sizeable" object (one which defines a __len__ method) is true if
len(obj) > 0, else it's false (which implies that empty dicts, lists,
tuples and strings are false)
- anything else is true

(please someone correct me if I forgot something here).


>
> PS Is there anywhere that explains why Decorators (in the context of
> functions/methods) are so good?  I've read lots of things saying they
> are good, but no real justification of why.  To me it looks more like
> "re-arranging deck chairs on the Titanic" - you're just moving where
> the hack happens from one place to another.  Is the point that now the
> hack is more visible and hence modifiable?

I wouldn't call function decorators "a hack" - it's just a pretty
common use of HOFs. Now wrt/ the @decorator syntax: yes, you're plain
right, the GoodThing(tm) is that it makes the use of the HOF clearly
visible at the top of the function definition so you just can't miss
it.