why sqrt is not a built-in function?

[Denys Contant]

I don't understand why sqrt is not a built-in function.
Why do we have to first import the function from the math module?
I use it ALL THE TIME!

That felt good. Thank you.

[jak]

>>> val=16
>>> exp=2
>>> val ** (1/exp)
4.0
>>>

[Skip Montanaro]

> I don't understand why sqrt is not a built-in function.
> Why do we have to first import the function from the math module?
> I use it ALL THE TIME!

For one, it's specific to numeric types. You might use it all the
time, but I (for example) almost never need to use it, or to import
the math module for my Python work/play. OTOH, I use stuff from the
sys and csv modules (and lately, pandas) all the time. I import those
modules when necessary. If you don't need them, I suspect you might
grumble that they are useless for you. Requiring explicit module
import gives programmers more control over the content of their module
namespaces if the builtins don't include the kitchen sink.

If you skim the output of

import builtins
dir(builtins)

you should see that the two largest classes of builtin identifiers are
exceptions (ZeroDivisionError, etc) and types (list, set, etc). Other
classes include singleton constants (True, False, None) and general
sequence operations (useful for loop control - reversed, iter,
zip...). math.sqrt doesn't fit into those object classes. The
remainder are a mixture of things, but generally aren't quite as
special purpose as that. Granted, there are a couple which might be
better left out (IMO), like round and pow, but I suspect their
presence might simply be more a matter of them being present since
Python's earliest days and reflect a tendency later to avoid
gratuitous breakage of existing code.

Finally, should have never considered it, I think you might want to
study the output of

import this

Think on the second and last lines in particular.

Skip

[Alan Gauld]

On 14/01/2021 17:44, Denys Contant wrote:
> I don't understand why sqrt is not a built-in function.
> Why do we have to first import the function from the math module?
> I use it ALL THE TIME!

because pow() is a builtin function and

root = pow(x,0.5)

is the same as

root = math.sqrt(x)

As is

root = x ** 0.5

which is also builtin.

My question is: why do we even have a sqrt() in the
math module given that pow() and ** are already there?

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

[Ethan Furman]

On 1/14/21 9:44 AM, Denys Contant wrote:

> I don't understand why sqrt is not a built-in function.
> Why do we have to first import the function from the math module?
> I use it ALL THE TIME!

And thousands, tens of thousands, and maybe hundreds of thousands don't.

> That felt good. Thank you.

Any time. ;-)

--
~Ethan~

[2QdxY4Rz...@potatochowder.com]

On 2021-01-14 at 17:54:55 +0000,

Alan Gauld via Python-list <pytho...@python.org> wrote:

> My question is: why do we even have a sqrt() in the
> math module given that pow() and ** are already there?

Probably because the standard C math library has such a function, and
Python's math module is (or at least was) supposed be a thin wrapper
around that library.

For completeness, C doesn't have a exponentiation operator.

[Chris Angelico]

Also, the math module works specifically with floats. Sometimes that's
what you want, other times it's not.

>>> pow(-2, 0.5)
(8.659560562354934e-17+1.4142135623730951j)
>>> (-2)**0.5
(8.659560562354934e-17+1.4142135623730951j)
>>> from math import sqrt; sqrt(-2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> from cmath import sqrt; sqrt(-2)
1.4142135623730951j

ChrisA

[Eli the Bearded]

In comp.lang.python, Skip Montanaro <skip.mo...@gmail.com> wrote:
> Finally, should have never considered it, I think you might want to
> study the output of
>
> import this
>
> Think on the second and last lines in particular.

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

"There should be one-- and preferably only one --obvious way to do it."

Meanwhile, Alan Gauld pointed out:

AG> because pow() is a builtin function and
AG> root = pow(x,0.5)
AG> is the same as
AG> root = math.sqrt(x)

Plus the ** operation ("root = x ** 0.5"), that's now three ways.

Elijah
------
python user, not python advocate

[Chris Angelico]

They're not the same. The math module is the one obvious way to do
things that specifically involve floating point numbers and nothing
else.

ChrisA

[Ethan Furman]

On 1/14/21 11:06 AM, Eli the Bearded wrote:

> "There should be one-- and preferably only one --obvious way to do it."
>
> Meanwhile, Alan Gauld pointed out:
>
> AG> because pow() is a builtin function and
> AG> root = pow(x,0.5)
> AG> is the same as
> AG> root = math.sqrt(x)
>
> Plus the ** operation ("root = x ** 0.5"), that's now three ways.

Yes, but which of those is obvious?

--
~Ethan~

[Avi Gross]

Ethan, if it is not obvious, then should we add the following functions just
in case?

cube_root()
fourth_root()
nth(root)
two_thirds_root()
e_th_root()
pi_th_root()
x_over_y_root()

And so on.

It is true that square roots are probably more commonly taken than many
others above (I have never taken the pi_th root but you never know) and you
can make a fourth root by taking the square root twice. There is nothing
wrong with creating a convenience function but it needs to stop somewhere.
The purpose of modules or packages and other add-ons is to supplement the
base language that is loaded whether you want it or not. Some have argued to
remove many current things from the base that THEY never use (or compiled
their own such version) to make it smaller and faster.

Given that, you can either import the sqrt function or make your own that
just turns around and uses one of the methods that is built-in. But if you
use all kinds of things regularly, consider importing them all at once by
having your own module with some name that imports all of them and importing
that and waiting as they all load.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=veriz...@python.org> On
Behalf Of Ethan Furman
Sent: Thursday, January 14, 2021 2:36 PM
To: pytho...@python.org
Subject: Re: why sqrt is not a built-in function?

On 1/14/21 11:06 AM, Eli the Bearded wrote:

> "There should be one-- and preferably only one --obvious way to do it."
>
> Meanwhile, Alan Gauld pointed out:
>
> AG> because pow() is a builtin function and
> AG> root = pow(x,0.5)
> AG> is the same as
> AG> root = math.sqrt(x)
>
> Plus the ** operation ("root = x ** 0.5"), that's now three ways.

Yes, but which of those is obvious?

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

[Eli the Bearded]

In comp.lang.python, Ethan Furman <et...@stoneleaf.us> wrote:
> On 1/14/21 11:06 AM, Eli the Bearded wrote:
>> "There should be one-- and preferably only one --obvious way to do it."

>> Plus the ** operation ("root = x ** 0.5"), that's now three ways.
> Yes, but which of those is obvious?

If it's up to me, the ** one.

Elijah
------
using a syntax with "^" instead of "**" would be okay, too

[Greg Ewing]

Aother thing to consider is that math.sqrt is not the only
sqrt function in Python. There is also one in cmath, and
in the wider ecosystem, another one in numpy. Being explicit
about which one you're using is a good thing.

Concerning exponentiation, it can be used to achieve the same
thing as sqrt, but the sqrt function probably uses a more
efficient algorithm.

Also, exponentiation assumes you're okay with getting a
complex result:

>>> (-27)**0.5
(3.181725716174721e-16+5.196152422706632j)

So it's not quite the same thing as math.sqrt().

--
Greg

[Rob Cliffe]

On 14/01/2021 17:44, Denys Contant wrote:

> I don't understand why sqrt is not a built-in function.
> Why do we have to first import the function from the math module?
> I use it ALL THE TIME!

I agree that, especially if you have experience in other languages, this
feels odd, and I have some sympathy for you.  I am not sure that I can
give you a 100% satisfactory answer.
But:
    if the math module should be automatically imported, how many other
modules that _somebody_ uses "all the time" should also be automatically
be imported?  Python gives you a light-weight framework (fast to load a
program) with the option to plug in whichever batteries you need, and
it's not so terrible to remember to write "import math" or similar,
especially after the first time.

>
> That felt good. Thank you.

Although I hope you have other ways of venting your frustration than
shouting at newsgroups.  Perhaps juggling balls?
Best wishes
Rob Cliffe

[Michael F. Stemper]

On 14/01/2021 13.00, Rob Cliffe wrote:
> On 14/01/2021 17:44, Denys Contant wrote:

>> I don't understand why sqrt is not a built-in function.
>> Why do we have to first import the function from the math module?
>> I use it ALL THE TIME!
> I agree that, especially if you have experience in other languages, this
> feels odd, and I have some sympathy for you.

I cut my teeth on FORTRAN, which has SQRT() as part of the
language. At least 3, 4, and 5 did; I never used later versions.

Here's the status of the square root function in various languages,
in the order that I encountered them:

FORTRAN Part of the language
Pascal Part of the language
SNOBOL Part of the language
c Need to #include <math.h>
clisp Part of the language
EcmaScript Part of the language
python Need to import from math
Java Need to import from java.math

The four that appear to be in the most use currently are c,
EcmaScript, python, and Java. Of these, only EcmaScript has
Math.sqrt() as part of the language, and that could be partly
due to the fact that the language doesn't have any concept of
"import" or "include".



--
Michael F. Stemper
This email is to be read by its intended recipient only. Any other party
reading is required by the EULA to send me $500.00.

[Chris Angelico]

On Sat, Jan 16, 2021 at 6:21 AM Michael F. Stemper <mste...@gmail.com> wrote:
> Here's the status of the square root function in various languages,
> in the order that I encountered them:
>
> FORTRAN Part of the language
> Pascal Part of the language
> SNOBOL Part of the language
> c Need to #include <math.h>
> clisp Part of the language
> EcmaScript Part of the language
> python Need to import from math
> Java Need to import from java.math
>
> The four that appear to be in the most use currently are c,
> EcmaScript, python, and Java. Of these, only EcmaScript has
> Math.sqrt() as part of the language, and that could be partly
> due to the fact that the language doesn't have any concept of
> "import" or "include".
>

Cool. Now tell me: Of all the languages that have a built-in global
name SQRT (which does not include ECMAScript, and for the record, ES
does have imports), how many of them have a built-in or syntax for
dictionaries/mappings? I would put it to you that the ability to look
up something by name in a tree, hashtable, or equivalent, is *at
least* as useful as the ability to calculate a square root. Python
gives you both (since you can raise something to the 0.5th power),
JavaScript in a web browser gives you both, C gives you neither (you
have to #include), and you can fill in the rest yourself.

Languages differ. I don't see why it's so important to focus on just
one thing - and to complain that, even though it's in the standard
library, you have to use an import command to get it.

ChrisA

[Chris Green]

Michael F. Stemper <mste...@gmail.com> wrote:

> On 14/01/2021 13.00, Rob Cliffe wrote:
> > On 14/01/2021 17:44, Denys Contant wrote:
>
> >> I don't understand why sqrt is not a built-in function.
> >> Why do we have to first import the function from the math module?
> >> I use it ALL THE TIME!
> > I agree that, especially if you have experience in other languages, this
> > feels odd, and I have some sympathy for you.
>
> I cut my teeth on FORTRAN, which has SQRT() as part of the
> language. At least 3, 4, and 5 did; I never used later versions.
>

Surely III, IV and V. I was definitely Fortran IV

--
Chris Green
·

[Michael F. Stemper]

I think that the listings for my cross-compiles for the Cyber 1700
actually said "FORTRAN 3" at the top of each page, but that was over
three decades back, so it's a little hazy. There weren't any standards
for it anyway.

You're spot-on for FORTRAN IV.

A quick check of wikipedia shows that the last one was better referred
to as FORTRAN 77, but I think that the NOS command to invoke the
compiler was FTN5.

--
Michael F. Stemper
Galatians 3:28

[Michael F. Stemper]

On 15/01/2021 14.02, Chris Angelico wrote:
> On Sat, Jan 16, 2021 at 6:21 AM Michael F. Stemper <mste...@gmail.com> wrote:
>> Here's the status of the square root function in various languages,
>> in the order that I encountered them:
>>
>> FORTRAN Part of the language
>> Pascal Part of the language
>> SNOBOL Part of the language
>> c Need to #include <math.h>
>> clisp Part of the language
>> EcmaScript Part of the language
>> python Need to import from math
>> Java Need to import from java.math
>>
>> The four that appear to be in the most use currently are c,
>> EcmaScript, python, and Java. Of these, only EcmaScript has
>> Math.sqrt() as part of the language, and that could be partly
>> due to the fact that the language doesn't have any concept of
>> "import" or "include".
>>
>
> Cool. Now tell me: Of all the languages that have a built-in global
> name SQRT (which does not include ECMAScript,

I wasn't looking at how the various languages spell it, I was just looking
at the fact that it could be used directly. Since ECMAScript has a
function Math.sqrt(), I counted it as being a direct part of the
language.

> and for the record, ES
> does have imports),

I stand corrected. So I could say something like "import Math.*" and
then use "sqrt()" directly?

> how many of them have a built-in or syntax for
> dictionaries/mappings?

Beats me. That wasn't what the OP was complaining about. I just did this
little ad-hoc survey to show that more modern languages don't have an
"inherent" square root function, so python's hardly unique.

> I would put it to you that the ability to look
> up something by name in a tree, hashtable, or equivalent, is *at
> least* as useful as the ability to calculate a square root.

I don't think that I've used the square root function since I took a
course in geometry in the fall of 2019, so I have no grounds to dispute.

> Languages differ. I don't see why it's so important to focus on just
> one thing - and to complain that, even though it's in the standard
> library, you have to use an import command to get it.

You should probably direct this to the person who complained rather than
the person who showed that the complaint wasn't really consistent with
modern language direction, while python's handling of the square root
function is consistent.

[Chris Angelico]

On Sat, Jan 16, 2021 at 7:45 AM Michael F. Stemper <mste...@gmail.com> wrote:
> > Languages differ. I don't see why it's so important to focus on just
> > one thing - and to complain that, even though it's in the standard
> > library, you have to use an import command to get it.
>
> You should probably direct this to the person who complained rather than
> the person who showed that the complaint wasn't really consistent with
> modern language direction, while python's handling of the square root
> function is consistent.
>

Sorry, you're right, it looked like I was focusing on you there. Your
post was a convenient one to pick up on, since it had some data -
that's all :) My point about complaining was aimed at the OP, who
started this thread with a rant on the basis of having to "import
math". No offense meant to anyone, least of all you.

ChrisA

[Michael F. Stemper]

On 15/01/2021 14.01, Stefan Ram wrote:

> "Michael F. Stemper" <mste...@gmail.com> writes:

>> Of these, only EcmaScript has
>> Math.sqrt() as part of the language, and that could be partly
>> due to the fact that the language doesn't have any concept of
>> "import" or "include".
>

> You do not need to use the import statement in Python,
> but can also use the expression
>
> __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.

I hope that it satisfies the OP.

--
Michael F. Stemper
I feel more like I do now than I did when I came in.

[Chris Angelico]

On Sat, Jan 16, 2021 at 8:16 AM Michael F. Stemper <mste...@gmail.com> wrote:
>
> On 15/01/2021 14.01, Stefan Ram wrote:
> > "Michael F. Stemper" <mste...@gmail.com> writes:
>
> >> Of these, only EcmaScript has
> >> Math.sqrt() as part of the language, and that could be partly
> >> due to the fact that the language doesn't have any concept of
> >> "import" or "include".
> >
> > You do not need to use the import statement in Python,
> > but can also use the expression
> >
> > __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.
>

Hehe, it's really nothing to do with the Zen; it's playing around with
internals, so you get whatever you get.

I recommend option #2. It is incredibly good fun. For added bonus
obscurity, don't import a module directly; import it from some
unrelated module, such as "from ast import sys" or "from base64 import
re".

ChrisA

[Michael F. Stemper]

On 15/01/2021 15.26, Stefan Ram wrote:
> "Michael F. Stemper" <mste...@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.

This statement led inevitably to:

>>> sqrt = __import__("math").sqrt
>>> sqrt(4)
2.0
>>>

I don't know why; it just did.

> "__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.)

That's much too mature. Es ist Feierabend!

--
Michael F. Stemper
2 Chronicles 19:7

[Chris Angelico]

On Sat, Jan 16, 2021 at 8:56 AM Michael F. Stemper <mste...@gmail.com> wrote:
>
> On 15/01/2021 15.26, Stefan Ram wrote:
> > "Michael F. Stemper" <mste...@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?

I am confuzzed.

ChrisA

[dn]

On 16/01/2021 10.49, Michael F. Stemper wrote:
...

> Es ist Feierabend


You had me there for a moment, because spotting a 'double meaning"
(actually triple) my mind succumbing to dissonance, refused to translate
(into English), instead latching onto the last two syllables:-

At one time, tech-jargon included the term "abend". It meant "abnormal
end", and was a more palatable term (to someone) for "crash" - a bit
like the airline which talked of "non-operational termination" instead
of using the same (unpalatable) word!


Yes, not only might it have been literally the end of (your) day. This
conversation does seem to have reached the point of reductio ad absurdum!
--
Regards =dn

[Eli the Bearded]

In comp.lang.python, Chris Angelico <ros...@gmail.com> wrote:
> Michael F. Stemper <mste...@gmail.com> wrote:
>> 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.

> I recommend option #2. It is incredibly good fun. For added bonus
> obscurity, don't import a module directly; import it from some
> unrelated module, such as "from ast import sys" or "from base64 import
> re".

Is there an Obfuscated Python contest, like there is with C? I know the
C ones are often quite interesting, like the 2020 entry that implements
tic-tac-toe in "Turing complete" sub-language of printf() format strings.
(Carlini, http://www.ioccc.org/years.html#2020 )

Elijah
------
with the complexity of fitting the 200k format into a 2k source file

[Chris Angelico]

No there isn't, but similar abominations have showed up in security
testing. Attempts to (a) create a sandboxed Python, and then (b) break
out of said sandbox, have produced some fairly terrifying (and quite
awesome) demonstrations.

ChrisA

[Michael F. Stemper]

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).

> I am confuzzed.

It's a common condition.


--
Michael F. Stemper
Life's too important to take seriously.

[dn]

On 15/01/2021 06.44, Denys Contant wrote:
> I don't understand why sqrt is not a built-in function.
> Why do we have to first import the function from the math module?
> I use it ALL THE TIME!
>

> That felt good. Thank you.

Are you 'venting', or do you have a specific frustration-induced question?


Much of my training work centers on HTML5. An issue which you will have
experienced as a user (if not an HTML5 coder), is how long it takes for
certain pages to load or to respond to a 'click'.

We talk of the "weight" of the page. Sadly, in a bid to "capture
eye-balls" and/or to prove how much smarter 'I' am (than any other
web-author/JavaScript-er), there are (far too) many reasons why
web-pages are adorned and accompanied by myriad scripts (and likely,
whole libraries/frameworks), and thus become slow (or 'heavy').


What does this have to do with Python?

As an "interpreted language" Python will (tend to) execute slowly when
compared with a "compiled language".
(ignoring 'shades and grades', and purity of definition)

Another form of delay/slow-ness, is how long it takes a program(me) to
start (in the eyes of the user). Another form of 'weight', and component
of start-up time is how much storage is required to hold the code
(excluding any data).


An advantage of Python is that it has a small 'core'. Mark Summerfield
(author) refers to it as "Python's beautiful heart". The minimised core
(or should that be "optimised"?) is fast to load, and occupies minimal
resource.

As a consequence, you and I may well grumble that we have to import the
math library - every time we code some non-trivial calculation. However,
in doing-so we (should) compute a conscious cost-benefit analysis:
knowing that to include the library will incur a resource-cost, but that
its facilities will improve the accuracy and/or efficiency (eg speed) of
our work. OK, so sign me up!

Contrarily, people who don't 'work with numbers', eg other threads
'here' discussing character manipulation; don't experience any longer
waiting-time or 'suffer' extra resource-cost, due to loading the math
library, from which they/their code will receive no benefit at all!


Thus, one of the philosophies of Python I keenly appreciate (that makes
me "[feel] good", to borrow your words), is that not only are "batteries
included", but I don't have to carry-around any 'spare batteries' that I
don't actually need right now!

(even more applicable when using MicroPython, etc)
--
Regards =dn

[Chris Angelico]

Sure, and that's how I'd normally code too. But if I give you a
snippet like this:

from collections import Counter
ltr_weights = ''.join(Counter(text) & Counter(string.ascii_letters)).elements())

then it's absolutely fine to keep the import next to the code. There's
no need to go to the hassle of splitting the snippet; if you want to,
you can, but the snippet is still a single thing.

The __import__ function doesn't add anything here.

ChrisA

[dn]

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

[Chris Angelico]

On Sat, Jan 16, 2021 at 10:18 AM dn via Python-list
<pytho...@python.org> wrote:
> >> 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...

Good idea, you never know what I might have been drinking, and
therefore what materials could have been sprayed across the screen
when I read that! :D

ChrisA

[Greg Ewing]

On 16/01/21 10:14 am, Michael F. Stemper wrote:
> I had no idea that syntax existed, and find it completely at odds
> with The Zen of Python.

It's not an *obvious* way, so there's no Zen conflict.

As for why it exists, it's part of the mechanism that implements
imports -- 'import' statements get compiled into a call to
__import__.

It also provides a way of importing something specifed by a
string at runtime, so it can be useful.

--
Greg

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