This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Maciej Gol
Recipients Maciej Gol, brett.cannon, eric.snow, ethan.furman, lars.gustaebel, ncoghlan, serhiy.storchaka
Date 2020-01-24.13:33:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1579872823.18.0.663006882195.issue39430@roundup.psfhosted.org>
In-reply-to
Content
> PR 18161 fixes race condition by using "from ... import ..."
> which waits until the module be completely initialized if the specified
> names are not set.

Correct me if I'm wrong, but I think the behavior of 'import lzma' in
this case (vulnerable to race conditions) is not as intended? Shouldn't we also fix
the 'import' statement itself?

In general, I understand that due to how dynamic Python is, it might not be
possible to load every single name at import time using `import` and using
`from x import y` brings more determinism (because we have a safeguard now).

But, looking at the stacktrace from ipython the problem lies in a sequence of
import statements, not dynamic python coding. Shouldn't the importing mechanism
be more deterministic in such case? For sure, it should not return an empty module
(this is the case when race condition occurs).

I think a race condition caused by simply using `import` statements
(not `from x import y`) is a big caveat in the statement itself and how python
imports work.

Haven't checked if the cause is isolated to how tarfile works, or works in general, though :-(
History
Date User Action Args
2020-01-24 13:33:43Maciej Golsetrecipients: + Maciej Gol, brett.cannon, ncoghlan, lars.gustaebel, ethan.furman, eric.snow, serhiy.storchaka
2020-01-24 13:33:43Maciej Golsetmessageid: <1579872823.18.0.663006882195.issue39430@roundup.psfhosted.org>
2020-01-24 13:33:43Maciej Gollinkissue39430 messages
2020-01-24 13:33:43Maciej Golcreate