Published object names

4 views
Skip to first unread message

Steve Howe

unread,
Feb 13, 2005, 1:19:33 PM2/13/05
to cherryp...@googlegroups.com
Hello all,

I recently begun playing with cherrypy, and although I love the idea of
publishing functions, I thought about an annoying limitation: does that
mean I can't have objects called "print", "class" or "exec", for
instance, since they are are reserved Python names (and I can't name a
function with a reserved name) ? Is there any way to circumvent that, in
case the limitation applies, like playing with the functions dictionary
?

Perhaps functions could have a "exposed_name" attrib, in the line of
"exposed" attrib, that allows one to change their published (exposed)
names. Is that available ? I'm sorry if it's an easy response, docs for
CherryPy v2.0 are currently somewhat sparse.

Also, since I'm beginning with with it, would it be best to start with
v2.0 as I did or just try with 0.10 series ? Any recommendations ?

Thanks.
--
Best regards,
Steve mailto:ho...@carcass.dhs.org

Sylvain Hellegouarch

unread,
Feb 14, 2005, 2:51:36 AM2/14/05
to cherryp...@googlegroups.com
Hi Steve,

Point 1. No you can't have such names but it is not CP's fault. CP2 is a
Python module and thus follows Python's rules, which means that you
cannot use reserved keywords for something different from their purpose.
You would get some strange behavior.

Point 2. It is best starting with CP v2 as CP v1 is not supported
anymore and far less powerful :)

Don't worry about your questions, we'll be pleased to help.

- Sylvain

Steve Howe a écrit :

Steve Howe

unread,
Feb 14, 2005, 11:10:32 AM2/14/05
to Sylvain Hellegouarch
Hello Sylvain,

Monday, February 14, 2005, 4:51:36 AM, you wrote:

> Point 1. No you can't have such names but it is not CP's fault. CP2 is a
> Python module and thus follows Python's rules, which means that you
> cannot use reserved keywords for something different from their purpose.
> You would get some strange behavior.
Thanks for the responses.

The behavior will be a module that has a syntax error :) However, what
if I want to publish a "http:/mysite.com/class" url ? I think there
should be a way to do it, and having a function attribute comes to mind.
Something like:

def _class():
...

_class.exposed = True
_class.expose_name = 'class'


Am I allowed to send a patch to do this ? Is anyone else interested in
this functionality ? Obviously, the same should be implmented to the
"published" attribute.

Best Regards,
Steve

Remco Boerma

unread,
Feb 14, 2005, 10:25:02 AM2/14/05
to cherryp...@googlegroups.com
Steve Howe wrote:

>def _class():
> ...
>
>_class.exposed = True
>_class.expose_name = 'class'
>
>Am I allowed to send a patch to do this ? Is anyone else interested in
>this functionality ? Obviously, the same should be implmented to the
>"published" attribute.
>
>
There is a quick hack to solve your problem. If that keeps you from
writing the patch : )
I don't think the patch is needed, and it would allow an even more
complex mapping, and
might turn out to be quite confusing.

assuming cpg.root.some.var._class is something you want to have
published, but with the _class
being class. ..

setattr(cpg.root.some.var,'class',cpg.root.some.var._class)

or, even simpler

class SomeClass(object):
def __init__(self):
setattr(self,'print',self._print)
setattr(self,'class',self._class)

def _print(self):
....
_print.exposed = True

def _class(self):
....
_class.exposed = True

This should do the trick as well.

you could even delete the original _print and _class functions if you
would like to.


Cheers!
Remco Boerma
IPN Developer

Remi Delon

unread,
Feb 14, 2005, 10:23:48 AM2/14/05
to cherryp...@googlegroups.com
>>Point 1. No you can't have such names but it is not CP's fault. CP2 is a
>>Python module and thus follows Python's rules, which means that you
>>cannot use reserved keywords for something different from their purpose.
>>You would get some strange behavior.
>
> Thanks for the responses.
>
> The behavior will be a module that has a syntax error :) However, what
> if I want to publish a "http:/mysite.com/class" url ? I think there
> should be a way to do it, and having a function attribute comes to mind.
> Something like:
>
> def _class():
> ...
>
> _class.exposed = True
> _class.expose_name = 'class'
>
>
> Am I allowed to send a patch to do this ? Is anyone else interested in
> this functionality ? Obviously, the same should be implmented to the
> "published" attribute.

I think it's a good idea to have an easy way to set the "expose_name".
This will be a nice workaround for python's variable name limitations
that don't exist in URLs.
That would provide an easy way to dynamically serve robots.txt and
favicon.ico for instance.

However, I think this is part of a more general discussion that should
also include the verbs and other things...

Right now, you can only tell CherryPy "expose this object", whereas it
would be more flexible to be able tell it "expose this object under that
name, for these verbs"

I just want to make sure we have a generic way of supporting these
features before we start adding more and more attributes ...

There will be a discussion about this in the next IRC session.

Remi.

Tom Jenkins

unread,
Feb 14, 2005, 11:16:41 AM2/14/05
to cherryp...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remco Boerma wrote:
| There is a quick hack to solve your problem. If that keeps you from
| writing the patch : )
|
| assuming cpg.root.some.var._class is something you want to have
| published, but with the _class
| being class. ..
|
| setattr(cpg.root.some.var,'class',cpg.root.some.var._class)
|
| or, even simpler
|
| class SomeClass(object):
| def __init__(self):
| setattr(self,'print',self._print)
| setattr(self,'class',self._class)
|
| def _print(self):
| ....
| _print.exposed = True
|
| def _class(self):
| ....
| _class.exposed = True
|
| This should do the trick as well.

i feel this is the proper way to do it. i don't consider this a hack,
its exactly what you need to do for any python program... however i'll
concede that my definition of hack may not be everyones <wink>.

thanks to Remco for sharing the code snippet.
thanks to Steve for the question so this code snippet could be shared.

- --
Tom Jenkins
DevIS - Development Infostructure
http://www.devis.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0-nr2 (Windows XP)
Comment: Using GnuPG with MultiZilla - http://enigmail.mozdev.org

iD8DBQFCEM7pV7Yk9/McDYURAqgTAJ4jfV9PunwnvzT4RK5sGfe6grwOjwCgiU1g
ykYD+M0jW8+2wYraDI0OdYI=
=iGsq
-----END PGP SIGNATURE-----

Steve Howe

unread,
Feb 14, 2005, 12:27:54 PM2/14/05
to Remco Boerma
Hello Remco,

Monday, February 14, 2005, 12:25:02 PM, you wrote:

> There is a quick hack to solve your problem. If that keeps you from
> writing the patch : ) I don't think the patch is needed, and it would
> allow an even more complex mapping, and might turn out to be quite
> confusing.

> assuming cpg.root.some.var._class is something you want to have
> published, but with the _class
> being class. ..

> setattr(cpg.root.some.var,'class',cpg.root.some.var._class)
[...]

> you could even delete the original _print and _class functions if you
> would like to.
Thanks, Remco. That's what I imagined it should be done. However, I
don't have a problem *yet*, I just wanted to suggest something I thought
it could be useful, and intuitive enough. I'll use your method if I have
to work around the varnames limitation.

I was thinking about it and realized that urls can't also be named
"tic-tac-toe", "1000", because of the very same limitation - and that
could be very annoying...

Steve Howe

unread,
Feb 14, 2005, 12:30:15 PM2/14/05
to Remi Delon
Hello Remi,

Monday, February 14, 2005, 12:23:48 PM, you wrote:

> I think it's a good idea to have an easy way to set the "expose_name".
> This will be a nice workaround for python's variable name limitations
> that don't exist in URLs.
> That would provide an easy way to dynamically serve robots.txt and
> favicon.ico for instance.

> However, I think this is part of a more general discussion that should
> also include the verbs and other things...

> Right now, you can only tell CherryPy "expose this object", whereas it
> would be more flexible to be able tell it "expose this object under that
> name, for these verbs"

> I just want to make sure we have a generic way of supporting these
> features before we start adding more and more attributes ...

> There will be a discussion about this in the next IRC session.
Am I allowed to participate ? I plan to start working heavily with
CherryPy, and the more I get into it, the better will be, specially if I
can contribute with something. When will it be ?

Steve Howe

unread,
Feb 14, 2005, 12:41:29 PM2/14/05
to Remco Boerma
Hello Remco,

Monday, February 14, 2005, 12:25:02 PM, you wrote:

> There is a quick hack to solve your problem. If that keeps you from
> writing the patch : )
> I don't think the patch is needed, and it would allow an even more
> complex mapping, and
> might turn out to be quite confusing.
I forgot to mention that I think there should be a documented way to do
it, so that it becomes "standard". Your approach, while simple and
totally viable, not being documented, really becomes a "hack". I suggest
that the most "intuitive" method, once agreed about it, be used, even if
it just calls Remco's code. That way, if something changes in the
future, like the root var's name, code that use that feature won't be
broken.

Jos

unread,
Feb 14, 2005, 11:52:05 AM2/14/05
to cherryp...@googlegroups.com
Remco Boerma wrote:
>
> class SomeClass(object):
> def __init__(self):
> setattr(self,'print',self._print)
> setattr(self,'class',self._class)
>
> def _print(self):
> ....
> _print.exposed = True
>
> def _class(self):
> ....
> _class.exposed = True

I just added this to the FAQ page.

j

--
jos yule
Digital Hyakugei

mailto:j...@theorganization.net
http://www.theorganization.net

aim:josyule
msn:hyak...@hotmail.com

Remco Boerma

unread,
Feb 15, 2005, 4:19:28 AM2/15/05
to cherryp...@googlegroups.com
Steve Howe wrote:
There is a quick hack to solve your problem. If that keeps you from
writing the patch : )
I don't think the patch is needed, and it would allow an even more 
complex mapping, and
might turn out to be quite confusing.
    
I forgot to mention that I think there should be a documented way to do
it, so that it becomes "standard". Your approach, while simple and
totally viable, not being documented, really becomes a "hack". I suggest
that the most "intuitive" method, once agreed about it, be used, even if
it just calls Remco's code. That way, if something changes in the
future, like the root var's name, code that use that feature won't be
broken.
Well, my 'hack', if named correctly, is the proper way to do it, in a strange fashion. It's pure python,
and the object mapper simply searches for the names in the object hierarchy, using getattribute.
If you keep that in mind, a lot of things aren't a problem ;)

Cheers all!

Remco Boerma

Remi Delon

unread,
Feb 15, 2005, 7:34:46 AM2/15/05
to cherryp...@googlegroups.com
Well, I see that someone added it to the FAQ, so I guess we're good to
go :-)
I still see this as a little bit hacky, but I guess that since it's only
one line of code it's not that bad after all ...

Remi.

Steve Howe

unread,
Feb 15, 2005, 12:22:13 PM2/15/05
to Remi Delon
Hello Remi,

Tuesday, February 15, 2005, 9:34:46 AM, you wrote:

> Well, I see that someone added it to the FAQ, so I guess we're good to
> go :-)
> I still see this as a little bit hacky, but I guess that since it's only
> one line of code it's not that bad after all ...
Ok, just to end this discussion: are you sure it is a safe way to
suggest and you're not tempted to change the dictionary name at some
point, breaking compatibility with applications that use this ? Is this
revevant ?

Remi Delon

unread,
Feb 15, 2005, 12:06:53 PM2/15/05
to cherryp...@googlegroups.com
Steve Howe wrote:
> Hello Remi,
>
> Tuesday, February 15, 2005, 9:34:46 AM, you wrote:
>
>
>>Well, I see that someone added it to the FAQ, so I guess we're good to
>>go :-)
>>I still see this as a little bit hacky, but I guess that since it's only
>>one line of code it's not that bad after all ...
>
> Ok, just to end this discussion: are you sure it is a safe way to
> suggest and you're not tempted to change the dictionary name at some
> point, breaking compatibility with applications that use this ? Is this
> revevant ?

Well, the line you add is like this:

setattr(self,'print',self._print)

This doesn't reference any CP variable name and will always work ...

Remi.

Steve Howe

unread,
Feb 15, 2005, 1:14:40 PM2/15/05
to Remi Delon
Hello Remi,

Tuesday, February 15, 2005, 2:06:53 PM, you wrote:

> Well, the line you add is like this:
> setattr(self,'print',self._print)
> This doesn't reference any CP variable name and will always work ...
Hmm, ok, I was thinking about the other way... this should work,
alright.
Reply all
Reply to author
Forward
0 new messages