I don't think the implementation needs alternative approach, but I think the formulation of the problem and the method profile strongly requires improvements.
The big problem of your formulation is that is implies strongly
ad-hoc behavior, something opposite to being abstract and universal. In your implementation, you hard-code
immediate constants 0 and 2, which is always bad (for maintenance and everything else), but you have to blame the problem formulation a lot more then the implementation. Even with perfect implementation, when the opening "brackets" has any number of characters other then 2, your method fails. Moreover, the signature of the method is not self-commenting. If give the user no clue on the requirements for the first parameter; and the requirements are just very unnatural.
This is not just bad, this is very bad.
At the same time, more neat solution
is obvious. Use different signature:
def makeOutWord(bra, word, ket):
I'm also not sure that such a trivial method is really needed, but let's set it aside and assume it is needed, say, due to frequent use of such word sandwiching.
Implementation just does not matter and can be based on the same formatting approach you have used. As you can see,
nothing will need to be hard-coded. Moreover, the method signature is intuitive. My naming only helps me; I use this naming sometimes. I borrowed it from my highly respected colleague Paul Dirac who first introduced it :-):
https://en.wikipedia.org/wiki/Bra%E2%80%93ket_notation[
^],
https://en.wikipedia.org/wiki/Paul_Dirac[
^].
—SA