We Keep Coding

Python sqlite3 library can't use URIs, even though sqlite3 version should be able to

I have the most recent sqlite3 installed on my machine:
$ sqlite3 --version
3.26.0 2018-12-01 12:34:55 bf8c1b2b7a5960c282e543b9c293686dccff272512d08865f4600fb58238b4f9
And, in python, the sqlite3 module is using this version of sqlite3:
$ python
Python 3.4.9 (default, Jan 5 2019, 18:35:56)
[GCC 5.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3 as sq
>>> sq.sqlite_version_info
(3, 26, 0)
>>> sq.version_info
(2, 6, 0)
However, I cannot open a database file using URIs, even though that feature has been present in sqlite since version 3.7:
>>> import sqlite3 as sq
>>> c = sq.connect('file://test', uri=True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
sqlite3.NotSupportedError: URIs not supported
What is going on here? What have I done wrong?

OK, I figured out what was going on by reading the source code. When pyenv compiled my version of Python, the _sqlite module was compiled against the ridiculously old CentOS version of the "sqlite3.h" file. Because of this, the Python module didn't have the SQLITE_OPEN_URI macro defined, which causes it give a hard-coded "URIs not supported" Python exception.
To get around this, I had to set the following environment variable:
# This is to direct pyenv to the linuxbrew include and library directories, when building versions of Python
export PYTHON_CONFIGURE_OPTS="LD_RUN_PATH=/home/linuxbrew/.linuxbrew/lib/ LDFLAGS=-L/home/linuxbrew/.linuxbrew/lib/ CPPFLAGS=-I/home/linuxbrew/.linuxbrew/include/"

Why is my script's directory not in the Python sys.path?

Python 3.6.5
I am aware of this one: Why does my python not add current working directory to the path?
But the problem there is that he's doing something more complicated (referring to a sub-folder but executing from a main folder). The answers there are to either simplify things or to add package definitions.
And the selected answer even says: "It is the script's directory that is added"
However, my problem is really more simple: My script's directory ISN'T added.
Basically, all the tutorials on the internet say: import mymodule
When I do that, I get a name error...
My folder structure:
C:/Projects/interner
interner.py # this is the main program body
aux.py # this is the auxiliary file I would like to import into the above
I've tried both coding 'import aux' inside interner.py, and also using the interactive console:
cd c:/Projects/interner
python
import aux
To no avail (ModuleNotFoundError: No module named 'aux')
My sys.path:
['C:\\Tools\\Python\\python365\\python36.zip', 'C:\\Tools\\Python\\python365']
(both from inside the script and from interactive console)
Could you please tell me why I can't import local scripts? Is it because my sys.path is missing the PWD? If so, why is it missing it?
Edit: Doing this to help investigation:
>>> import os; print(os.listdir("."))
['aux.py', 'hw.py', 'interner.py', 'my_funcs.py']

I believe this is a Python bug, specific to the embeddable (ZIP file without an installer) Windows distribution. I’ve filed https://bugs.python.org/issue34841.
Removing the python37._pth file (presumably python36._pth in your case) from the distribution fixed it for me.

I don't know why but it seems that "" is missing from your sys.path variable, and that prevents from importing modules from current directory all right!
I can somehow reproduce your issue (eatcpu.py is in my current dir):
$ python.exe
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'C:\\Windows\\system32\\python27.zip', 'D:\\AppX64\\Python27\\DLLs', ... etc...]
>>> import eatcpu
works. Now in another python session:
$ python.exe
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.remove("")
>>> import eatcpu
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named eatcpu
>>>
So the quickfix for you is to do:
import sys
sys.path.append("")

It looks like you are using the embeddable distribution of CPython rather than one of the regular installers. As described on the documentation page:
The embedded distribution is a ZIP file containing a minimal Python environment. It is intended for acting as part of another application, rather than being directly accessed by end-users.
Since you seem to be directly accessing Python rather than embedding it, you should consider using the regular (or Microsoft Store) installer (also described on the page I linked above).

Try making it explicit:
from . import aux

Pycharm 4 no module named ROOT, when importing a locally installed module (PyROOT), that is working fine from shell on Mac OS X Yosemite

I am trying to set up PyROOT to work with Pycharm 4 on Mac OS X Yosemite.
I have installed ROOT (locally), with the python option enabled, and set up all of the necessary environment paths.
echo $PYTHONPATH
/Users/natalia/Software/root/lib:/Users/natalia/Software/root/bin:/Users/natalia/Software/root
It works just fine from the shell interpreter:
python
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ROOT
>>> ROOT.__file__
'/Users/natalia/Software/root/lib/ROOT.pyc'
>>>
In Pycharm I have tried to add these paths to the interpreter using Preferences->Project Interpreter->More->Show paths...
The paths that show there are the following:
file:///Library/Python/2.7/site-packages/pip-6.1.1-py2.7.egg
file:///Users/natalia/Software/root/lib
file:///System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
file:///System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin
file:///System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac
file:///System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages
file:///System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
file:///System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
file:///System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
file:///System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC
file:///Library/Python/2.7/site-packages
file:///Users/natalia/Software/root/bin
file:///Users/natalia/Software/root
I created the following file in Pycharm:
import os
os.system("echo $PYTHONPATH")
import ROOT
When run, it returns this:
Traceback (most recent call last):
/Users/natalia/Software:/Users/natalia/Software/root:/Users/natalia/Work/Projects/untitled
File "/Users/natalia/Work/Projects/untitled/l.py", line 3, in <module>
import ROOT
ImportError: No module named ROOT
Notice how this PYTHONPATH that's printed from python in Pycharm doesn't include (for a reason unknown to me) the path that actually includes the ROOT.pyc file, that is: '/Users/natalia/Software/root/lib'
I have also tried doing the dirty trick of
os.system("export PYTHONPATH=$PYTHONPATH:/Users/natalia/Software/root/lib")
but I found it doesn't actually change the path if I print it afterwards.
I am absolutely confused as to where Pycharm gets the paths from.
Any possible solutions would be welcome and greatly appreciated.

You may have figured this out already, but just in case...
import sys
sys.path.append('/Applications/Misc/root/lib')
import ROOT
print ROOT.TTimeStamp().AsString()
will add that search path to Python (& PyCharm by extension); the snippet gives me the following output in PyCharm:
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
/Users/rrios/PycharmProjects/untitled/dummy.py
Thu, 02 Jul 2015 01:07:57 UTC +628998000 nsec
Process finished with exit code 0

Can't import the cx_Oracle module unless I'm using an interactive shell

When using Python on an interactive shell I'm able to import the cx_Oracle file with no problem. Ex:
me#server~/ $ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>>
As you can see, importing works without a hitch. However, when I try to run a Python script doing the same thing, I get an error:
me#server~/ $ sudo script.py
Traceback (most recent call last):
File "/usr/local/bin/script.py", line 19, in <module>
import cx_Oracle
ImportError: No module named "cx_Oracle'
Here is the important section from script.py:
# 16 other lines above here
# Imports
import sys
import cx_Oracle
import psycopg2
...
I'm befuddled here. Other pertinent information is the server I'm running is Ubuntu 14.04.1 LTS (upgraded from 12.04) 64bit. which python and sudo which python both point to the same location. Also, doing this as root via sudo su - gets the same results; import OK from interactive but error from script.
Nothing other than the OS upgrade happened between when this worked and when it stopped working.

Sorry, all. This was a silly on my part. Turns out the script in question was using Python3, and when the server upgraded, Python3 went from being 3.2 version to being 3.4 version.
Once the cx_Oracle module was set up in the 3.4 version, everything worked as expected.
Phil, your final note talking about the shebang was what lead me to discover this, so kudos to you! The reason I didn't mark your response as the answer was because technically it wasn't but led me on the right path.
Cheers!

sudo starts a new bash environment which is then pointing to a different python executable (different installed modules).
You can verify this with which python and sudo which python
EDIT: so if they point to the same executable, then you should look at sys.path to find differences. In both environemnts you can:
python -c "import sys; print('\n'.join(sys.path))"
sudo python -c "import sys; print('\n'.join(sys.path))"
Look for differences. If there are none:
A common error in import situations like this is that python will first look at the local dir. So if you happen to be running python and importing something what is found locally (i.e. cx_Oracle is a subdir of your current location), you will get an import error if you change directories.
Final note: I have assumed here that the shbang of the script.py points to the same executable as which python. That is, that python script.py and script.py return the same error.

Bizarre python ImportError

Here's my setup: a Mac, running OS X Tiger. Windows XP running in a virtual machine (Parallels). Windows XP has my Mac home directory mapped as a network drive.
I have two files in a directory of my Mac home directory:
foo.py
pass
test.py
import foo
If I run test.py from within my virtual machine by typing 'python test.py', I get this:
Traceback (most recent call last):
File "test.py", line 1, in <module>
import foo
ImportError: No module named foo
If I try to import foo from the console (running python under Windows from the same directory), all is well:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
>>>
If I run test.py with Mac python, all is well.
If I copy test.py and foo.py to a different directory, I can run test.py under Windows without problems.
There is an init.py in the original directory, but it is empty. Furthermore, copying it with the other files doesn't break anything in the previous paragraph.
There are no python-related environment variables set.
Any ideas?

Add import sys; print sys.path to the start of test.py. See what it prints out in the failing case. If "." isn't on the list, that may be your problem.

As a random guess: are the permissions on foo.py accessable from the windows client? (eg try opening with notepad from the virtual machine).
If that's OK, try running:
python -v -v test.py
and looking at the output (alternatively, set PYTHONVERBOSE=2). This should list all the places it tries to import foo from. Comparing it with a similar trace on the working machine may give some further clues.