At 01:26 PM 6/28/2007 -0400, Phillip J. Eby wrote:
>You should also be able to delete unwanted function type attributes
>like this::
>
>from types import FunctionType
>del dictionary_of(FunctionType)['func_closure']
>del dictionary_of(FunctionType)['func_code']
By the way, you probabl
tav wrote:
> But, all I am asking for is to not expose func_closure (and perhaps
> some of the other func_*) as members of FunctionType -- isn't it
> possible to add functionality to the ``new`` module which would allow
> one to read/write func_closure?
Would func_closure then also be removed from
I love you PJE! Thank you! =)
On 6/28/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:23 PM 6/28/2007 +0100, tav wrote:
> >Any pointers on removing members via ctypes front?
> >
> >Whilst I can understand even the most obscure aspects of your python
> >code fine, I'm not familiar with C/ctyp
At 10:20 AM 6/28/2007 -0700, Robert Brewer wrote:
>tav wrote:
> > But, all I am asking for is to not expose func_closure (and perhaps
> > some of the other func_*) as members of FunctionType -- isn't it
> > possible to add functionality to the ``new`` module which would allow
> > one to read/write
At 05:23 PM 6/28/2007 +0100, tav wrote:
>Any pointers on removing members via ctypes front?
>
>Whilst I can understand even the most obscure aspects of your python
>code fine, I'm not familiar with C/ctypes...
What you want is to get access to the type's real dictionary, not the
proxy. Then you
At 04:14 PM 6/28/2007 +0100, tav wrote:
> > Well, there's no __self__ in 2.3 or 2.4; I guess that was added
> in 2.5. Darn.
>
>anyone know *why* it was added?
>
> > >Or, setting __call__.__doc__ ?
> >
> > What does that do?
>
>ah, i just wanted a way of providing documentation, and __call__'s
>__
> Well, there's no __self__ in 2.3 or 2.4; I guess that was added in 2.5. Darn.
anyone know *why* it was added?
> >Or, setting __call__.__doc__ ?
>
> What does that do?
ah, i just wanted a way of providing documentation, and __call__'s
__doc__ isn't writable...
> If it works, you could probabl
At 01:09 PM 6/28/2007 +0100, tav wrote:
>>You know, I find it particularly interesting that, as far as I can
>>tell, nobody who proposes making changes to the Python language to
>>add security, ever seems to offer any comparison or contrast of their
>>approaches to Zope's -- which doesn't require a
> You know, I find it particularly interesting that, as far as I can
> tell, nobody who proposes making changes to the Python language to
> add security, ever seems to offer any comparison or contrast of their
> approaches to Zope's -- which doesn't require any changes to the language. :)
Whilst
At 02:04 AM 6/28/2007 +0100, tav wrote:
>rehi all,
>
>I have been looking at the object capability + Python discussions for
>a while now, and was wondering what the use cases for
>``object.__subclasses__`` and ``FunctionType.func_closure`` were?
>
>I don't see __subclasses__ used anywhere in the st
rehi all,
I have been looking at the object capability + Python discussions for
a while now, and was wondering what the use cases for
``object.__subclasses__`` and ``FunctionType.func_closure`` were?
I don't see __subclasses__ used anywhere in the standard library. And
whilst I can see exposing f
11 matches
Mail list logo