Josh Rosenberg added the comment: You're going to need to provide a real repro; your description is effectively useless. For the record, Python is not precisely pass by reference (it's roughly equivalent to passing a pointer in C, binding the local name to the same pointer, so if you reassign the local name, you lose the reference, but otherwise it behaves like pass-by-reference).
Are you sure the command library doesn't open new connections as needed? In a recursive call scenario, if it goes deep enough, even if it clean up with the recursive call eventually returns, you could still hit the open files limit. The problem is not copyfile, even if you happen to see copyfile in the traceback. You've got too many open files, and copyfile is the straw that broke the camel's back, but unless you're running 1000 threads doing copyfile simultaneously, it's not responsible for the excess open file handles. But this is all speculation; the only thing I'm confident of is that copyfile isn't ultimately responsible. We have no idea what's wrong, so you need to provide some sort of minimal repro that exhibits the problem. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26861> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
