1) _I_ am not using symlinks this way.  The hadoop scheduling processor is.  This means that we cannot use Python for it withouth hacking the scripts for the special case.  Presumably applications are not generally breaking when run in an artificial file tree populated with symlinked files into arbitrary real locations, but Python is.  Only Python seems to care about the _real_ location of the file, as opposed to the apparent location.
2) This particular use case is quite unobvious, and goes against the spirit of symbolic links. They are meant to be transparent for applications.  Consider e.g. the analogue to e.g. C header files. Only Python seems to care about the _real_ location of the file, as opposed to the apparent location. Effectively, Python is actively using the knowledge of these links as a sort of dynamic sys.path modifying tool.

I agree that it is not good to break existing usage, however misguided it may be.  But in that case, isn't it possible to disable this symlink dereference via e.g. an option?