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 belopolsky
Recipients Arfrever, belopolsky, jcea, khenriksson, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall
Date 2011-06-07.18:54:23
SpamBayes Score 5.965981e-09
Marked as misclassified No
Message-id <>
In-reply-to <>
On Fri, Jun 3, 2011 at 6:52 PM, Martin v. Löwis <> wrote:
>> One reason is the desire to avoid loading Python module from a
>> C-module.
> This desire is indeed no guidance for Python development; the opposite
> is the case.

Can you elaborate on this?  I did notice the current trend of mixing
software layers and welcoming circular dependencies in Python stdlib,
but I am not sure this is a good thing.  In the good old times imports
inside functions where frowned upon.  (And for many good reasons.)
Imports from inside C functions seem to be even worse.  Tricks like
this greatly reduce understandability of the code.  The import
statements at the top of the module tell a great deal about what the
module can and cannot do.  When modules can be imported at will as a
side-effect of innocuous looking functions (time.strptime is my
personal pet peeve), analysis of the programs becomes much more

>  The only exception may be bootstrapping issues, which I
> claim are irrelevant in this case.

It is hard to tell without attempting an implementation, but my
intuition is exactly the opposite.  I believe parts of the import
mechanism have been implemented in Python and it seems to me that
os.stat() may need to be available before decimal can be imported.
Date User Action Args
2011-06-07 18:54:25belopolskysetrecipients: + belopolsky, loewis, jcea, mark.dickinson, lars.gustaebel, nadeem.vawda, Arfrever, r.david.murray, rosslagerwall, khenriksson
2011-06-07 18:54:24belopolskylinkissue11457 messages
2011-06-07 18:54:23belopolskycreate