I am teaching myself python from this site. On Chapter 3, when I typed the code in the given example, I got the following error--
Python 3.2 (r32:88445, Mar 25 2011, 19:28:28)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import turtle
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "turtle.py", line 2, in <module>
wn = turtle.Screen()
AttributeError: 'module' object has no attribute 'Screen'
>>>
Is this something that I need to download and install? I tried looking into docs.python.org, but my nose started to bleed reading all that tech stuff.
Kindly point me in the right direction please? Thank you.
Adam Bernier's answer is probably correct. It looks like you have a file called turtle.py that Python is picking up before the one that came with your Python installation.
To track down these problems:
% python
Python 2.7.1 (r271:86832, Jan 29 2011, 13:30:16)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
[...] # Your ${PYTHONPATH}
>>> import turtle
>>> turtle.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/turtle.pyc' # Should be under your Python installation.
>>>
If you see something like this:
>>> import turtle
>>> turtle.__file__
'turtle.py'
Then you'll want to move turtle.py (and any corresponding turtle.pyc or turtle.pyo files) in your current working directory out of the way.
As per the comments below, you'll find a wealth of information about a module, including its pathname and contents by calling help() upon it. For example:
>>> import turtle
>>> help(turtle)
Rename turtle.py. It is clashing with the imported module of the same name.
I tested that the code from that site works in Python 2.6 (without installing any external packages).
From http://docs.python.org/tutorial/modules.html#the-module-search-path
When a module named spam is imported, the interpreter searches for a file named spam.py in the current directory, and then in the list of directories specified by the environment variable PYTHONPATH.
So the Python interpreter is finding your turtle.py file, but not seeing a Screen class within that file.
Johnsyweb's answer contains several good tips on how to debug this kind of issue. Perhaps the most direct way of determining where on the filesystem an imported module resides is to use repr(module) or simply type the module name at the REPL prompt, e.g.:
>>> turtle
<module 'turtle' from '/usr/lib/python2.6/lib-tk/turtle.pyc'>
Another problem that people may encounter is due to an installation issue on Linux systems. On my Windows machine, 'turtle' was just there and I was able to import turtle with no problem. When I tried to import turtle in Ubuntu, it didn't find the module, so I tried to install it.
When I did sudo pip install turtle, it installed a package 'turtle' which apparently is very different: "Turtle is an HTTP proxy whose purpose is to throttle connections to specific hostnames ...." This 'turtle' most certainly does not have "Screen" or anything related to a little drawing turtle. So I ended up with the same error as the user in the question of module has no attribute 'Screen'.
For Ubuntu, what I needed to do was:
sudo pip uninstall turtle
sudo apt-get install python-tk
Then when I did import turtle, all of the expected modules were found.
Go to the directory where you save your python files. There is a file named turtle.py. Either remove it, or rename it. This will work.
thanks,
Probably not related, but I spent some time tracking down this same error and found a different cause: I had a file named "copy.py" in the folder with my project.
This "copy.py" was an assignment to make a function that returns a deep copy of a list. The turtle library imports "deepcopy" from "copy"; turns out there's already a "copy.py" as part of python (which I'd never seen/used) & by having a file named "copy.py" in my project folder, it was causing turtle to import the wrong copy.py, which was causing the error to be thrown in turtle (my copy.py assignment's deepcopy function didn't work the same way as the one in python).
This is a more general suggestion, but it's good to double check and make sure you don't have any filenames that are in conflict with actual python imports used in your project. There are too many to list here, but ones used by turtle include: tkinter, types, math, time, inspect, sys, and copy. If you have any of these with a .py in your folder (for example, if you had previously created an inspect.py), turtle will be loading that instead of the built-in library & will not work.
Related
I made a test of shadowing Python's built-in string module with my own
module named 'string', to test module search path behavior. My custom
string script has only print('string' * 2) for contents. It is
located in the current directory as shown in code below.
Python 3.6.4 |Anaconda custom (64-bit)| (default, Jan 16 2018, 10:22:32) [MSC v.1900 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.
In [1]: %pwd
Out[1]: 'C:\\Users\\stephen'
In [2]: import string
In [3]: string
Out[3]: <module 'string' from 'C:\\ProgramData\\Anaconda3\\lib\\string.py'>
In [4]: import imp
In [5]: imp.reload(string)
stringstring
Out[5]: <module 'string' from 'C:\\Users\\stephen\\string.py'>
Three questions about reload in IPython:
Why did reload think the module it actually imported (the local string.py) had already been imported? Is it just the sameness of file
name?
Why did reload import a different module than the one already imported? Did it skip the check of sys.modules dictionary, which was
checked first during original import?
Why did reload/IPython/Python not know it had pulled a fast one here, switching one module for another?
Edit: In going back and forth trying to take care of Stack Overflow complaining about my code block, I inadvertently lost some of what I meant to say. Here is what I can remember:
IPython is adding the built-in string module to sys.modules dictionary at startup (sys.modules is searched before sys.path), something the regular Python interactive prompt doesn't do. So I got a different behavior from the interactive prompt vs. IPython. With the interactive prompt, I always got the local string.py, since sys.path starts with current directory for module search. So, this much I understand about the difference between regular interactive (Anaconda) and IPython. The questions I listed are what remain confusing for me.
reload is supposed to repeat the process of locating the source code for the module it's reloading, and if it finds a different file from what the original import found, it's supposed to use the new file. After all, it needs to handle cases where a module was moved, or where a normal module was changed to a package or an extension module.
reload is not supposed to look at sys.modules and stop if it finds something. If it did that, it would perform no reloading!
The reason reload finds the local string.py file when the initial IPython-internal import didn't is because the import path has changed since the first import. You ran IPython in a way that doesn't cause Python itself to put the working directory on the module search path, and IPython imported the string module from the standard library under that configuration. Afterward, IPython placed the working directory on the module search path itself, mimicking regular interactive Python, so reload found the local string.py.
Tested on my Kernel
Looks you are using a local module name that shadows the name of a standard library or third party package or module that the application relies on. Python imports usually check from the the sys.path setting which might be set under Users\stephen. Hence when we reload it, it picks the first occurrence. Hope it helps.
For reference: https://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html
I am trying to import a python (2.7.5) module but I'm not sure if I am going at it in the right way. I usually work in Jupyter Notebook (in a seperate Conda env) to keeps things organized per project. Now I am trying to import a module called otbApplication which are Python bindings for a GIS program called Orfeo Toolbox. The thing is, Orfeo Toolbox (together with QGIS) comes with its own Python install (and subsequent paths) and even its own CMD prompt (assuming you use OSGEO4W). If I use this CMD prompt to start Python and import otbApplication, it works fine. But I want to install more packages and just work within my own 'usual' environment (Jupyter Notebook) in this case.
How should you normally reuse modules between Python installations?
I already tried placing a .pth txt file containing the path to the module in one of the sys.path locations of a different Python installation but it wouldn't even find it. I tried to force it by hosting a notebook (with the same Python install) in the same folder as the module and then importing it. I got the following error which makes me question if I am going at this the wrong way:
Python 2.7.5 |Continuum Analytics, Inc.| (default, Jul 1 2013, 12:37:52)
[MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import otbApplication
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "otbApplication.py", line 28, in <module>
_otbApplication = swig_import_helper()
File "otbApplication.py", line 24, in swig_import_helper
_mod = imp.load_module('_otbApplication', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
This means that forcing the same paths to my new installation is not enough, what am I missing? Apologies for the long story (or the probable butchering of some of the terms).
Kind regards,
Jasper
You've got the right idea with the .pth file, but in order to get it to work you need to check some prerequisites. Obviously, the syntax needs to be good (just give the directory locations separated by line breaks). A common issue is that folks don't put the .pth files in the correct directory (usually though not necessarily \Lib\site-packages). I bet that if you check these you'll be okay.
**Also: as noted in the comments be aware that 32-bit python isn't going to like a 64-bit DLL and verse-visa, so ensure that you're running the right version of python when you try to access those libs.
I am trying to use a code which was written for python 2 and may run with python 3.6.0, but it does not run with python 3.6.4. It imports the IN module, and uses IN.IP_RECVERR. I tried to google it, but it is a 'bit' hard to find anything about a module called IN (naming fail?). To demonstrate in REPL, that it works in python 2, but not in 3.6.4:
$ python2
Python 2.7.14 (default, Jan 5 2018, 10:41:29)
[GCC 7.2.1 20171224] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import IN
>>> IN.IP_RECVERR
11
>>>
$ python3
Python 3.6.4 (default, Jan 5 2018, 02:35:40)
[GCC 7.2.1 20171224] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import IN
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'IN'
>>>
What is the replacement for this IN module in newer versions of python 3?
This is presumably the private plat-linux/IN.py module, which was never intended to be used. There have been plans to remove these plat-* files for a few zillion years, but it looks like it finally happened in issue 28027 for 3.6. As mentioned in What's New in Python 3.6:
The undocumented IN, CDROM, DLFCN, TYPES, CDIO, and STROPTS modules have been removed. They had been available in the platform specific Lib/plat-*/ directories, but were chronically out of date, inconsistently available across platforms, and unmaintained. The script that created these modules is still available in the source distribution at Tools/scripts/h2py.py.
Most of the useful constants that are at least somewhat portable (as in you can expect them to be available and work the same on your old laptop's linux and your brand-new Galaxy's linux, if not on OS X or Solaris) have long been made available through other places in the stdlib.
I think this specific one you're looking for is an example of not completely useless, but not portable enough to put anywhere safe, because linux documents the existence of IP_RECVERR, but not its value. So, you really need the version from your own system's ip headers.
The way to do this safely, if you actually need the IN module, is to run Tools/scripts/h2py.py with the Python version you're using, on the specific platform you need. That will generate an IN.py from the appropriate headers on your system (or on your cross-compilation target), which you can then use on that system. If you want to distribute your code, you'd probably need to put a step to do that into the setup.py, so it'll be run at install time (and at wheel-building time for people who install pre-built wheels, but you may need to be careful to make sure the targets are specific enough).
If you don't need to be particularly portable, you just need to access the one value in a few scripts that you're only deploying on your laptop or your company's set of identical containers or the like, you may be better off hardcoding the values (with a nice scare comment explaining the details).
I am a beginner python learner using The book 'Think Python' where I have to install module name Swampy. The link provided fro instruction and download has a tar.gz file. I found the python 3 version of the swampy with google search here. All setup tools for modules are under python 3. I am pretty lost, how do i install/use the module?
Thanks
You don't have to install Python modules. Just import them. (In fact, swampy is a package, which is basically a collection of modules.)
import swampy
Of course, Python has to know where to import them from. In this case, the simplest thing for you to do is to invoke Python from the directory containing the folder swampy, since the interpreter will first search for modules in the current directory. You can equivalently os.chdir to the directory after invoking Python from anywhere.
Don't worry about setuptools yet.
for python 2.7 I go to C:/Python27/Scripts dir and then try to "easy_install " or "pip install ".
can be a file.
if it does not help: try to unzip downloaded source files and execute "python setup.py install" from command promt
The link is correct but the explanation is vague even for an experienced Windows developer. It assumes too much knowledge of the Python installation process IMO.
e.g. "The simplest way to use this code is to unzip it in your home directory, cd into the unzipped directory and work there."
What is meant by 'home directory'? Then there is a reference to an 'unzipped directory', which I presume means the home directory. The change of name is confusing.
Nevertheless, say one unzips to C:\Python33\lib\swampy-2.1, and works from there. Whatever this means? I can only presume it means save your code in the swampy 'home directory'. It is not best practice to save your python code in a library directory. I use \dev\python\test\ but then
Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import swampy
Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
import swampy
ImportError: No module named 'swampy'
However, if the swampy directory is simply renamed to swampy (from swampy-2.1) then all is OK!
>>> import swampy
>>> from swampy.Gui import *
>>> g=Gui()
>>> g.title('Swampy.GUI')
>>> g.mainloop()
FYI this is my path (my dev drive is E: rather C:)
E:\Python33\Lib>path
PATH=E:\Python33\;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\System32\Wbem;E:\Program Files\Microsoft SQL Server\100\Tool
s\Binn\;E:\Program Files\Microsoft SQL Server\100\DTS\Binn\;E:\WINDOWS\system32\WindowsPowerShell\v1.0;E:\Program Files\
Microsoft\Web Platform Installer\;E:\Program Files\Microchip\xc8\v1.21\bin;E:\Program Files\GtkSharp\2.12\bin
and I don't have a PYTHONPATH environment variable as suggested by other posts.
One easy method is by unpacking the contents into a directory of its own in the Python root directory. Then point Python to the location of the module in the file modulepaths.pth (You may need to create this file in the root directory of your python installation.)
You can either put the full path or a just a relative path. My modulepaths.pth looks like this with one relative and one full path:
swampy
c:\Python34\arduino
I've installed and configured PyDev version 1.6.5.2011020317 inside Eclipse, running on Mac OS X 10.6.6:
Version: Helios Service Release 1
Build id: 20100917-0705
I used 'Auto Config' to set up my Python interpreter: it correctly found /usr/bin/python (which is Python version 2.6.1) and added various system folders to the PYTHONPATH, including /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC. Now that path is the correct path to the Foundation module in OS X, as evinced by the command-line interpreter:
$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
>>> Foundation.__path__
['/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC/Foundation']
So why does PyDev complain about "Undefined variable from import: NSDictionary" on this class:
import Foundation
class MyClass(object):
def __init__(self, projectPath):
'''
Constructor
'''
self.projectDict = Foundation.NSDictionary.dictionaryWithContentsOfFile_(projectPath)
when I can use that class without any problem from the command-line interpreter?
Update: OK, I found out why it complains, which is that the Foundation module is using ScriptingBridge to dynamically generate the classes - presumably pydev isn't actually importing the module to see what classes are inside, it's just looking for .py[c] files. So let my question not be "why does this happen", but "what do I do to fix it"?
Why does this happen?: PyDev has no support for parsing the PyObjC scripting bridge metadata, and therefore has no way of introspecting / extracting symbols for many of the PyObjC classes.
What to do to fix it: In the PyDev source code there are several Python scripts which handle discovery of this metadata. The scripts are executed by Eclipse using the configured interpreter, and they return strings which are used to configure the interpreter, fill in completion lists, show usage tips, etc.
The scripts which seem relevant to your needs are:
interpreterInfo.py - called to obtain the list of directories and other default top-level imports for a given interpreter.
importsTipper.py - generates usage tips for a given symbol.
pycompletion.py - generates a list of completions for a given symbol.
Examples of calls to the above scripts using the system interpreter:
% /usr/bin/python interpreterInfo.py | grep PyObjC
|/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjCINS_PATH
Generate completions for a module:
>>> import pycompletion
>>> print pycompletion.GetImports('os')
##COMPLETIONS(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py,(EX_CANTCREAT, 3),(EX_CONFIG, 3),(EX_DATAERR, 3), ....
It seems possible to create a simple macobjc.py library with routines which detect and read the PyObjC.bridgesupport file(s). The PyDev scripts could be modified to call into this library in order to return the list of valid completions for those classes. You'll need to point Eclipse to a local copy of the PyDev source in order to develop and test your patches against these files. Once you're done you can send it upstream; I have to believe the PyDev folks would accept a well-written patch to support PyObjC completions.