Re: why sqrt is not a built-in function?
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
wrote:
On 15/01/2021 15.26, Stefan Ram wrote:
"Michael F. Stemper" 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
Re: why sqrt is not a built-in function?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 10:18 AM dn via Python-list 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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
>> wrote:
>>>
>>> On 15/01/2021 15.26, Stefan Ram wrote:
"Michael F. Stemper" 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
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 9:47 AM 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 > > wrote: > >> > >> On 15/01/2021 15.26, Stefan Ram wrote: > >>> "Michael F. Stemper" 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 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). 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On 15/01/2021 16.01, Chris Angelico wrote: On Sat, Jan 16, 2021 at 8:56 AM Michael F. Stemper wrote: On 15/01/2021 15.26, Stefan Ram wrote: "Michael F. Stemper" 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 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 9:25 AM Eli the Bearded <*@eli.users.panix.com> wrote: > > In comp.lang.python, Chris Angelico wrote: > > Michael F. Stemper 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 ) > 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
In comp.lang.python, Chris Angelico wrote: > Michael F. Stemper 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 8:56 AM Michael F. Stemper wrote: > > On 15/01/2021 15.26, Stefan Ram wrote: > > "Michael F. Stemper" 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On 15/01/2021 15.26, Stefan Ram wrote:
"Michael F. Stemper" 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
--
https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 8:16 AM Michael F. Stemper wrote: > > On 15/01/2021 14.01, Stefan Ram wrote: > > "Michael F. Stemper" 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On 15/01/2021 14.01, Stefan Ram wrote: "Michael F. Stemper" 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 7:45 AM Michael F. Stemper 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On 15/01/2021 14.02, Chris Angelico wrote: On Sat, Jan 16, 2021 at 6:21 AM Michael F. Stemper wrote: Here's the status of the square root function in various languages, in the order that I encountered them: FORTRANPart of the language Pascal Part of the language SNOBOL Part of the language c Need to #include 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. -- Michael F. Stemper Galatians 3:28 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
Michael F. Stemper 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 · -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On 15/01/2021 14.00, Chris Green wrote: Michael F. Stemper 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 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Sat, Jan 16, 2021 at 6:21 AM Michael F. Stemper wrote: > Here's the status of the square root function in various languages, > in the order that I encountered them: > > FORTRANPart of the language > Pascal Part of the language > SNOBOL Part of the language > c Need to #include > 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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: FORTRANPart of the language Pascal Part of the language SNOBOL Part of the language c Need to #include 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
In comp.lang.python, Ethan Furman 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
--
https://mail.python.org/mailman/listinfo/python-list
RE: why sqrt is not a built-in function?
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 On
Behalf Of Ethan Furman
Sent: Thursday, January 14, 2021 2:36 PM
To: python-list@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
--
https://mail.python.org/mailman/listinfo/python-list
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
Re: why sqrt is not a built-in function?
On Fri, Jan 15, 2021 at 6:11 AM Eli the Bearded <*@eli.users.panix.com> wrote: > > In comp.lang.python, Skip Montanaro 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) 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
In comp.lang.python, Skip Montanaro 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
--
https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On Fri, Jan 15, 2021 at 5:56 AM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2021-01-14 at 17:54:55 +, > Alan Gauld via Python-list 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. 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 "", line 1, in ValueError: math domain error >>> from cmath import sqrt; sqrt(-2) 1.4142135623730951j ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
On 2021-01-14 at 17:54:55 +, Alan Gauld via Python-list 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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~ -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
> 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: why sqrt is not a built-in function?
Il 14/01/2021 18:44, Denys Contant ha scritto: 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. >>> val=16 >>> exp=2 >>> val ** (1/exp) 4.0 >>> -- https://mail.python.org/mailman/listinfo/python-list
why sqrt is not a built-in function?
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. -- https://mail.python.org/mailman/listinfo/python-list
