The answer by @Paul92 is good general discussion, but I would like to offer a possible clean(ish) solution to this:
A a library, this code needs to be adaptable to any runtime environment, so you can't really ask
STDIN for some crucial bit of data. For one, users of your library might not have stdin available for a number of reasons. Instead you might want to use some form of strategy pattern to customise how the token is to be retrieved.
In Python, probably the best option is to pass in the token fetching strategy as a function parameter. Something like that:
return input("Enter code: ")
def my_library_function(arg1, arg2, ... argn, token_provider = stdin_prompt):
token = token_provider()
# somewhere in the user code
stuff = my_library_function(a1, a2, ... an, lambda: "123456")
Think of it like this. The token that you require, is an argument to the library function. Since the value for the token might not be statically known at the call site, you can not really ask for the value as an argument. Instead, the caller has to provide a function that is going to be responsible for providing the token when called.
All the responsibility for providing the exact mechanics of the token are now externalised from the library function. The consumer of the function is now responsible for acquiring the token by whatever means are available at runtime. It may ask STDIN, but it might also act as a mail gateway, wait for the message to pop in to the inbox, read it, extract the token and completely automate the process. It might be a GUI dialog or a web based form. Anything really -- all the options are now in the hands of the library consumer.