On 1/20/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-01-20 00:01, Brett Cannon wrote:
> > On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >> On 2007-01-19 22:33, Brett Cannon wrote:
> That's a typical error situation you get in __del__ methods at
> the time the interprete
On 2007-01-20 00:01, Brett Cannon wrote:
> On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-01-19 22:33, Brett Cannon wrote:
That's a typical error situation you get in __del__ methods at
the time the interpreter is shut down.
>>> Yeah, but in this case this is at the
Josiah Carlson schrieb:
> I was saying that it would be nice if the following were true:
>
> >>> encodings.__module__
>
Ah, ok. It would be somewhat confusing, though, that __module__ is
sometimes a module object, and sometimes a string (it certainly confused
me).
> So what if it is a c
On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-01-19 22:33, Brett Cannon wrote:
> >> That's a typical error situation you get in __del__ methods at
> >> the time the interpreter is shut down.
> >>
> >
> > Yeah, but in this case this is at the end of Py_Initialize() for the
> > stuff
On 2007-01-19 22:33, Brett Cannon wrote:
>> That's a typical error situation you get in __del__ methods at
>> the time the interpreter is shut down.
>>
>
> Yeah, but in this case this is at the end of Py_Initialize() for the
> stuff I am doing to the interpreter. =)
Is that in some error branch
On 1/18/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
> > Anybody have any ideas on how to deal with this short of rewriting
> > some codecs stuff so that they don't depend on global state in the
> > module or just telling me to just live with it?
>
> There is an old patc
On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-01-18 20:53, Brett Cannon wrote:
> > I have discovered an issue relating to func_globals for functions and
> > the deallocation of the module it is contained within. Let's say you
> > store a reference to the function encodings.search_
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson schrieb:
> > Seems to me like a bug, but the bug could be fixed if the module's
> > dictionary kept a (circular) reference to the module object. Who else
> > has been waiting for a __module__ attribute?
>
> This is the time machine
On 2007-01-18 20:53, Brett Cannon wrote:
> I have discovered an issue relating to func_globals for functions and
> the deallocation of the module it is contained within. Let's say you
> store a reference to the function encodings.search_function from the
> 'encodings' module (this came up in C cod
Josiah Carlson schrieb:
> Seems to me like a bug, but the bug could be fixed if the module's
> dictionary kept a (circular) reference to the module object. Who else
> has been waiting for a __module__ attribute?
This is the time machine at work:
py> import encodings
py> encodings.search_function
Brett Cannon schrieb:
> Anybody have any ideas on how to deal with this short of rewriting
> some codecs stuff so that they don't depend on global state in the
> module or just telling me to just live with it?
There is an old patch by Armin Rigo ( python.org/sf/812369 ), which
attempts to implemen
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
> I have discovered an issue relating to func_globals for functions and
> the deallocation of the module it is contained within. Let's say you
> store a reference to the function encodings.search_function from the
> 'encodings' module (this came up in C c
I have discovered an issue relating to func_globals for functions and
the deallocation of the module it is contained within. Let's say you
store a reference to the function encodings.search_function from the
'encodings' module (this came up in C code, but I don't see why it
couldn't happen in Pyth
13 matches
Mail list logo
