There is no "binary" here contributing to the problem.  The particular case is a the hadoop runtime engine which creates a "virtual" folder of your working directory.  We have set up a directory of .py files:

foo/
 a.py
 b.py
 c.py

The hadoop job is then to run a.py.  It is run simply as python a.py.  In this case, by cd-ing into the dir and running the file.  hadoop knows nothing of python and merely executes the given file.

Now, what this hadoop implementation does, however, is to create a virtual symlink image of your project directory, and duplicate this in various places, e.g.:

tmp1/
 a.py -> /secret/filecache/0001/a.py
 b.py -> /secret/filecache/0002/b.py
 c.py -> /secret/filecache/0003/c.py

tmp2/
 a.py -> /secret/filecache/0001/a.py
 b.py -> /secret/filecache/0002/b.py
 c.py -> /secret/filecache/0003/c.py

Notice how each file, previously together in a folder, now pyhysically resides in a unique place.
now, when you run a.py from either tmp1 or tmp2, it will contain
sys.path[0] == "/secret/filecache/0001"

This means that a.py can no longer import b.py.  I am unaware of a workaround for this issue which does not involve modifying the individual .py files themselves to set up a path.

Fixing this would mean that rather than to
- get the absolute path of the .py file, and extract the path from it
you would
- extract the relative path of the .py file and retrieve the absolute path for it.

I am not sure about what use cases could be broken by the above change, do you have examples?
Normal use cases of symbolic links have to do with linking entire folders, not individual files, and that behaviour would not be broken by  such a hypothetical change, I think.