Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Invisible function attributes

Reply
Thread Tools

Invisible function attributes

 
 
Olivier Lefevre
Guest
Posts: n/a
 
      09-03-2003
Python 2.3
>>> def foo():

.... foo.a = 1
....
>>> vars(foo)

{}
>>> foo()
>>> vars(foo)

{'a': 1}
>>>


So it would appear that function attributes are not really
there until the first call to the function. If that is the
intended behaviour, it is really weird. I couldn't find any
explicit discussion of this topic in the LRM.

Thanks if anyone can shed some light on this,

-- O.L.
 
Reply With Quote
 
 
 
 
Tom Lee
Guest
Posts: n/a
 
      09-03-2003
Olivier Lefevre wrote:

> Python 2.3
>
>>>>def foo():

>
> ... foo.a = 1
> ...
>
>>>>vars(foo)

>
> {}
>
>>>>foo()
>>>>vars(foo)

>
> {'a': 1}
>
>
> So it would appear that function attributes are not really
> there until the first call to the function. If that is the
> intended behaviour, it is really weird. I couldn't find any
> explicit discussion of this topic in the LRM.
>
> Thanks if anyone can shed some light on this,
>
> -- O.L.


Makes sense to me.

The foo.a = 1 line should never be executed until foo() is executed.
Thus, foo.a is never set before the call to foo.

- TL

 
Reply With Quote
 
 
 
 
Peter Otten
Guest
Posts: n/a
 
      09-03-2003
def foo():
try:
foo.a += 1 # executed every time you call the function
except AttributeError:
foo.a = 1 # set to one if it's not already there

foo.b = 1 # executed once

print vars(foo) # function body not yet called {'b': 1}

for i in range(3):
foo()
print vars(foo)

Loop output is

{'a': 1, 'b': 1}
{'a': 2, 'b': 1}
{'a': 3, 'b': 1}

That is all perfectly sane as code in the function body is never executed
unless you call the function, whereas code on the module level is executed
immediately as the module is imported. So put foo.attr = ... into the
function body iff you want it to execute every time the function is
invoked; otherwise put it into the module startup code, i. e. do not indent
it.

Peter

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      09-03-2003

"Olivier Lefevre" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Python 2.3
> >>> def foo():

> ... foo.a = 1


If you want foo to be attributed before it is called, move the setter
outside the function.

>>> def foo(): pass

....
>>> foo.a = 1
>>> vars(foo)

{'a': 1}

Terry J Reedy


 
Reply With Quote
 
Bob Gailer
Guest
Posts: n/a
 
      09-03-2003
Of course the inevitable question is why do you want to do this? Consider
creating a class instead (with a __call__ method if you want to call the
instance as a function).

class Foo:
a = 1 # pre-initialized property
def __call__(self):
print self.a

foo = Foo()
foo()
# prints 1

Bob Gailer
http://www.velocityreviews.com/forums/(E-Mail Removed)
303 442 2625


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

 
Reply With Quote
 
John J. Lee
Guest
Posts: n/a
 
      09-03-2003
(E-Mail Removed) (Olivier Lefevre) writes:
[...]
> So it would appear that function attributes are not really
> there until the first call to the function. If that is the


Not function attributes in general, just those that are first assigned
to in the function body. No special rule here, though, because...


> intended behaviour, it is really weird. I couldn't find any
> explicit discussion of this topic in the LRM.
>
> Thanks if anyone can shed some light on this,


....what I'm guessing you haven't figured out yet is that everything
works like this in Python. For example, what might be called a 'class
declaration' in other languages isn't really a declaration in Python,
it's code that gets executed at runtime. Same is true of functions:

if WANT_SPAM:
def sayhello(): print "spam"
else:
def sayhello(): print "eggs"

sayhello()


And your foo.a = 1 isn't a declaration (Python doesn't have them,
really), it's just an attribute assignment.


John
 
Reply With Quote
 
Olivier Lefevre
Guest
Posts: n/a
 
      09-04-2003
Thanks to all those who replied.

> ...what I'm guessing you haven't figured out yet is that everything
> works like this in Python.


Very possibly. I am coming to python from Java and I want to investigate
the weird stuff precisely because either it's a one-off (in which case
I'll make a note to myself to ignore it and not use it) or it holds the
key to what is specific about the language. I seem to have hit pay dirt
with this one

Nudged by the dot syntax, I was thinking of this function attribute as
if it were a sort of class member (i.e., pretending for a while this
function is a class) and, since functions can't have instances, treating
it as a sort of static member of the function, which should be available
as soon as declared. Obviously I got it all wrong. Instead, they work
like local variables except that they "persist" after the function has
exited. That still feels weird to me. What are they used for? Give me
a compelling reason to have such a beast in the language.

OTOH, does this behaviour have anything to do with so-called "futures"?

-- O.L.
 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      09-04-2003

"Olivier Lefevre" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Thanks to all those who replied.
>
> > ...what I'm guessing you haven't figured out yet is that everything
> > works like this in Python.

>
> Very possibly. I am coming to python from Java and I want to investigate
> the weird stuff precisely because either it's a one-off (in which case
> I'll make a note to myself to ignore it and not use it) or it holds the
> key to what is specific about the language. I seem to have hit pay dirt
> with this one
>
> Nudged by the dot syntax, I was thinking of this function attribute as
> if it were a sort of class member (i.e., pretending for a while this
> function is a class) and, since functions can't have instances, treating
> it as a sort of static member of the function, which should be available
> as soon as declared. Obviously I got it all wrong. Instead, they work
> like local variables except that they "persist" after the function has
> exited. That still feels weird to me. What are they used for? Give me
> a compelling reason to have such a beast in the language.


I don't know of a really compelling reason, other than it simply
works that way. Like everything else in the language, functions
are objects, which means that they have a dictionary at their
core. Therefore, functions can have attributes.

The only use I can think of would be definitely advanced
programming. Functions are first class objects, which means
they can be rebound anywhere you want them. If you find
a good reason to do that, then as an extension you might find
a reason to add attributes to classify what you've got so you
can manage the process.

As I said, I'm reaching with this one...

>
> OTOH, does this behaviour have anything to do with so-called "futures"?


No. Future is a feature so that experimental features can be added to the
language in one release, and then made standard in a future release.

John Roth
>
> -- O.L.



 
Reply With Quote
 
Jacek Generowicz
Guest
Posts: n/a
 
      09-05-2003
(E-Mail Removed) (Olivier Lefevre) writes:

> Nudged by the dot syntax, I was thinking of this function attribute as
> if it were a sort of class member (i.e., pretending for a while this
> function is a class) and, since functions can't have instances, treating
> it as a sort of static member of the function, which should be available
> as soon as declared.


There is no declaration in Python; you just create attributes by
binding objects to names.

> Obviously I got it all wrong. Instead, they work like local
> variables except that they "persist" after the function has exited.


Hmmm. No. Functions are first class objects, and you can dynamically
add attributes to them as you go along (as is the case for many, but
not all, other types of objects).

Do you realize that the foo identifier you used in your example is not
inextricably linked to any function whose name is foo? The name of a
function, and the variables to which it is bound are two different
concepts.

Consequently, the foo.a in the function body only _coincidentally_
refers to an attribute of the function in which it appears.

Consider:

>>> def foo(arg): foo.a = arg

....
>>> bar = foo # Now the function is known by two different names
>>> bar(3)
>>> foo.a

3
>>> foo = 1 # Now the function called "foo" can only be accessed via bar !
>>> bar(4)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in foo
TypeError: 'int' object has only read-only attributes (assign to .a)
>>> bar # I call it "bar", bit it thinks it's called "foo"

<function foo at 0x815e71c>
>>>


The error at "bar(4)" in the above should hint at the fact that the
"foo" in "foo.a" in the definition of the function foo, does not refer
to the function itself but to whatever object which happens to be
bound to the name "foo" at the time the function is being exectuted.

> What are they used for? Give me a compelling reason to have such a
> beast in the language.


Now there's a good question I haven't found a use for these
myself ... but then I haven't looked very hard for one.

Given that function attributes were added to the language (in version
2.1 or 2.2 ?), I guess someone felt a need for them, and Guido agreed.
 
Reply With Quote
 
Olivier Lefevre
Guest
Posts: n/a
 
      09-11-2003
> Python has no declarations, only executable statements.

I think this was the key to my confusion in this case.

> >>> bar(4)

> Traceback (most recent call last):
> TypeError: 'int' object has only read-only attributes (assign to .a)


The way I read this, it says that a was bound to the name foo,
not to the function foo stood for at the time of that function's
definition; you are saying as much. Thus "foo.a" has to be looked
up and resolved anew for each call. This must be costly. Why was
it done this way?

OTOH I read the func attr PEP and it says that they are
implemented via a dict inside the function object. If so,
shouldn't they be bound to the function object rather than
to its name?? Or is func_dict itself an attribute?

-- O.L.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Making 1 control invisible while showing another in the exact location of the invisible one Andy B ASP .Net 5 05-29-2008 03:08 AM
Invisible - Succinic acid : (AMBER ACID) Invisible krithika.143@gmail.com C++ 0 04-14-2008 06:59 PM
class attributes & data attributes james_027 Python 2 06-20-2007 03:12 PM
WebControl.Attributes.Add and custom attributes P4trykx ASP .Net 2 01-31-2007 04:33 PM
Parse reserved attributes as normal attributes Max XML 1 09-22-2006 12:04 PM



Advertisments