Imagine you have a chain of functions calls, in which each function is taking the previous function's output as input for the next calculation in the chain.

Make an assumption that you are leading the infra scope, which means you are defining the process chain and protocol, but you have a group of users that are responsible to implement each cube of the chain (I.e implementation of functions A,B,C and so forth).

Assume we have already a given flow likeA->B->C->D, now imagine that function A sometimes need to return a dictionary and sometimes pandas dataframe as input, this is requirement came from the users, and I think quite break common programming paradigms.

In my opinion, this can have serious inconsistency issues, errors and less testable code.

I would like to hear your thoughts regarding this as a concept
Do you think it is reasonable to return different value type from function according to configuration and having protocol in which each cubes in chain may not talking always on the same protocol? (Discliamer: We are using python)

I tend to see this equivalent to the ability, for example, to populate function parameter function with different types for the same parameter let say (I.e sometimes int sometimes dict) at different function calls - which is wrong.

Although a dynamic type language might let you do it, it's doesn't necessarily mean you should do it, and it may be considered as a bad practice or even abuse of the ability.

Even in python the use of dynamic parameters passing (*args, **kwargs) should be used wisely and in a limited way and only when needed for example here

  • 1
    see What is the problem with "Pros and Cons"?
    – gnat
    Oct 17, 2019 at 11:36
  • No more pros and cons, but this channel is for exchanging ideas and more broader view, engineering concepts, I see no contradiction now, this may be relevant to stackoverflow when trying to be as specific as possible
    – Mulder
    Oct 17, 2019 at 11:38
  • I doubt this, see On discussions and why they don't make good questions
    – gnat
    Oct 17, 2019 at 11:39
  • 1
    @Mulder Historical questions are not a guide for what makes a good, on-topic question on this site. The scope of this site and indeed the name of this site has changed since that question had been asked over 7 years ago. That particular question would almost certainly be closed as off-topic if it were asked here now in 2019 because the topic is covered on workplace.stackexchange.com instead Oct 17, 2019 at 12:18
  • 1
    @Mulder As I said, other questions are not a guide for what makes a good, on-topic question on this site. Some questions may be closed if they aren't a good fit, many others will fall through the net. Oct 17, 2019 at 12:38

1 Answer 1


This is overall a bad practice. Functional language or not, function as a concept should have a given, proper set of inputs (or a single one) and the same for the output, stemming from a mathematical definition of a function. Functional languages bridge this issue of inconsistent return types in chains through the use of monads, which neatly wrap the resulting type in a "container", allowing for easier handling in such calls.

Specific to this case, why wouldn't all of your functions talk on the same protocol? Having a configuration flag indicating which protocol to switch to for all functions doesn't seem like a bad idea, but if some functions are "deaf" in regards to listening to what the configuration says, then you're in for a wild ride of error handling and matching input types. I'd certainly avoid that if possible and I'd always return the same type, avoiding that conf-based function definition as well, for example in your case, I'd always return a dict with the Int value inside it under some specific key.

There's a reason for Python having a practice of docblock-ing functions stating the return type of that function. I'd reformat the code to follow established practices, most likely it'll save you some effort in the long run.

Not the answer you're looking for? Browse other questions tagged or ask your own question.