quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: Python 2.5 nested auth functions in publisher.
Date Fri, 27 Oct 2006 21:58:38 GMT
Thanks, confirms my thinking when I was trying to sleep. That is,  
that the
only way they could do it if using co_varnames was to rely on  
co_argcount
to denote which are the function arguments and which aren't.

Strange, wander why they made this change?

Anyway, will log a JIRA issue and see if I can come up with alternate
code to cope with this. I wander if I am safe in assuming that < 2.5,  
that
len(co_varnames) is always the same as co_argcount.

Graham

On 27/10/2006, at 11:03 PM, Dan Eloff wrote:

> On 10/27/06, Graham Dumpleton <grahamd@dscpl.com.au> wrote:
>> Unless they have really screwed things around, co_varnames is
>> specifically
>> for function argument names and is unlikely to contained nested  
>> constant
>> names. If it did, then I would expect a lot of the publisher code to
>> break in
>> other ways as it uses co_varnames for the very specific purpose of
>> matching
>> form parameters against function arguments.
>
> I'd look into that code then.
>
>>>> fc.co_names
> ()
>>>> fc.co_varnames
> ('__auth__', '__access__')
>
>>>> def foo(a,b):
> 	d = 5
> 	def bar(c):
> 		return c
>
>>>> fc.co_names
> ()
>>>> fc.co_varnames
> ('a', 'b', 'd', 'bar')
>
> To get just args, try:
>
>>>> fc.co_varnames[:fc.co_argcount]
> ('a', 'b')
>
> And for just local vars:
>
>>>> fc.co_varnames[fc.co_argcount:]
> ('d', 'bar')
>
> -Dan

Mime
View raw message