On 15/01/2021 17.17, dn wrote:
On 16/01/2021 11.40, Michael F. Stemper wrote:
On 15/01/2021 16.01, Chris Angelico wrote:
On Sat, Jan 16, 2021 at 8:56 AM Michael F. Stemper
<mstem...@gmail.com> wrote:
On 15/01/2021 15.26, Stefan Ram wrote:
"Michael F. Stemper" <mstem...@gmail.com> writes:
On 15/01/2021 14.01, Stefan Ram wrote:
__import__( "math" ).sqrt( 4 )
I had no idea that syntax existed, and find it completely at odds
with The Zen of Python. I'm torn between forgetting that I ever saw
it and using it for some evilly-obfuscated code.
When one collects snippets of Python code that are intended
to be inserted into programs, a snippet usually would have
to consist of two parts: One part to be inserted at the top
of the program, into the imports section, and then the actual
snippet.
"__import__" allows to write snippets that can be inserted
as they are without the need to do insertions at two different
places. (Possibly with a tool to later normalize the insertions
to the usual style.)
I'm not sure how that works. In Python, you can just put the imports
where you want them - why would the __import__ function be needed?
import is 'syntactic sugar' for __import__().
And any high-level language is, from a certain point of view, syntactic
sugar for entering the machine-language instructions using the toggle
switches on the front panel. The way that Turing meant for us to do it.
More seriously, it's like creating a class object by
MyClass = type('MyClass', (), {})
whereas it's far easier (for most of us) to use
class MyClass( etc )
As well as far easier to comprehend and maintain.
I have no idea what PEP-8 has to say on the subject. However, my coding
style *generally* puts all of the imports up front, right after the
prologue (program description, revision history, uzw).
This is indeed received-wisdom.
However it does not disallow (yuk: double-negative!) coding an import
statement elsewhere, eg a routine which is only executed during some
invocations, but not others.
Hence the emphasized "generally". For instance, one of my programs has
an option to plot its results. If that option is selected, matplotlib is
imported -- way at the end, after all of the number-crunching.
I think that we're in agreement here.
What you may like to consider about "prolog[ue]s" is whether they belong
'in' the code (plenty of arguments 'for') or within the VCS (plenty of
arguments here too)...
eg1: how easy is it to establish when a particular decision/code-change
was made (more than one week ago)? - particularly if changes were
subsequent made 'on top of' that change?
eg2: is it a good idea to use 'Python constants' to display the
program(me) name and (perhaps) a version number on the
terminal/application window?
Such as "%prog"? Or "sys.argv[0]"? Quite useful for help text and
diagnostic messages, with no need to hard-code the program name
into the program. Which would cause confusion if a user wanted to
rename/alias the program.
--
Michael F. Stemper
What happens if you play John Cage's "4'33" at a slower tempo?
--
https://mail.python.org/mailman/listinfo/python-list
