Steve Holden wrote:
> Klaas wrote:
>> robert wrote:
>>
>>> Klaas wrote:
>>>
It seems clear that the import lock does not include fully-executing
the module contents. To fix this, just import cookielib before the
>>>
>>> What is the exact meaning of "not include fully-executing" -
>>> re
Klaas wrote:
> robert wrote:
>
>>Klaas wrote:
>>
>>>It seems clear that the import lock does not include fully-executing
>>>the module contents. To fix this, just import cookielib before the
>>
>>What is the exact meaning of "not include fully-executing" - regarding the
>>examples "import cookie
robert wrote:
> Klaas wrote:
> > It seems clear that the import lock does not include fully-executing
> > the module contents. To fix this, just import cookielib before the
>
> What is the exact meaning of "not include fully-executing" - regarding the
> examples "import cookielib" ?
> Do you real
Klaas wrote:
> It seems clear that the import lock does not include fully-executing
> the module contents. To fix this, just import cookielib before the
What is the exact meaning of "not include fully-executing" - regarding the
examples "import cookielib" ?
Do you really mean the import statemen
It seems clear that the import lock does not include fully-executing
the module contents. To fix this, just import cookielib before the
threads are spawned. Better yet, use your own locks around the
acquisition of the opener instance (this code seems fraughtfully
thread-unsafe--fix that and you s
I get python crashes and (in better cases) strange Python exceptions when (in
most cases) importing and using cookielib lazy on demand in a thread.
It is mainly with cookielib, but remember the problem also with other imports
(e.g. urllib2 etc.).
And again very often in all these cases where I
