why sqrt is not a built-in function?

[Michael F. Stemper]

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
>>> <mstemper at gmail.com> wrote:
>>>> On 15/01/2021 15.26, Stefan Ram wrote:
>>>>> "Michael F. Stemper" <mstemper at 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?