Decorators, Identity functions and execution...

[Chance Ginger]

If I define a decorator like:

def t(x) :
def I(x) : return x
return I

and use it like:

@t(X)
def foo(a) :
# definition of foo...
pass

or maybe this:

@t(X)
@(Y)
def bar(a) :
# The definition of bar...


Will in encounter much of a penalty in executing
'foo' or 'bar'? If so, is there a way to define
t such that Python knows it is the identity function
and short-circuit evaluation?

Thanks in advance.

 

[Fredrik Lundh]

If I define a decorator like:

def t(x) :
def I(x) : return x
return I

.... you get a syntax error.

and use it like:

@t(X)
def foo(a) :
# definition of foo...
pass

that's also a syntax error.

or maybe this:

@t(X)
@(Y)
def bar(a) :
# The definition of bar...

and that's not even fixable.

Will in encounter much of a penalty in executing
'foo' or 'bar'?

since foo is wrapped, calling foo will call your I function, which in
turn calls the original foo.

If so, is there a way to define t such that Python knows it is
the identity function and short-circuit evaluation?

if you don't want to wrap something, don't wrap it:

def t(x) :
def I(x) :
return x
if date == friday:
return x # don't wrap it
return I # wrap it

</F>

 

[Chance Ginger]

... you get a syntax error.

It isn't a syntax error...I tried it before I posted. In fact
def t(x) :
def I(x) : return x
return I

is correct.

that's also a syntax error.

Once again this isn't an error assuming you pass in a valid 'X'.

and that's not even fixable.

Again you are mistaken. If I say:

@t(1)
@t(2)
def bar(a) : pass

It is perfectly valid.

since foo is wrapped, calling foo will call your I function, which in
turn calls the original foo.


if you don't want to wrap something, don't wrap it:

def t(x) :
def I(x) :
return x
if date == friday:
return x # don't wrap it
return I # wrap it

</F>

Decorators are a way to add "syntactic" sugar to Python,
extending it in ways that make it useful for tools. What
I am trying to do is lessen the impact on the time used
in executing Python code when I use some forms of decorators.

 

[Jorge Godoy]

It isn't a syntax error...I tried it before I posted. In fact
def t(x) :
def I(x) : return x
return I

is correct.

Indeed. This is correct. Fredrick's comment was related to the lack of
indentation in your code.

Once again this isn't an error assuming you pass in a valid 'X'.

If your indentation is broken as above it doesn't matter what 'X' is.

--
Jorge Godoy <[email protected]>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.

 

[Fredrik Lundh]

It isn't a syntax error...I tried it before I posted. In fact
def t(x) :
def I(x) : return x
return I

is correct.

tabs don't make it through all channels. don't use tabs for
indentation when you post to newsgroups or mailing lists.

and @(Y) is not valid Python syntax. no amount of indentation
will change that.

Decorators are a way to add "syntactic" sugar to Python,
extending it in ways that make it useful for tools.

that's a rather narrow view of what a decorator does, and doesn't
help much in understanding how they work.

which is unfortunate, because it's very simple: decorators are simply
ordinary callables, and the result of the decoration is whatever the
callable returns.

in fact, any callable can be used to decorate a function:
... def foo(bar):
... pass
... Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable

and it's all done at runtime; there is no magic involved whatsoever.
... @str
... def bar(foo):
... pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in ?

I am trying to do is lessen the impact on the time used in
executing Python code when I use some forms of decorators.

if you don't want Python to execute some code, all you have to do is
to make sure that it isn't called.

</F>

 

[Carl Banks]

It isn't a syntax error...I tried it before I posted. In fact
def t(x) :
def I(x) : return x
return I

is correct.

You've made the unfortunate mistake of indenting it with tabs, which do
not show up on some newsreaders. I see the tabs in Google; people
using Microsoft Outlook do not.

Always use spaces when posting, and use them in your code as well.
Spaces are the current recommended practice, and in the future tabs
might become illegal. I'd prefer tabs myself, but it's more important
to respect community standards than to stick to some silly preference
you have.

Decorators are a way to add "syntactic" sugar to Python,
extending it in ways that make it useful for tools. What
I am trying to do is lessen the impact on the time used
in executing Python code when I use some forms of decorators.

One suggestion. Have you run the script, determined it's too slow, and
are trying to optimize? If not (and it doesn't sound like you are), I
suggest that it's too soon to worry about whether this decorator has
any overhead. You may end up doing a lot of work optimizing that will
ultimately have very little benefit.

Having said that, this decorator will not affect calling overhead at
all. The decorator is applied when the module is loaded, not when the
decorated function is called.


Carl Banks

 

[Chance Ginger]

First, thanks for the tip of 'tabs'. I keep forgetting
Outlook has some interesting rules about displaying text.

Thanks for the comment about happening at load time. That
resolved the problem (in my thinking)! I don't believe I
have an issue at all...

Peace,
CG.

 

[Fredrik Lundh]

Having said that, this decorator will not affect calling overhead at
all. The decorator is applied when the module is loaded, not when the
decorated function is called.

to be precise, the decorator is applied when the "def" statement is exe-
cuted (that is, when the decorated function object is created).

this may be load time, or, for nested functions, some other time.

</F>

 

[Steven D'Aprano]

it's more important
to respect community standards than to stick to some silly preference
you have.

What happens when the community standard is a silly preference? I object
to the suggestion that "community standards" (that is, a standard not even
designed by a committee, merely evolved by a mob) is necessarily worthy of
respect.

As it turns out, regarding this particular "silly preference" (community
or private), I always remember that communication is the purpose of email
(and, believe it or not, Usenet), and the use of tabs in some buggy
news readers can cause the failure of communication. Hence I use spaces
when posting code. The rest of the time, particularly in my private
coding, my preference (whatever it is) is no more or less irrational than
the other preference.

 

[Roy Smith]

What happens when the community standard is a silly preference? I object
to the suggestion that "community standards" (that is, a standard not even
designed by a committee, merely evolved by a mob) is necessarily worthy of
respect.

Design by committee has far from a stellar track record. On the Internet,
most of the really good stuff has come from the mobs.

As it turns out, regarding this particular "silly preference" (community
or private), I always remember that communication is the purpose of email
(and, believe it or not, Usenet), and the use of tabs in some buggy
news readers can cause the failure of communication. Hence I use spaces
when posting code.

As you should. It matters not whether news readers that can't handle tabs
are buggy or not. The fact is that they exist. One of the most basic
maxims on the Internet has always been, "Be liberal in what you accept, be
conservative in what you produce".

 

[Felipe Almeida Lessa]

Em Dom, 2006-04-09 às 08:52 -0700, Carl Banks escreveu:

You've made the unfortunate mistake of indenting it with tabs, which
do
not show up on some newsreaders. I see the tabs in Google; people
using Microsoft Outlook do not.

He does not need to know that some poor designed newsreaders mess up
with tabs at will. Python supports tab indentation and it's not
forbidden to use it (if it was, support for it in the Python codebase
would have been removed long time ago).

I don't like to code with tab-indents, I use 4 spaces, but I don't press
space four times each time I need to indent something, I just press Tab
and the editor does the clunky part for me. The problem is that most (if
not all) mail programs/newsreaders don't convert tabs to spaces, they
don't even keep the indentation of the last line, so nobody has the
obligation of opening its IDE or hitting dozens of times the space key
just to post a message to the list.

 

[Carl Banks]

Em Dom, 2006-04-09 às 08:52 -0700, Carl Banks escreveu:

He does not need to know that some poor designed newsreaders mess up
with tabs at will.

Yes, he does need to know if he doesn't want some people to pass over
his post.

Python supports tab indentation and it's not
forbidden to use it (if it was, support for it in the Python codebase
would have been removed long time ago).

Nope. If tab indentation were the biggest mistake in the language, it
would still be supported because of backwards compatibility. I don't
recall the status of tabs in Py3K but your reasoning is wrong.


Carl Banks

 

[Carl Banks]

What happens when the community standard is a silly preference? I object
to the suggestion that "community standards" (that is, a standard not even
designed by a committee, merely evolved by a mob) is necessarily worthy of
respect.

It is worthy of respect because it's such a stupid thing to even have a
preference for; consistency with the community is by far the strongest
argument one could make for or against tabs.


Carl Banks

 

[Christos Georgiou]

Indeed. This is correct. Fredrick's comment was related to the lack of
indentation in your code.

His code was indented fine, as you maybe noticed later on. The actual
problem was that he had tabs, so Fredrik's Outlook Express (and I guess
other newsreaders too) did not show indentation.

Fredrik suggested already the typical "use spaces, not tabs"; I just thought
that "lack of indentation" was unfair for the OP.

 

[Lawrence D'Oliveiro]

Always use spaces when posting, and use them in your code as well.
Spaces are the current recommended practice, and in the future tabs
might become illegal. I'd prefer tabs myself, but it's more important
to respect community standards than to stick to some silly preference
you have.

Tab stops every 4 columns. What's silly about that? Any other definition
is silly, or at best antiquated.

 

[Lawrence D'Oliveiro]

One of the most basic
maxims on the Internet has always been, "Be liberal in what you accept, be
conservative in what you produce".

How do you explain top-posting, then?

 

[Christos Georgiou]

How do you explain top-posting, then?

“Be lazy and let your news/mail client choose for you.â€

Unless you meant “how do you explain top-posting *acceptance* by non
top-posters.â€Â  That is another branch of psychology.

 

[Ben Sizer]

Tab stops every 4 columns. What's silly about that? Any other definition
is silly, or at best antiquated.

Every day I come across people or programs that use tab stops every 2
or 8 columns. I am another fan of tabs every 4 columns, but
unfortunately this isn't standard, so spaces in Python it is.

 

[Sybren Stuvel]

Ben Sizer enlightened us with:

Every day I come across people or programs that use tab stops every
2 or 8 columns. I am another fan of tabs every 4 columns, but
unfortunately this isn't standard, so spaces in Python it is.

I don't care about how people see my tabs. I use one tab for every
indent level, so no matter how you set your tab width, my code will
look consistent.

Sybren

 

[Terry Reedy]

> I don't care about how people see my tabs. I use one tab for every
indent level, so no matter how you set your tab width, my code will
look consistent.

Unless they view with tab_width = 0, as with some news readers.

tjr