Re: [Python-Dev] Deadlock by a second import in a thread
2007/10/19, Christian Heimes <[EMAIL PROTECTED]>:
> I know a possible solution. You could write a patch that moves the
> imports in C code to the module init function and stores the modules in
> a global static variable.
I thought about this. It even will have the good side efect of not
shooting the whole "import" machinery to see that you already imported
it, every time you do an strptime.
One question: The program makes this:
PyObject *strptime_module = PyImport_ImportModule("_strptime");
...
Py_DECREF(strptime_module);
If I'd import it in the beggining of the file with the following...
static PyObject *strptime_module = PyImport_ImportModule("_strptime");
... I'd never decref it, right?
Thank you!
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deadlock by a second import in a thread
2007/10/20, Nick Coghlan <[EMAIL PROTECTED]>: > bb.py is broken - importing a module should never spawn a new thread as > a side effect (precisely because it will deadlock if the spawned thread > tries to do an import, which can happen in a myriad of ways). Agreed. But if we move the import of the _strptime module to do it once when "time" is imported, we enhance the "least surprise" situation (and has a marginal performance benefit of not trying to import it again every time.strptime() call). And even solves this bug, which does not hurt enaybody, ;) Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python developers are in demand
Guido van Rossum python.org> writes: > I wonder if we should start maintaining a list of Python developers > for hire somewhere on python.org, beyond the existing Jobs page. Is > anyone interested in organizing this? I would be definitely interested in putting my name on such a list. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New chapter "Using Python" in the docs
Hi, as you may have seen in the checkins, I just created a new chapter in the docs called "Using Python." We, the doc team, would like that section to contain, roughly, information how to install Python on different platforms, how to configure it, how to invoke it, what extra things and quirks you should know about, etc. Currently, there are two sections: one about the Python command-line options, newly distilled from the manpage and other sources docs, and the old "Using Python on Mac" document which had been in the HOWTO section since the migration. Now it would of course be nice to have at least two other documents for Unixy platforms and Windows... I don't think this is not written down somewhere, but it isn't in the official docs currently -- so it'd be wonderful if you could help us to collect this information, give it a proper shape and add it to the new chapter. Even links to wiki pages, blog articles etc. can help! Cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deadlock by a second import in a thread
On 10/20/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> 2007/10/19, Christian Heimes <[EMAIL PROTECTED]>:
>
> > I know a possible solution. You could write a patch that moves the
> > imports in C code to the module init function and stores the modules in
> > a global static variable.
>
> I thought about this. It even will have the good side efect of not
> shooting the whole "import" machinery to see that you already imported
> it, every time you do an strptime.
>
> One question: The program makes this:
>
> PyObject *strptime_module = PyImport_ImportModule("_strptime");
> ...
> Py_DECREF(strptime_module);
>
> If I'd import it in the beggining of the file with the following...
>
> static PyObject *strptime_module = PyImport_ImportModule("_strptime");
>
> ... I'd never decref it, right?
Right. Otherwise, if the module is removed from sys.modules then it
will have a refcount of 0 and be collected, leaving your static
variable holding junk memory.
One issue with this approach, though, is that the import is a one-time
thing, and so replacing what is in sys.modules['_strptime'] will not
take affect in the module ever thanks to the caching of the module's
dict.
Granted this is a small issue as normal Python code does not pick up
changes in sys.modules, but it is something to be aware of.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
