This is not a violation of DRY. It is a facade which hides the implementation detail that
get_some_stuff_type_B uses the same underlying method. This is often good API design, since the implementation could change in the future to use different methods without affecting the interface. (Whether it is good design in this particular case is hard to say since the example is so abstract, but the principle is fine.)
To take a more concrete example:
private def set_user_state(state)
You could just expose
set_user_state(state) directly and let the caller provide the state value, right? But what if you want to change the implementation to actually delete the record from the database? Oops, you can't do that now. Or what if it
delete_user should take a flag which indicates if the user is permanently deleted? Too late. By exposing the state enum in the API you have coupled the API to a particular implementation.
On the other hand there may be contexts where the second approach is better. Lets say there is a text rendering routine:
In this case there is no value to have individual methods for each letter, so you could simplify the API to just expose
So the actual answer to your question depends on what "stuff" is.
DRY is a good principle in general, but is sometimes misunderstood. It does not say you should compress the code to contain the lowest number of tokens. It says the same information should only be represented once. But in the case of an API facade you have two different kind of information - how the API interface looks and how it is actually implemented. These are supposed to be different and be able to change independently, otherwise you have a tight coupling.