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 -
regarding the examples import
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 statement can
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 really mean the
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 cookielib ?
Do you really
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
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
