AttributeError: 'module' object has no attribute 'pydebug'

Question

When trying to run a python script, I get the error AttributeError: \'module\' object has no attribute \'pydebug\'. I am using Python 2.6.

Full error:

Answer 1

On Ubunut-12.04 pyinstaller built binaries invoke "site.py" from host python installation the call trace is trying to fetch "sys.pydebug" value.

$ python
Python 2.7.3 (default, Feb 27 2014, 19:58:35)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> sys.pydebug
False

The custom built python is missing this.

HACK: To make pyinstaller binaries work on Ubuntu-12.04. Added below code change in custom built python which return zero for "sys.pydebug".

$ diff -Naur Python/sysmodule-org.c Python/sysmodule.c
--- Python/sysmodule-org.c      2018-03-15 09:37:26.539515000 -0700
+++ Python/sysmodule.c  2018-03-15 19:58:34.503031000 -0700
@@ -1106,6 +1106,7 @@
maxunicode -- the largest supported character\n\
builtin_module_names -- tuple of module names built into this 
interpreter\n\
version -- the version of this interpreter as a string\n\
+pydebug -- always return zero\n\
version_info -- version information as a named tuple\n\
hexversion -- version information encoded as a single integer\n\
copyright -- copyright notice pertaining to this interpreter\n\
@@ -1420,6 +1421,8 @@

     SET_SYS_FROM_STRING("version",
                      PyString_FromString(Py_GetVersion()));
+    SET_SYS_FROM_STRING("pydebug",
+                         PyInt_FromLong(0));
     SET_SYS_FROM_STRING("hexversion",
                      PyInt_FromLong(PY_VERSION_HEX));
  svnversion_init();

Answer 2

I hit this issue when attempting to run the Ubuntu 12.04.1 system gdb on a python I built myself. I expect Ubuntu has built some hooks into the system gdb so that it uses a debugging version of Python; but the hooks don't latch onto anything in my own python. I got around this by building my own gdb and running that instead.

Here's the command-line and full traceback:

price@neverland:~/LSST/ip_diffim[master] $ gdb --args python tests/SnapPsfMatch.py 
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 562, in <module>
    main()
  File "/usr/lib/python2.7/site.py", line 544, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/lib/python2.7/site.py", line 271, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/lib/python2.7/site.py", line 246, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/lib/python2.7/site.py", line 236, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/lib/python2.7/sysconfig.py", line 577, in get_config_var
    return get_config_vars().get(name)
  File "/usr/lib/python2.7/sysconfig.py", line 476, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/lib/python2.7/sysconfig.py", line 337, in _init_posix
    makefile = _get_makefile_filename()
  File "/usr/lib/python2.7/sysconfig.py", line 331, in _get_makefile_filename
    return os.path.join(get_path('platstdlib').replace("/usr/local","/usr",1), "config" + (sys.pydebug and "_d" or ""), "Makefile")
AttributeError: 'module' object has no attribute 'pydebug'

so it seems to go looking for the wrong python (in /usr/lib) despite my having told the system not to do so:

price@neverland:~/LSST/ip_diffim[master] $ which python
/home/price/eups/Linux/python/2.7.2/bin/python
price@neverland:~/LSST/ip_diffim[master] $ echo $PYTHONPATH | grep usr
price@neverland:~/LSST/ip_diffim[master] $ 

Answer 3

I think whatever you are trying to run is expecting to be used with a special debug build of python. sys.pydebug is not normally found on the standard release of the sys module, and I believe it would be there if you built a debug python:

http://docs.python.org/c-api/intro.html#debugging-builds

It is possible that this also might be part of a specific build that Debian/Ubuntu distros are using.

Answer 4

I receive the error when running gdb on a Ubuntu system where an alternative version of Python has been installed and is being preferred by the linker. You can verify whether this is happening in your case by using ldd to ask which libraries gdb is using:

# ldd $(which gdb)
...
        libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00007ff75e044000)
...

You can see that the off-brand version of Python running in /usr/local/lib is supplying libpython to gdb instead of the official Ubuntu Python in /usr/lib which is causing the error — whatever off-brand Python this is in /usr/local must not have been compiled in the same way that the Ubuntu Python was compiled, and so the expectations of gdb are being disappointed.

The solution is to use the environment to control the linker’s behavior and make it prefer the system libpython. For good measure, I also reset my PATH back to something utterly standard. I find that this works:

PATH=/bin:/usr/bin LD_LIBRARY_PATH=/usr/lib gdb ...