Title: flat namespace
Type: crash Stage:
Components: IO, Library (Lib) Versions: Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: bugbee, ned.deily
Priority: normal Keywords:

Created on 2016-03-07 05:30 by bugbee, last changed 2016-03-08 08:30 by bugbee. This issue is now closed.

Messages (4)
msg261278 - (view) Author: Larry (bugbee) Date: 2016-03-07 05:30
On OSX El Capitan, Python v2.7.10 and 2.7.11 (standard installer)...

When importing urllib2 it crashes with a flat namespace error then loading  Shortest test case: "python -c 'import urllib2'"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 94, in <module>
    import httplib
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 80, in <module>
    import mimetools
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 6, in <module>
    import tempfile
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 32, in <module>
    import io as _io
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 51, in <module>
    import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/
  Expected in: flat namespace
 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/

This error occurs under both v2.7.10 and v2.7.11.  When I regress to 2.7.9 and all is well.
msg261305 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-03-07 17:01
Sorry, I am unable to reproduce the problem.  My guess is that somehow there is a version mismatch between the Python executable and the dynamic libraries.  This *could* be caused by a number of things, like environment variable settings.  Suggest trying to isolate the problem by checking the following in a bash shell:

$ type python
python is hashed (/usr/local/bin/python)
$ which python
$ ls -l $(which python)
lrwxr-xr-x  1 root  wheel  68 Jan  2 23:08 /usr/local/bin/python -> ../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python
$ python -c 'import sys;print(sys.version)'
2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 12:54:16)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
$ /usr/local/bin/python2.7 -c 'import urllib2'
$ env | sort
# look for LD_* and DYLD_* variables
$ python -v -c 'import urllib2'
msg261306 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-03-07 17:13
An even more likely scenario: the Python executable you are using is coming from an older virtualenv.  If so, you need to update the virtualenv to include an up-to-date python executable.
msg261333 - (view) Author: Larry (bugbee) Date: 2016-03-08 08:30
Ned, thank you for your suggestions.  

Just so you know, my HD recently crashed so I rebuilt the system with a new SSD.  I was previously running 2.7.9 so I installed 2.7.9 to minimize any potential conflicts with my code base.  All was well.

Now it was time to rev Python to 2.7.11 and that was when the problem occurred. I tried 2.7.10 and then 2.7.9.  I hadn't gotten around to virtualenv so all these Python installs were on top of each other in /Library/Frameworks/...

Following your suggestion, with 2.7.9 installed, I ran your commands and the output was as expected.  I did notice, however, a lot of [benign?] cruft in my .profile and .bashrc and thought it best to clean them up.  Ok, still good.  I then installed 2.7.11 and reran your commands.  Again, everything worked as expected.  Huh?

I restored back to my earlier versions of .profile and .bashrc (cruft included), and am still unable to reproduce.  :-/  I've tested and retested.  All is still well, so sadly I'm unable to report the cause.  I suggest we close the report.

Changing the subject slightly...  I noticed that each time we do an install of Python, another path is prepended to PATH even if there is already an identical entry in .profile.  Did I mention cruft?  ;-)  Hard perhaps, but is there a way for the install script to mock execute .profile to devine the resulting PATH, inspecting it for the desired path rather than just blindly adding it to .profile?  ...just a thot.

Again, thanks for your help.  I'm off and running.
Date User Action Args
2016-03-08 08:30:30bugbeesetstatus: open -> closed
resolution: not a bug
messages: + msg261333
2016-03-07 17:13:11ned.deilysetmessages: + msg261306
2016-03-07 17:01:28ned.deilysetnosy: + ned.deily
messages: + msg261305
2016-03-07 05:30:41bugbeecreate