Re: Is there a conflict of libraries here?
On 07Nov2020 22:57, Steve wrote: >Ok, the light just went out. >I thought I was getting something, but no... > >I will keep on reading, maybe it will hatch. You're probably overthinking this. I'll address your new example below. First up: numbers are objects, strings are objects, classes are objects, modules are objects. A variable can refer to any of them. So when you do an import you're setting a name to refer to a module, or to refer to something from within a module. Consider this: x = 3 x = 4 What is x? It's 4, because that happened second. An import is just a special form of assignment statement, with an implicit module load behind the scenes. So consider this: import datetime from datetime import datetime Each of these assigns to the name "datetime". The former assigns the module named "datetime". The latter assigns the _class_ named 'datetime" from inside the module. One happens after the other, so after this the name "datetime" refers to the class. Alternatively: import datetime datetime = datetime.datetime "datetime" starts referring to the datetime module. Then we reassign it to the "datetime" class that is inside the module. The effect is the same as the previous pair of lines. It is unfortunate that the "datetime" module contains a "datetime" class. It makes for a lot of confusion. Modern classes start with uppercase letters (entirely by convention), which reduces this issue - you have a better idea of what you're looking at just from the name. It's been mentioned in this thread, but perhaps been as obvious as it could have been: if you need to refer to the module "datetime", and also the class "datetime" from within it, assign them to different variables: import datetime dt = datetime.datetime Now you have "datetime" referring to the module, and "dt" referring to the class. >Maybe a different approach. >What is happening here? >(Should this be a new thread?) No, keep the thread -it is the same discussion and really the same issue. It keeps it all together for us, too. >import tkinter as tk Equivalent to this: import sys tk = sys.modules['tkinter'] >from tkinter import * a = sys.modules['tkinter'].a b = sys.modules['tkinter'].b c = sys.modules['tkinter'].c ... for each name defined in the tkinter module. Try to avoid this incantation - it sucks in a large uncontrolled list of names into your script. Some small scripts do it for simple things where's they're really working against only one module. In most things it is unhelpful. >from tkinter import ttk ttk = sys.modules['tkinter'].ttk All of these 3 things set local variables/names in your script to some value. The "*" import sets a bunch of variables. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Questions about XML processing?
On 2020-11-07 20:03, Dieter Maurer wrote: Hernán De Angelis wrote at 2020-11-6 21:54 +0100: ... However, the hard thing to do here is to get those only when tagC/note/title/string='value'. I was expecting to find a way of specifying a certain construction in square brackets, like [@string='value'] or [@/tagC/note/title/string='value'], as is usual in XML and possible in xml.etree. However this proved difficult (at least for me). So this is the "brute" solution I implemented: You might have a look at `lxml`. It supports XPath (1.0) which is more powerfull in selecting nodes than `etree`. Yes, I am having a look at that. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/6/2020 5:05 PM, Steve wrote: "Right, because the name "datetime" points to the class datetime in the module datetime. A module containing an object with the same name as the module is a real pain, a constant mental papercut. I consider datetime.datetime to be a design mistake*. You are the 2nd person in about a month to post the same resulting code problem. * Either the class should have been 'Datetime', capitalized like classes in modules other that builtins generally should be, or the module should have been given a different name. I personally would always rename the module when imported. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
ha! ha! 2 empowering___ we make it. __ +44 1635 887711 On Sunday, November 8, 2020, 01:06:03 a.m. PST, Cameron Simpson wrote: On 07Nov2020 22:57, Steve wrote: >Ok, the light just went out. >I thought I was getting something, but no... > >I will keep on reading, maybe it will hatch. You're probably overthinking this. I'll address your new example below. First up: numbers are objects, strings are objects, classes are objects, modules are objects. A variable can refer to any of them. So when you do an import you're setting a name to refer to a module, or to refer to something from within a module. Consider this: x = 3 x = 4 What is x? It's 4, because that happened second. An import is just a special form of assignment statement, with an implicit module load behind the scenes. So consider this: import datetime from datetime import datetime Each of these assigns to the name "datetime". The former assigns the module named "datetime". The latter assigns the _class_ named 'datetime" from inside the module. One happens after the other, so after this the name "datetime" refers to the class. Alternatively: import datetime datetime = datetime.datetime "datetime" starts referring to the datetime module. Then we reassign it to the "datetime" class that is inside the module. The effect is the same as the previous pair of lines. It is unfortunate that the "datetime" module contains a "datetime" class. It makes for a lot of confusion. Modern classes start with uppercase letters (entirely by convention), which reduces this issue - you have a better idea of what you're looking at just from the name. It's been mentioned in this thread, but perhaps been as obvious as it could have been: if you need to refer to the module "datetime", and also the class "datetime" from within it, assign them to different variables: import datetime dt = datetime.datetime Now you have "datetime" referring to the module, and "dt" referring to the class. >Maybe a different approach. >What is happening here? >(Should this be a new thread?) No, keep the thread -it is the same discussion and really the same issue. It keeps it all together for us, too. >import tkinter as tk Equivalent to this: import sys tk = sys.modules['tkinter'] >from tkinter import * a = sys.modules['tkinter'].a b = sys.modules['tkinter'].b c = sys.modules['tkinter'].c ... for each name defined in the tkinter module. Try to avoid this incantation - it sucks in a large uncontrolled list of names into your script. Some small scripts do it for simple things where's they're really working against only one module. In most things it is unhelpful. >from tkinter import ttk ttk = sys.modules['tkinter'].ttk All of these 3 things set local variables/names in your script to some value. The "*" import sets a bunch of variables. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy wrote: > > On 11/6/2020 5:05 PM, Steve wrote: > > "Right, because the name "datetime" points to the class datetime in the > > module datetime. > > A module containing an object with the same name as the module is a real > pain, a constant mental papercut. I consider datetime.datetime to be a > design mistake*. You are the 2nd person in about a month to post the > same resulting code problem. > > * Either the class should have been 'Datetime', capitalized like classes > in modules other that builtins generally should be, or the module should > have been given a different name. I personally would always rename the > module when imported. > Yes, it's annoying, but it's only annoying when code on the internet suggests "from datetime import *", which IMO is the real mental papercut. If everything was written assuming "import datetime", there'd be only a very minor confusion. So, my suggestion to anyone who's struggling with datetime is: Don't ever write "from datetime import *" or "from datetime import datetime". Your code may break in the short term, but if it does, it's a solvable break. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/7/20 9:26 PM, Terry Reedy wrote: > On 11/6/2020 5:05 PM, Steve wrote: >> "Right, because the name "datetime" points to the class datetime in the >> module datetime. > > A module containing an object with the same name as the module is a > real pain, a constant mental papercut. I consider datetime.datetime > to be a design mistake*. You are the 2nd person in about a month to > post the same resulting code problem. > > * Either the class should have been 'Datetime', capitalized like > classes in modules other that builtins generally should be, or the > module should have been given a different name. I personally would > always rename the module when imported. > Which says that if you do: import datetime from datetime import datatime as Datatime you get the class in your module as the more modern capitalized name, and avoid the name conflict. It just says that in your code, to use the class you either need to use Datatime or datetime.datetime -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
returning totals in functions of math
Errors say that add takes 1 positional argument but 3 were given? Does this limit how many numbers I can have or do I need other variables? Here is what I have: def add(numbers): total = 1 for x in numbers: total += x return total print(add(1999, -672, 84)) I have a multiply function above it but that was solved and I'm trying to figure everything out for each of the different math functions. Thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
On Sun, 8 Nov 2020 13:50:19 -0500, Quentin Bock wrote: > Errors say that add takes 1 positional argument but 3 were given? Does this > limit how many numbers I can have or do I need other variables? > Here is what I have: > def add(numbers): >total = 1 >for x in numbers: > total += x >return total > print(add(1999, -672, 84)) Your function "add" expects a single argument that is a list of numbers. You're passing it three arguments, each a number. Try add([1999, -672, 84]). -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
answer not correct
*def add(numbers):* * total = 1* * for x in numbers:* * total += 1* * return total* *print(add[1999, -672, 64]))* *the answer I get is 4 but it should be 1,411* -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
On 2020-11-08 at 19:00:34 +, Peter Pearson wrote: > On Sun, 8 Nov 2020 13:50:19 -0500, Quentin Bock wrote: > > Errors say that add takes 1 positional argument but 3 were given? Does this > > limit how many numbers I can have or do I need other variables? > > Here is what I have: > > def add(numbers): > >total = 1 > >for x in numbers: > > total += x > >return total > > print(add(1999, -672, 84)) > > Your function "add" expects a single argument that is a list > of numbers. You're passing it three arguments, each a number. > Try add([1999, -672, 84]). Or change add to accept an arbitrary number of arguments and collect them into a tuple: def add(*numbers): # then the rest of the function as before BTW, why initialize total to 1? -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
Ok, I don't know how to change add to accept an arbitrary number of arguments (I'm pretty new) and as for total = 1 idk but it worked for other versions of this (multiplication), and figured it might work for this one, do you have any tips on what a better number might be for the total to equal? On Sun, 8 Nov 2020 at 14:37, <[email protected]> wrote: > On 2020-11-08 at 19:00:34 +, > Peter Pearson wrote: > > > On Sun, 8 Nov 2020 13:50:19 -0500, Quentin Bock > wrote: > > > Errors say that add takes 1 positional argument but 3 were given? Does > this > > > limit how many numbers I can have or do I need other variables? > > > Here is what I have: > > > def add(numbers): > > >total = 1 > > >for x in numbers: > > > total += x > > >return total > > > print(add(1999, -672, 84)) > > > > Your function "add" expects a single argument that is a list > > of numbers. You're passing it three arguments, each a number. > > Try add([1999, -672, 84]). > > Or change add to accept an arbitrary number of arguments and collect > them into a tuple: > > def add(*numbers): > # then the rest of the function as before > > BTW, why initialize total to 1? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: answer not correct
Hello, First of all, remove the asterisks around the snippet, it makes it so hard to copy and paste your code. My answer is inlined. On Sun, Nov 8, 2020 at 2:28 PM Quentin Bock wrote: > > *def add(numbers):* > * total = 1* If this is your sum, you need to initialize it to zero: total = 0 > * for x in numbers:* > * total += 1* Do you mean total += x? Regards rambius > * return total* > *print(add[1999, -672, 64]))* > > *the answer I get is 4 but it should be 1,411* > -- > https://mail.python.org/mailman/listinfo/python-list -- Tangra Mega Rock: http://www.radiotangra.com -- https://mail.python.org/mailman/listinfo/python-list
Re: answer not correct
On 2020-11-08 19:25, Quentin Bock wrote: *def add(numbers):* * total = 1* * for x in numbers:* * total += 1* * return total* *print(add[1999, -672, 64]))* *the answer I get is 4 but it should be 1,411* 1. You typed "total += 1", which means it's adding 1 each time around the loop. 2. The print line as written above is incorrect. 3. I don't see how can the answer be 1,411! -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
On 09/11/2020 08:47, Quentin Bock wrote: Ok, I don't know how to change add to accept an arbitrary number of arguments (I'm pretty new) and as for total = 1 idk but it worked for other versions of this (multiplication), and figured it might work for this one, do you have any tips on what a better number might be for the total to equal? Fair comment - arguments discussed in previous post - try what has been suggested... The "Law of Identity" is that zero added to anything doesn't change the value, eg 1 + 0 = 1; 1 million + 0 = 1 million... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
Comments interposed:- On 09/11/2020 08:14, [email protected] wrote: On 2020-11-08 at 19:00:34 +, Peter Pearson wrote: On Sun, 8 Nov 2020 13:50:19 -0500, Quentin Bock wrote: Errors say that add takes 1 positional argument but 3 were given? Does this limit how many numbers I can have or do I need other variables? Here is what I have: def add(numbers): total = 1 for x in numbers: total += x return total print(add(1999, -672, 84)) Your function "add" expects a single argument that is a list of numbers. You're passing it three arguments, each a number. Try add([1999, -672, 84]). Minor point ('here'): aren't arguments passed as a tuple? (cf "list") [next point probably more advanced than OP requires] Major 'gotchas' elsewhere: remember the difference between passing an immutable, cf a mutable, argument (tuple cf list)! Also related, functions' name-spaces: >>> my_list = [ 1, 2, 3 ] >>> def function1( any_list ): ... any_list = [ 4, 5, 6 ] ... >>> function1( my_list ) >>> my_list [1, 2, 3] >>> def function2( any_list ): ... any_list.append( [ 4, 5, 6 ] ) ... >>> function2( my_list ) >>> my_list [1, 2, 3, [4, 5, 6]] - neither of which works with tuples... Some refer to such mutable 'flexibility' as a "side-effect" and thus undesirable/to be avoided. Or change add to accept an arbitrary number of arguments and collect them into a tuple: def add(*numbers): # then the rest of the function as before +1 BTW, why initialize total to 1? Because OP copied 'multiply' code, completed earlier? [OP] Once you have this code working, as above, consider refactoring to use sum()... Web.Refs: https://docs.python.org/3/library/functions.html https://riptutorial.com/python/example/28509/mutable-and-immutable-as-arguments -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
On 09/11/2020 09:41, Quentin Bock wrote: Okay, thank you :) I didn't understand about 90% of what you explained lol (sorry) but the sum worked and I have the correct answer. Also, do you know any numbers that could replace 1 in this function as the total? just curious Thanks :) Yes, apologies to you. Some of those points were discussing another response. Its content was quite advanced. Please ignore, as noted. Am assuming that the question about "1" has been answered. OK? Please post* the successful code for both multiply() and add(), then we will be able to help you draw comparisons and/or re-factor (improve the code - or improve the approach) - whether your question is about 'math' or about 'Python'. * best to copy-paste directly from the code-editor. Incidentally, if you would prefer, there is a "Tutor" list where <>> https://mail.python.org/mailman/listinfo/tutor -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: returning totals in functions of math
On Sun, Nov 8, 2020 at 1:51 PM Quentin Bock wrote: > Errors say that add takes 1 positional argument but 3 were given? Does this > limit how many numbers I can have or do I need other variables? > Here is what I have: > def add(numbers): >total = 1 >for x in numbers: > total += x >return total > print(add(1999, -672, 84)) > > I have a multiply function above it but that was solved and I'm trying to > figure everything out for each of the different math functions. > Thank you > -- > https://mail.python.org/mailman/listinfo/python-list By the way, did you know about the `sum` function? It does basically what your add function does, except I think you'd need to pass it an initial value so it knows what type it's adding, or something like that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/8/2020 9:56 AM, Chris Angelico wrote: On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy wrote: A module containing an object with the same name as the module is a real pain, a constant mental papercut. I consider datetime.datetime to be a design mistake*. You are the 2nd person in about a month to post the same resulting code problem. * Either the class should have been 'Datetime', capitalized like classes in modules other that builtins generally should be, or the module should have been given a different name. I personally would always rename the module when imported. Yes, it's annoying, but it's only annoying when code on the internet suggests "from datetime import *", I agree that the latter is annoying, but I disagree about 'only'. Names pointing to two different objects (or people ;-) are ambiguous without additional disambiguation. If I write 'datetime has an off-by-one bug' or 'datetime is great', which datetime do I mean? idlelib once had multiple name.name pairs, such as Debugger.Debugger, and to me, the nuisance of fixing them (as per PEP 434 and subsequent decision by the BDFL-delegate) has now been outweighed by the continuing benefit. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On Mon, Nov 9, 2020 at 3:32 PM Terry Reedy wrote: > > On 11/8/2020 9:56 AM, Chris Angelico wrote: > > On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy wrote: > > >> A module containing an object with the same name as the module is a real > >> pain, a constant mental papercut. I consider datetime.datetime to be a > >> design mistake*. You are the 2nd person in about a month to post the > >> same resulting code problem. > >> > >> * Either the class should have been 'Datetime', capitalized like classes > >> in modules other that builtins generally should be, or the module should > >> have been given a different name. I personally would always rename the > >> module when imported. > >> > > > > Yes, it's annoying, but it's only annoying when code on the internet > > suggests "from datetime import *", > > I agree that the latter is annoying, but I disagree about 'only'. Names > pointing to two different objects (or people ;-) are ambiguous without > additional disambiguation. If I write 'datetime has an off-by-one bug' > or 'datetime is great', which datetime do I mean? Perhaps, but certainly the confusion is far less when the module is always imported as itself, and then the class is "datetime.datetime" which nicely parallels "datetime.date" and "datetime.time". If we could abuse Guido's time machine and have them as "datetime.DateTime" etc, I would definitely be in favour of it. I don't know that it'd be worth actually changing, though, and even adding aliases doesn't really seem worthwhile IMO. > idlelib once had multiple name.name pairs, such as Debugger.Debugger, > and to me, the nuisance of fixing them (as per PEP 434 and subsequent > decision by the BDFL-delegate) has now been outweighed by the continuing > benefit. Yes, but the nuisance of fixing internal idlelib details isn't nearly as strong as renaming a public class :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
