I decided to use mttkinter in my project, but I have problem. I usually import tkinter like this:
from tkinter import *
root=Tk()
And I tried mttkinter like this import:
from mttkinter import *
root=Tk()
After this, I saw global name 'Tk' is not defined.
What can I do with it?
I know this is a old question, but I had the same problem and found a solution.
As stated in the comments you're probably using Python 3.x. since you use "tkinter" all in lower case.
If you check the example from the mtTkinter github.
You'll see that the example checks for the Python version installed and imports either "Tkinter" or "tkinter" before importing mtTkinter (I would assume, to make sure you have access to everything in tkinter even if mtTkinter is not up to date).
For your case (as for mine), your imports should be:
from tkinter import *
from mttkinter import mtTkinter
root = Tk()
Note that if we read what's in the code, your import should work, but you'd have to declare root as follows (I tested this import and it works):
from mttkinter import *
root = mtTkinter.Tk()
Again, I know this question is old, but the answer might be useful for someone else.
Cheers.
Related
I have been trying to understand how to properly call a function from inside a subpackage in python. I wanted to be able to call the function the way I call, for example, function isfile from os package, with os.path.isfile(). I made a test package with a structure like this:
sandbox/
-- __init__.py
-- acid.py
-- pack1/
-- __init__.py
-- fly/
-- __init__.py
-- plane.py
-- by/
-- pack2/
There are only two modules there, acid.py and plane.py. Both of them contain just a function, e.g. plane.py is
"""plane module"""
def plane(x):
x=x+4
return x
To use the function in my test.py code, I put
import pack1
in sandbox/__init__.py
import fly
in sandbox/pack1/__init__.py, and
from plane import plane
in sandbox/pack1/fly/__init__.py
The test code was then:
import sandbox
print sandbox.pack1.fly.plane(3)
Is this the right way to import a function from a subpackage, or I'm misunderstanding things?
What you did certainly works, although there are several worthwhile changes to make.
First, a note about importing from packages: importing a module is semantically distinct from accessing something in a module, even though from xml import sax and from datetime import date are syntactically equivalent. It's impossible to import only part of a module, so that
import datetime
datetime.date.today() # OK: date is a class
is guaranteed to work. However, it is possible to import a package but not the modules it contains. This is a good thing for efficiency, but it does mean that
import xml
xml.sax.parse(...) # AttributeError: 'module' object has no attribute 'sax'
is an error. Unfortunately, such errors often go uncaught because some other code has already imported sax, making it available to any other code that imports xml. (The word "from" in from xml import sax is referring to the complete package on disk, not the module object xml — on which it stores the new module as an attribute!)
As an aside, note that your example of os.path is an abberation: writing
import os
os.path.isfile(...)
works, but only because os.path is not actually a module but an alias for one of posixpath, ntpath, etc. (It then gets installed in sys.modules to allow import os.path as if it were a normal module.)
As such, for a package there is a set of public modules that the user must be aware of (because they must be imported by name to be available); the rest are internal modules that the package loads itself when necessary. If a package contains no public modules, it is irrelevant to the user that it is a package (for example, importlib with its one public function is actually implemented as a package for forward compatibility with Python 3).
Now for the suggestions:
Implicit relative imports are deprecated: write from . import pack1 instead of just import pack1 in sandbox/__init__.py, for instance.
The from plane import plane (or from .plane import plane, following the above point) is problematic because it overwrites the reference to the module plane.py with a reference to the function. Instead:
Define the user-visible entry points (like plane()) directly in their package's __init__.py, importing internal functions from private modules as needed, or
Rename the module (to plane_module.py or so) to avoid the collision.
However, it's not generally a good idea to have a package automatically import its public modules anyway: it forces the client to pay for loading unused parts of the package, and it blurs the distinction between public modules and simple nested names. Instead, write client code like
import sandbox.pack1.fly
print sandbox.pack1.fly.plane(3) # the same line you had
or
from sandbox.pack1 import fly
print fly.plane(3)
if you want to avoid repeating sandbox.pack1.
It is often suggested that __init__.py be entirely empty, and in Python 3.3 it became possible to define packages without any __init__.py at all (which by necessity "makes it empty"). This policy does more than the "no automatic import" suggestion in that it precludes loading things from private modules (like plane).
There are sometimes good reasons to have a non-empty __init__.py; for example, it allows reorganzing an existing module into a package without breaking its clients. I personally see no reason to especially restrict its contents; for further discussion see What is __init__.py for?.
The init.py file makes a folder as a package so that you can import it to python prompt. If you just want to call the function "plane" from your file plane.py, add the absolute path of plane.py file to your PYTHONPATH and call the funtion as shown below.
>>> import sys
>>> sys.path.append("D:\\sandbox\\pack1\\fly")
>>> import plane
>>> print plane.__doc__
plane module
>>> print plane.plane(3)
7
If you want all the packages under "sandbox" folder to be used in your script just add the absolute path of "sandbox" folder to your PYTHONPATH and call the funtion as shown below.
>>> import sys
>>> sys.path.append("D:\\")
>>> from sandbox.pack1.fly import plane
>>> print plane.plane(3)
7
You can also import the "plane.py" module and call the function "plane" as shown below:
>>> import sys
>>> sys.path.append("D:\\")
>>> import sandbox.pack1.fly.plane
>>> print sandbox.pack1.fly.plane.plane(3)
7
I have a python structure like this:
mymodule/
globalconfig.py # variables to set environment, etc
work.py # has: from mymodule.globalconfig import *
__init__.py
tests/
testspart1/
test_work.py # has: from mymodule.work import *
From inside work.py, all is well and I can access my global config variables and functions.
From inside test_work.py, I cannot access those variables, even if I add a second import,
from mymodule.globalconfig import *
Why is this? I wanted to use the same syntax as used in my modules.
thank you!
I am using py2.7 and, to get nice rspec-style outputs and verbose diffs,
pytest --spec -vv
Ref;
1.This answer reminded me I could use another format of import. If there are no other answers I will post my workaround. how to share a variable across modules for all tests in py.test
The import syntax that worked for me was directly importing the nested python file in addition to importing the file under test.
from mymodule.work import *
import mymodule.globalconfig as myconfigs
I assume it's a name clash or import circularity issue, but I could not figure out what the problem was. It took me a while so I wanted to be sure to post the solution for future me and others.
I have a few defined apps in my Django project, each with their own sub-directory (created with startapp)
In the views.py of app1 I have an import to a model from app2
from app2.models import MyModel
This worked in Django 1.6.x. In version 1.9 I get:
Could not resolve variable
sometimes on MyModel, sometimes on the filter(..) method, or on both.
If I change the import to
from app2.models import * ##UnusedWildImport
then everything works just fine.
Has anything changed in 1.9.x (or before) that requires a different mode of importing models external to the app?
I think I can rule our circular import problems as this would have failed in 1.6...
Edit: Based on the comments I started wondering whether this might be a PyDev problem.
I tried:
Removing and re-adding Python to PyDev - it did not help
This https://stackoverflow.com/a/8534599/5958359 - removing the myproject/src folder from PYTHONPATH worked ... with a caveat.
The error did not appear when I completely removed the import statement, so this is not a good solution
This is a PyDev error.
Searches haven't yielded an adequate solution - most simply explain how to disable the error - so I will not link to any solution here.
My workaround, as much as I don't like from xxx import * seems like the best temporary solution.
I'm reading Two Scoops Django Best Practices to make my coding style improve. I'm in relative imports and here is the sample code to make it reusable.
Old Way:
from cones.foo import bar
New way:
from .foo import bar
The code above is for cones app, what if I call the other model in other app? Do I have to put like this:
from .foo import bar
from .other import sample
OR
from .foo import bar
from test.other import sample
What is the correct way?
I usually use imports like this only for one reason
from .foo import bar
from .other import sample
The reason being
If Tomorrow, my module name changes from say 'test' to 'mytest' then the code does not require a refactoring. The code works without breaking.
Update
All imports starting with a '.' dot, only works within that package.
Cross package imports need require the whole path.
If test is another app,
from .other import sample
wont work.
Update:
You can only use relative imports when you're importing from the same app.
Inside test app
from .other import sample
will work. But you'll still need the complete form
from cones.foo import bar
if you import method defined in foo from test app.
So answering your question the second way is the correct way.
I get an error when attempting to import the java.util.regex (specifically added the line to figure out that the error is in the import as I previously only had import java.util.*).
find_glycopeps.java:5: cannot find symbol
symbol : class regex
location: package java.util
import java.util.regex; // Should be redundant...
<some more messages about not recognising Pattern and Matcher, which are classes of the regex package>
As far as I am aware, the regex is a 'core' library. I am assuming that since import java.io.* works that the native method of keeping track of where libraries are should be working so I am quite puzzled how this has occured.
PS: I have to note that I have tested some java compilers over the weekend to find 1 that I like and re-installed a 'clean' openjdk-6 this morning, this is probably where the problems originate from but not sure how to proceed.
Cheers
EDIT (SOLVED): .. I will definitely go hide in shame now, thank you all for pointing out the truly silly mistake
.
Your import is defined wrong.
You'll either need to provide explicit imports of each class, as so:
import java.util.regex.Matcher;
import java.util.regex.Pattern;
Or do
import java.util.regex.*;
You're trying to import a package, you need the * meta-character for that.
If you read the message the compiler gives you, it says it can't find Class regex.
You can't import a package. You import a class, or all classes in a package:
import java.util.regex.*;
Packages are organized in a tree, but import is not recursive. Importing java.util.* only imports classes in java.util, but not classes from sub-packages.
You need to write either:
import java.util.regex.Matcher;
import java.util.regex.Pattern;
or else:
import java.util.regex.*;
You can't just import java.util.regex, without the asterisk, since that's a package; it would be like importing java.io.