def index(self):

[Gert Cuykens]

Is there a difference between

<code>
class HelloWorld:
def index(self):
index.exposed = True
return "Hello world!"
</code>

and

<code>
class HelloWorld:
def index(self):
self.exposed = True
return "Hello world!"
</code>

[Jussi Salmela]

Gert Cuykens kirjoitti:

Is there a difference between

<code>
class HelloWorld:
def index(self):
index.exposed = True
return "Hello world!"
</code>

and

<code>
class HelloWorld:
def index(self):
self.exposed = True
return "Hello world!"
</code>

The resident experts seemingly being absent for a while, I'll strike:

Yes: the first gives a runtime error and the second is OK.
I've renamed the second class to HelloWorld2 and then:

>>hw = HelloWorld()
hw2 = HelloWorld2()

>>hw.index()

Traceback (most recent call last):
File "<pyshell#144>", line 1, in <module>
hw.index()
File "C:\Python\Dive into Python\Py\apihelper.py", line 40, in index
index.exposed = True
NameError: global name 'index' is not defined

>>hw2.index()

'Hello world!'

The error message shows that the Python compiler has interpreted the
construction 'index.exposed' to refer to a global variable 'index' that
doesn't exist at run time. The second class succesfully defines an
instance attribute 'exposed' as can be seen by:

>>print hw2.exposed

True

HTH
Jussi

[Bruno Desthuilliers]

Gert Cuykens a écrit :

Is there a difference between

<code>
class HelloWorld:
def index(self):
index.exposed = True
return "Hello world!"
</code>

and

<code>
class HelloWorld:
def index(self):
self.exposed = True
return "Hello world!"
</code>

Ask yourself what are the names 'index' and 'self' refering to in the
context of this function, and you'll have the answer. And if you can't
answer, then it may be time to learn Python...

FWIW, the first version raises an exception (unless of course the name
'index' is already bound in the enclosing scope). And the second won't
probably work as expected with CherryPy.

[Gert Cuykens]

FWIW, the first version raises an exception (unless of course the name

'index' is already bound in the enclosing scope). And the second won't
probably work as expected with CherryPy.

<code>
class HelloWorld:
def index(self):
return "Hello world!"
index.exposed = True #DOOOOOOH!
</code>

i skipped reading the chapter about 2.1.8 Indentation. Guess how many
hours it took to realize 2 spaces isn't the same as 1 space lol

Any other chapters i should read horizontal instead of vertical for a
php5 htm jso wane be snake user :)

[Bruno Desthuilliers]

Gert Cuykens a écrit :

>FWIW, the first version raises an exception (unless of course the name
'index' is already bound in the enclosing scope). And the second won't
probably work as expected with CherryPy.

<code>
class HelloWorld:
def index(self):
return "Hello world!"
index.exposed = True #DOOOOOOH!

And the winner is....

</code>

i skipped reading the chapter about 2.1.8 Indentation. Guess how many
hours it took to realize 2 spaces isn't the same as 1 space lol

Hint:
- use a good code editor with auto(de)indentation (emacs + python-mode
is quite nice)
- use 4 spaces for indentation

Any other chapters i should read horizontal instead of vertical for a
php5 htm jso wane be snake user :)

The whole thing, I guess. While Python is quite easy to get started
with, there are a few gotchas. You're above snippet should be:

class HelloWorld(object):
def index(self):
return "Hello World"
index.exposed = True

[Tim Roberts]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

>
Gert Cuykens a écrit :

>>FWIW, the first version raises an exception (unless of course the name
'index' is already bound in the enclosing scope). And the second won't
probably work as expected with CherryPy.

<code>
class HelloWorld:
def index(self):
return "Hello world!"
index.exposed = True #DOOOOOOH!

And the winner is....

></code>

The whole thing, I guess. While Python is quite easy to get started
with, there are a few gotchas. You're above snippet should be:

class HelloWorld(object):
def index(self):
return "Hello World"
index.exposed = True

Many people find it more readable to write that as:

class HelloWorld(object):
@cherrypy.exposed
def index(self):
return "Hello World"

I haven't decided yet.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Bruno Desthuilliers]

Tim Roberts a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

>>Gert Cuykens a écrit :

>>>>FWIW, the first version raises an exception (unless of course the name
'index' is already bound in the enclosing scope). And the second won't
probably work as expected with CherryPy.

<code>
class HelloWorld:
def index(self):
return "Hello world!"
index.exposed = True #DOOOOOOH!

And the winner is....

>>></code>

The whole thing, I guess. While Python is quite easy to get started
with, there are a few gotchas. You're above snippet should be:

class HelloWorld(object):
def index(self):
return "Hello World"
index.exposed = True

Many people find it more readable to write that as:

class HelloWorld(object):
@cherrypy.exposed
def index(self):
return "Hello World"

So do I. But this breaks compatibility with older Python versions, and
is perhaps a bit confusing for someone that doesn't seem to really get
some basic Python stuffs like what 'self' is...

My 2 cents

[Gert Cuykens]

class HelloWorld(object):

@cherrypy.exposed
def index(self):
return "Hello World"

do i have to write @cherrypy.exposed before every def or just once for
all the def's ? and why not write something like @index.exposed ?

in other words i have no idea what @ actually does i only know i have
too write it to make it work :) Am guessing @ is something like
prototyping in javascript but then def index is not a object but a
method ? So that would not make sense ?

oh and self stands more or less for private method right ?

[George Sakkis]

Gert Cuykens wrote:

class HelloWorld(object):
@cherrypy.exposed
def index(self):
return "Hello World"

do i have to write @cherrypy.exposed before every def or just once for
all the def's ? and why not write something like @index.exposed ?

in other words i have no idea what @ actually does i only know i have
too write it to make it work :) Am guessing @ is something like
prototyping in javascript but then def index is not a object but a
method ? So that would not make sense ?

oh and self stands more or less for private method right ?

Ouch. Do you really expect to learn a language from scratch by Q&A in a
malining list ? That's a very inefficient way to spend both yours and
others' time. Do your homework first by reading one of the several free
tutorials online and come back when you have trouble with something
specific you didn't understand.

George

[Duncan Booth]

"George Sakkis" <ge***********@gmail.comwrote:

Gert Cuykens wrote:

class HelloWorld(object):
@cherrypy.exposed
def index(self):
return "Hello World"

do i have to write @cherrypy.exposed before every def or just once
for all the def's ? and why not write something like @index.exposed ?

in other words i have no idea what @ actually does i only know i have
too write it to make it work :) Am guessing @ is something like
prototyping in javascript but then def index is not a object but a
method ? So that would not make sense ?

oh and self stands more or less for private method right ?

Ouch. Do you really expect to learn a language from scratch by Q&A in
a malining list ? That's a very inefficient way to spend both yours
and others' time. Do your homework first by reading one of the several
free tutorials online and come back when you have trouble with
something specific you didn't understand.

To be perfectly fair, searching for information about decorators if you
don't know what they are called is kind of hard. Searching for
information about the '@' character in the Python documentation doesn't
lead to much. The CherryPy tutorial does at least mention this
decorator, just not in any meaningful way:

Exposing objects

CherryPy maps URL requests to objects and calls the suitable method
automatically. The methods that can be called as a result of external
requests are said to be exposed.

Objects are exposed in CherryPy by setting the exposed attribute. This
an be done directly on the object itself: object.exposed = True.
Methods can also be exposed using a special decorator:

Why this distinction?

The distinction between published and exposed objects may seem silly
or unnecessary at first. By definition, all exposed objects are also
published, so why do we need to care about non-exposed objects?

To the OP:

do i have to write @cherrypy.exposed before every def or just once for
all the def's ?

Before every def that you wish to expose, which won't be all of them.

and why not write something like @index.exposed ?

because that isn't how it works. cherrypy.exposed is a decorator, which
means it is a function that takes a function as an argument modifies it in
some way and returns the modified function as its result.

>
in other words i have no idea what @ actually does i only know i have
too write it to make it work :) Am guessing @ is something like
prototyping in javascript but then def index is not a object but a
method ? So that would not make sense ?

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = (expr)(fn)

except that at the point when the decorator is called the function has not
yet been assigned to the name 'fn'. (Also remember that def is an
executable statement so it happens when the line containing the def is
execfuted, and that names assigned to functions are just like other
variable names and can be rebound at will.)

>
oh and self stands more or less for private method right ?

if you have to ask that question about 'self' you really do need to read
some introductory texts on Python.

Methods get passed their instance as their first parameter (usually this is
implicit in the call, but it is always explicitly shown in the method) and
self is simply the conventional name. Many other languages use 'this'
instead of self and make the passing of 'this' implicit inside the method
as well as outside. There are good reasons why it is explicit in Python,
but just remember that the first parameter a method receives is always the
instance and you won't go far wrong.

[Gert Cuykens]

On 21 Dec 2006 09:44:48 GMT, Duncan Booth <du**********@invalid.invalidwrote:

"George Sakkis" <ge***********@gmail.comwrote:

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = (expr)(fn)

ok i did my homework reading about decorators
http://www.python.org/doc/2.4.4/whatsnew/node6.html

could it be the example above needs to be like

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = expr(fn)

oh and self stands more or less for private method right ?

if you have to ask that question about 'self' you really do need to read
some introductory texts on Python.

Methods get passed their instance as their first parameter (usually this is
implicit in the call, but it is always explicitly shown in the method) and
self is simply the conventional name. Many other languages use 'this'
instead of self and make the passing of 'this' implicit inside the method
as well as outside. There are good reasons why it is explicit in Python,
but just remember that the first parameter a method receives is always the
instance and you won't go far wrong.

in all the things i every read about self i end up with blablabla
scoping blabla blabla self:: blablabla public static methods blablabla
:)

So when reading 'self' is the same as 'this' it was worth asking the
question for confusion sake :)

[Marc 'BlackJack' Rintsch]

In <ma***************************************@python. org>, Gert Cuykens
wrote:

On 21 Dec 2006 09:44:48 GMT, Duncan Booth <du**********@invalid.invalidwrote:

>"George Sakkis" <ge***********@gmail.comwrote:

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = (expr)(fn)

ok i did my homework reading about decorators
http://www.python.org/doc/2.4.4/whatsnew/node6.html

could it be the example above needs to be like

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = expr(fn)

This depends on the definition of `expr`. If `expr` includes the
possibility of enclosing parenthesis then yes. There are scenarios where
you would need them. For example if you use objects that overload
operators to build a callable used as decorator:

@spam + eggs + viking
def fn(...): ...

This would not be equivalent to:

def fn(...): ...
fn = spam + eggs + viking(fn)

but:

def fn(...): ...
fn = (spam + eggs + viking)(fn)

Ciao,
Marc 'BlackJack' Rintsch

[Fredrik Lundh]

Marc 'BlackJack' Rintsch wrote:

This depends on the definition of `expr`. If `expr` includes the
possibility of enclosing parenthesis then yes. There are scenarios where
you would need them. For example if you use objects that overload
operators to build a callable used as decorator:

@spam + eggs + viking
def fn(...): ...

that's a SyntaxError. the decorator syntax only allows for a dotted
name, optionally followed by an argument list in parentheses.

</F>

[Duncan Booth]

"Gert Cuykens" <ge**********@gmail.comwrote:

On 21 Dec 2006 09:44:48 GMT, Duncan Booth
<du**********@invalid.invalidwrote:

>"George Sakkis" <ge***********@gmail.comwrote:

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = (expr)(fn)

ok i did my homework reading about decorators
http://www.python.org/doc/2.4.4/whatsnew/node6.html

could it be the example above needs to be like

@expr
def fn(...): ...

is exactly equivalent to:

def fn(...): ...
fn = expr(fn)

no it doesn't *need* to be like that, but it *could* be written like that.
It is true that the parentheses I used are redundant (I thought they made
my point clearer), but removing redundant parentheses doesn't actually
change the meaning at all.

In any case, either of these rewrites is an approximation. There is no
Python code you can write which is exactly equivalent to, but doesn't use,
the decorator syntax. A closer approximation would be:

If you consider:

def fn(...): ...

is equivalent to writing:

fn = new.function(somecodeobject, globals(), 'fn', (...default argument
expressions...), ...and maybe a closure...)

then:

@expr
def fn(...): ...

is equivalent to writing:

__anonymous_temp_1 = expr
__anonymous_temp_2 = new.function(somecodeobject, globals(), 'fn',
(...default argument expressions...), ...and maybe a closure...)
fn = __anonymous_temp_1(__anonymous_temp_2)

but I don't think that is really any clearer.

It does perhaps indicate the order in which things happen more clearly:
decorator expression is evaluated, then default arguments, then function is
created, then decorator is called, then finally the result is assigned to a
variable with the same name as the function.

[Gert Cuykens]

Ok thx i think i understand it now

>>class C:

.... @staticmethod
.... def fn():
.... return 'whohoo'
....

>>C.fn()

'whohoo'

>>>