Is there a conflict of libraries here?

[SMOA BLX]

ha! ha! 2 empowering___








we make it. 








______________



+44 1635 887711     On Sunday, November 8, 2020, 01:06:03 a.m. PST, Cameron Simpson <cs at cskk.id.au> wrote:  
 
 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>
-- 
https://mail.python.org/mailman/listinfo/python-list