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__().
Have you not heard that "sugar is the new smoking"? We're being
encouraged to cut-back or giving it up completely...
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 )
However, when the power and/or dynamic possibilities of the underlying
code-construct is/are required...
> 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.
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?
>> I am confuzzed.
>
> It's a common condition.
There are three components:
1 From the Greek: "con" meaning 'against' or 'unable'.
2 From tech-jargon (and the Australian habit of shortening every word in
the English language): "fuzz" is the contraction of two highly-technical
terms, famously applied in intro courses and by naive job-interviewers.
3 From English: the suffix "ed" meaning past tense.
Thus, (smirking!) "confuzzed" is the psychological term for people who
have never been able to bend their minds around the "fizz-buzz" coding
challenge.
PS am running for cover before @Chris reads this...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
