'all' function name shadows built-in function.

[Xender]

Hello.

function_trace.all function shadows the built-in all function, which can create situations reaching from mere inconvenience (when one needs to use import as or refer to it by fully-quelified name in order to be able to use built-in all function normally), up to non-obvious bugs (when one uses from function_trace import all, but then forgets about the shadowing and tries to use built-in all).

Could the name be changed to one that doesn't case such a clash?
Maybe all_members or just members would cut it?

[weissjeffm]

I haven't maintained this lib in a while, and this problem doesn't seem severe enough to make another release. Python's module system has mechanisms to deal with these collisions - there's no rule that says you can't name anything the same as a std lib function.

However I'm not in the RedHatQE organization anymore so maybe a current member wants to take a shot at changing it.

[Xender]

Python's module system has mechanisms to deal with these collisions - there's no rule that says you can't name anything the same as a std lib function.

Well, It's just a non-written rule of not being "that guy" who shadows built-ins with function defined in his own library (and then suggesting others to from import those as in the example). ;)

I've also found that the example was not updated when trace_on function changed it's API and I've made Python 3 version of the library.

Anyway, the whole thing is on Python Software Foundation licence, right? I ask, because the only place the licence is mentioned is setup.py file...

[weissjeffm]

If you submit a PR to add an open source license (and whatever fixes you want), i'll help get it approved by Red Hat.

There won't be any problem getting the licensing approved, Red Hat is generally pretty easy for that sort of thing.