You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's have a wrapper for function calls or attribute lookups that lets us trace into things. IT would look something like this:
take:
if is_logged_in(session, user):
and say like:
if wtf_is_in(is_logged_in(session, user):
or even better:
@wtf_is_in
if is_logged_in(session, user):
and get output like this:
****DEBUG is_logged_in(session, user):
return False from /path/to/sourcefile:119:is_logged_in(session_object, user_object)
return False from /path/to/otherfile:1668:check_valid(session, user_object)
return False from /path/to/session_model.py:450:email_address_validated(user_object)
This is different from the current wtf behavior because rather than inserting a tracing line into a function call at the top of the stack to see what went on below, we can insert tracing at the base of the stack to see where things go up above en route to returning us values.
This seems like it's probably hard to write. Unless inspect already does some magic here, we're looking at real source code inspection. Get the return value, figure out if it's a bare value or a variable reference. If it's a variable reference, figure out where the variable is defined, then trace into that, rinse and repeat. If it's a bare value, return the name of this thing as likely being the culprit.
The text was updated successfully, but these errors were encountered:
Let's have a wrapper for function calls or attribute lookups that lets us trace into things. IT would look something like this:
take:
and say like:
or even better:
and get output like this:
****DEBUG is_logged_in(session, user): return False from /path/to/sourcefile:119:is_logged_in(session_object, user_object) return False from /path/to/otherfile:1668:check_valid(session, user_object) return False from /path/to/session_model.py:450:email_address_validated(user_object)
This is different from the current wtf behavior because rather than inserting a tracing line into a function call at the top of the stack to see what went on below, we can insert tracing at the base of the stack to see where things go up above en route to returning us values.
This seems like it's probably hard to write. Unless inspect already does some magic here, we're looking at real source code inspection. Get the return value, figure out if it's a bare value or a variable reference. If it's a variable reference, figure out where the variable is defined, then trace into that, rinse and repeat. If it's a bare value, return the name of this thing as likely being the culprit.
The text was updated successfully, but these errors were encountered: