I have a python script that I'm trying to execute but i'm not sure how it's meant to be executed. I don't program in Python so i'm unfamiliar with the language. Here is the link to the script i'm trying to use. Also, a link the configuration it's using if you wish to see it. All it seems to do for what's relevant here, however, is set my path which I know is correct since other scripts (not linked here) work as expected with the configuration in that file.
Having a look at the script, I believe that the script is meant to be ran with the command line arguments: view, new, init. Thus, I ran the following in my terminal
$ lectures.py new
But I get the following traceback
Traceback (most recent call last):
File "/usr/bin/lectures.py", line 156, in <module>
lectures = Lectures(Path.cwd())
File "/usr/bin/lectures.py", line 60, in __init__
self.root = course.path
AttributeError: 'PosixPath' object has no attribute 'path'
Furthermore, my python version
$ python --version
Python 3.8.1
EDIT:
I wanted to add the reference as well for what I am trying to follow
Going through your code, I think you might mean:
self.root = course
at that line.
Path.cwd() returns:
... the current working directory, that is, the directory from where you run the script.
that is, either a WindowsPath() or a PosixPath object. I believe it is PosixPath for you, and you can verify with:
import os
print(os.name)
# posix -> Linux
# nt -> Windows
This has no attribute path, and this is what your Interpreter tells you.
Related
Not my code, I was trying a tool that includes the osascript library.
In the lib, at the line path = temp.tempfile() the error in the title is raised.
The temp library, correctly imported by the authors, has the following code itself:
f, path = tempfile.mkstemp()
The tempfile.mkstemp() part works like a charm.
So, since we are talking about two very common and widely used libs and since I'm apparently unable to find anything relevant on Google, I'm kind pretty sure there's some problem with my local configuration.
I'm on macOS, using python3 (3.7), no virtual envs.
The command pip list --outdated tells me that exactly those two libs are actually outdated, but apparently there is no way pip will download the updated versions. (note: my pip is correctly referring to the python3 binary, not macOS outdated python 2.7)
osascript 0.0.0 2020.7.2 sdist
temp 0.0.0 2020.7.1 sdist
Any ideas?
Steps to reproduce the error:
>>> import temp
>>> temp.tempfile()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.7/site-packages/temp/__init__.py", line 15, in tempfile
f, path = tempfile.mkstemp()
AttributeError: 'function' object has no attribute 'mkstemp'
This is a bug in package temp which is a dependency of osascript. The package imports tempfile and then immediately overwrites it with a function tempfile. Report the bug.
Something in my setup of my shell causes arbitrary strings like "krmpfl" or "u45g5svtJ7" to create a Python error:
$> krmpfl
Traceback (most recent call last):
File "/usr/lib/command-not-found", line 28, in <module>
from CommandNotFound import CommandNotFound
File "/usr/lib/python3/dist-packages/CommandNotFound/CommandNotFound.py", line 19, in <module>
from CommandNotFound.db.db import SqliteDatabase
File "/usr/lib/python3/dist-packages/CommandNotFound/db/db.py", line 5, in <module>
import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'
I would expect bash (and not python!) to throw an error of the kind "Unknown command krmpfl. Did you mean...", but any non-recognized command is for some reason passed to python. I am confused.
Does anyone have an idea on how to debug this or how to move forward? I've tried type krmpfl but this (correctly) echoes bash: type: krmpfl: not found
My setup:
Win10 using Ubuntu 18.04 within WSL
ConEmu as a console
Bash-it
Python 3.8
Click (python package) installed to simplify creating commands
If your current shell function defines a function named command_not_found_handle, bash runs that for a non-existent command rather than immediately failing with a "command not found" error. In your case, that function exists and calls /usr/lib/command-not-found, which appears to be a Python script that tries to download (or at least suggest you download) a package with apt_pkg, but you don't have that Python module installed, which leads to the Python exception.
OK, trying to track down this issue of running a Python package.
Running on Windows.
Only one version of Python is installed on the computer: 3.4.3
Package has been installed (package name: Willie) (details of installation are more convoluted than usual; can provide steps if necessary)
Package installed at: C:\Python34\Lib\site-packages\willie
Startup script is: C:\Python34\Scripts\willie.py
Error is one of the first lines of the script:
from willie.tools import stderr
If I run willie.py from the command line, I get this error:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 2218, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python34\Scripts\willie.py", line 15, in <module>
from willie.tools import stderr
File "C:\Python34\Scripts\willie.py", line 15, in <module>
from willie.tools import stderr
ImportError: No module named 'willie.tools'; 'willie' is not a package
The __path__ attribute is supposed to be set automatically when the import function is used, but it doesn't exist, which leads to the program being unable to execute.
C:\Python34\Scripts; is in my Path environment variable.
PYTHONPATH has been set for everything from C:\Python34; to C:\Python34;C:\Python34\Lib;C:\Python34\Lib\site-packages;C:\Python34\Lib\site-packages;C:\Python34\Lib\site-packages\willie;C:\Python34\Lib\site-packages\willie\tools;.
In all cases with these directories, if I try to execute the above import command from the interactive Python prompt, it runs correctly. I can use the stderr function, and examine its __file__ and __path__ fields.
If I add C:\Python34\Scripts; to PYTHONPATH, however, I get the same error as using it from the command line: __path__ doesn't exist, 'willie' is not a package.
I do know that willie.py is being called recursively, somehow, because I can add a print() at the top of the file that runs twice.
Looking for help in figuring out how to make this run. Is almost certainly a configuration issue on my end, but I have no idea what to do to fix it.
First, you absolutely do not want c:\Python34\Scripts in your PYTHONPATH. Files under \Scripts are NOT meant to be importable.
Second, willie does some screwing around to make sure willie.py gets installed to c:\Python34\Scripts\willie (note there is no .py suffix). This is decidedly nonstandard. The only reason this even works is because on Unix machines, the first line of that file is a special "shebang" that tells the Unix program launcher to execute the file using Python. There is no equivalent feature on Windows - naming the file willie with no .py means you simply can't execute it.
So it looks like the module willie is simply not prepared to be installed on Windows systems. (#811 and #822 both refer to weirdness on Windows caused by the nonstandard package setup.)
A standard package setup would have willie.py inside the willie package as willie/main.py and, in the package's setup.py, register willie.main as an "Entry Point" named willie. This incantation would create c:\Python34\Scripts\willie.exe on Windows systems when the package is installed using pip.
I believe the reason for the recursive import is because the second entry in sys.path is the name of the script that is run from the command line. So, it's always finding C:\Python34\Scripts\willie.py when it looks for the module willie which is not the one it needs.
As a workaround, you could try renaming C:\Python34\Scripts\willie.py to C:\Python34\Scripts\run-willie.py
I had asked a question previously on relative paths in python in SO question: How can I access relative paths in Python 2.7 when imported by different modules
The provided answer worked great in all of my scripts and functions. However, when trying to debug the files in IDLE (Python 2.7) it generates run time errors.
Can anyone point me to documentation on using the __file__ notation? Also I would like to understand why IDLE generates errors while running the sample code but running the same file from the command line or double clicking it (for the windows users) does not.
Any help would be greatly appreciated!
Note that I am running Python 2.7 on Windows XP with virtualenv (unactivated during these tests).
Sample Code
import os
import sys
curdir = os.path.dirname(__file__)
sys.path.append(curdir + '/..')
Error
Traceback (most recent call last):
File "C:\MyFile.py", line 3, in `<module>`
curdir = os.path.dirname(`__file__`)
NameError: name '`__file__`' is not defined
__file__ won't be set if you're writing this in the interpretor.
So:
>>> import os, sys
>>> curdir = os.path.dirname(__file__)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name '__file__' is not defined
Is expected.
__file__ is the name of the file that was called by the python interpretor - so if you ran this from a script it would work.
$ python curdir.py
$
(The script is exactly the same as what I put into the interpretor, hence no error or output)
From what I've observed using IDLE before, it acts as an interpretor - so it'll run the file in question. However, it wasn't started with that file, so the __file__ is never set.
I did the Nodebox tutorial on the graph library:
http://nodebox.net/code/index.php/Graph#loading_the_library
I installed the library in Application Support
I pasted the following code:
graph = ximport("graph")
create(iterations=1000, distance=1.0, layout="spring", depth=True)
And I got this error message:
Traceback (most recent call last):
File "nodebox/gui/mac/__init__.pyo", line 358, in _execScript
File "mypath", line 2, in <module>
NameError: name 'create' is not defined
And before that I got this:
NameError: name 'ximport' is not defined
If I close the file and reopen and just say graph = ximport("graph")
Nothing happens (it seems to work).
I think it would be a very cool library to work with.
Any help would be great.
The problem is with your Path, as the tutorial link that you pointed to said:
Put the graph library folder in the same folder as your script so NodeBox can find the library. You can also put it in ~/Library/Application Support/NodeBox/.
Otherwise install content from the graph.zip
and do
import graph
graph.create
Sorry, I don't have MAC to try these. But the error messages are saying that Python is not able to find your modules properly. For python to find it, they should be in the current directory or in the PYTHONPATH.