On Thu, Oct 11, 2012 at 12:29 PM, Jeroen Demeyer <[email protected]> wrote: > On 2012-10-11 21:24, Volker Braun wrote: >> As I wrote on the trac ticket before, there is virtually no difference >> between "source foobar" in the shell and "import foobar" in Python, both >> will happily pull in somebody else's code. And nobody would dream of >> compiling a shared library into /tmp and then set LD_LIBRARY_PATH=/tmp >> to load it (in fact this might happen behind the scenes if you were to >> use libtool to compile something in /tmp). I don't see whats different >> if you put a Python script in /tmp, thats just ill-advised. > > As I already said, I do think that Python is to blame here because doing > > import some_module > > is an absolutely normal Python construct.
But putting Python files in /tmp and running them is not a normal thing to do, any more than compiling shared libraries in /tmp. BTW, it's not the Python testsuite that puts files here, it's us, which should be fixed by #12415 (which is a much bigger issue). > There is even no easy way to > specify an absolute file path for "some_module". In bash, people are > not normally going to do > > source some_file_not_under_my_control.sh > > (I would *always* specify a path for "source"). I've seen "source sibling_file" and "source $path_of_this_file/sibling_file many times, how else are you going to split functionality across multiple bash scripts? Such scripts obviously shouldn't be executed from, e.g., /tmp. - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
