Is there a conflict of libraries here?
Cameron Simpson
cs at cskk.id.au
Sun Nov 8 04:04:43 EST 2020
On 07Nov2020 22:57, Steve <Gronicus at SGA.Ninja> 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 <cs at cskk.id.au>
More information about the Python-list
mailing list