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]

Chance Ginger" wrote:

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]

On Sun, 09 Apr 2006 09:51:18 +0200, Fredrik Lundh wrote:

Chance Ginger" wrote:

If I define a decorator like:

def t(x) :
def I(x) : return x
return I
... 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.

and use it like:

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

that's also a syntax error.

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

or maybe this:

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

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.

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>

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]

Chance Ginger <cg********@hotmail.com> writes:

On Sun, 09 Apr 2006 09:51:18 +0200, Fredrik Lundh wrote:

Chance Ginger" wrote:

If I define a decorator like:

def t(x) :
def I(x) : return x
return I
... 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.

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

and use it like:

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

that's also a syntax error.

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 <go***@ieee.org>

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

[Fredrik Lundh]

Chance Ginger wrote:

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:

@str ... def foo(bar):
... pass
... foo '<function foo at 0x00986730>' foo("bar") 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.
@open

... @str
... def bar(foo):
... pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: '<function bar at 0x009867F0>'
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]

Chance Ginger wrote:

On Sun, 09 Apr 2006 09:51:18 +0200, Fredrik Lundh wrote:

Chance Ginger" wrote:

If I define a decorator like:

def t(x) :
def I(x) : return x
return I
... 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.

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.

On Sun, 09 Apr 2006 08:52:18 -0700, Carl Banks wrote:

Chance Ginger wrote:

On Sun, 09 Apr 2006 09:51:18 +0200, Fredrik Lundh wrote:

> Chance Ginger" wrote:
>
>> If I define a decorator like:
>>
>> def t(x) :
>> def I(x) : return x
>> return I
>
> ... 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.

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

[Fredrik Lundh]

Carl Banks wrote:

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]

On Sun, 09 Apr 2006 08:52:18 -0700, Carl Banks wrote:

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.

--
Steven.

[Roy Smith]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

On Sun, 09 Apr 2006 08:52:18 -0700, Carl Banks wrote:

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.

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.

--
Felipe.

[Carl Banks]

Felipe Almeida Lessa wrote:

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.

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]

Steven D'Aprano wrote:

On Sun, 09 Apr 2006 08:52:18 -0700, Carl Banks wrote:

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.

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]

On Sun, 09 Apr 2006 11:42:34 -0300, rumours say that Jorge Godoy
<go***@ieee.org> might have written:

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.
--
TZOTZIOY, I speak England very best.
"Dear Paul,
please stop spamming us."
The Corinthians

[Lawrence D'Oliveiro]

In article <11**********************@v46g2000cwv.googlegroups .com>,
"Carl Banks" <in**********@aerojockey.com> wrote:

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]

In article <ro***********************@reader1.panix.com>,
Roy Smith <ro*@panix.com> wrote:

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]

On Tue, 11 Apr 2006 15:05:22 +1200, rumours say that Lawrence D'Oliveiro
<ld*@geek-central.gen.new_zealand> might have written:

In article <ro***********************@reader1.panix.com>,
Roy Smith <ro*@panix.com> wrote:

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?

“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.
--
TZOTZIOY, I speak England very best.
"Dear Paul,
please stop spamming us."
The Corinthians

[Ben Sizer]

Lawrence D'Oliveiro wrote:

In article <11**********************@v46g2000cwv.googlegroups .com>,
"Carl Banks" <in**********@aerojockey.com> wrote:

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.

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.

--
Ben Sizer

[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
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Terry Reedy]

"Sybren Stuvel" <sy*******@YOURthirdtower.com.imagination> wrote in

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

[Lawrence D'Oliveiro]

In article <11**********************@t31g2000cwb.googlegroups .com>,
"Ben Sizer" <ky*****@gmail.com> wrote:

Lawrence D'Oliveiro wrote:

In article <11**********************@v46g2000cwv.googlegroups .com>,
"Carl Banks" <in**********@aerojockey.com> wrote:

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

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.

All we have to do is keep using and promoting 4-column tabs every chance
we get. I've been using them myself for about 18 years. Eventually
they'll become accepted as the standard.

[Lawrence D'Oliveiro]

In article <ma***************************************@python. org>,
"Terry Reedy" <tj*****@udel.edu> wrote:

"Sybren Stuvel" <sy*******@YOURthirdtower.com.imagination> wrote in

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.

I have my newsreader set to use a proportional font, so the point is
moot.

Any time I want to see something in fixed columns, I copy and paste it
into an editor window I always happen to have handy.

[Peter Hansen]

Lawrence D'Oliveiro wrote:

In article <11**********************@t31g2000cwb.googlegroups .com>,
"Ben Sizer" <ky*****@gmail.com> wrote:

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.

All we have to do is keep using and promoting 4-column tabs every chance
we get. I've been using them myself for about 18 years. Eventually
they'll become accepted as the standard.

"I am Lawrence of Borg. You will be tabulated. Resistance is futile."

:-)

[Dave Hansen]

On Wed, 12 Apr 2006 17:19:25 +1200 in comp.lang.python, Lawrence
D'Oliveiro <ld*@geek-central.gen.new_zealand> wrote:

In article <ma***************************************@python. org>,
"Terry Reedy" <tj*****@udel.edu> wrote:

"Sybren Stuvel" <sy*******@YOURthirdtower.com.imagination> wrote in

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

I have my newsreader set to use a proportional font, so the point is
moot.

Even in a proportional font, spaces all have the same width. Though
not as wide as a fixed font...

Regards,
-=Dave

--
Change is inevitable, progress is not.