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:h...@carcass.dhs.org
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.
>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 ?
> 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:
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.
>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. ..
>>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:
> 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.
| 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.
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...
-- Best regards,
Steve mailto:h...@carcass.dhs.org
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 ?
-- Best regards,
Steve mailto:h...@carcass.dhs.org
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.
-- Best regards,
Steve mailto:h...@carcass.dhs.org
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 ;)
>>>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 ;)
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 ...
