A quick search found this response -
knowledge.safe.com/questions/50441/shape...fields-as-strin.html
To answer this question, I need to explain some FME history. In the very beginning, our goal was to completely hide the internal representation of data from end users. We would look after any conversions that were ever going to be needed and do them automatically. And our original FME implementation was that we would handle any attribute we read as a string internally. This provided a very easy and consistent way of working. And all the early formats of FME were written accordingly -- they all created internal FME representations as strings. Shape is one of those, and this makes good sense because actually all attribute data in a shape file is actually stored as a string ultimately.
With time, we expanded the power of FME and for efficiency sake we added the ability to store attributes in the native type that we read them. So if a format could give us a number as a float or double or int, we'd just store that. And by so doing, avoid converting things into strings if we didn't need to.
For the most part we didn't go back and retrofit existing format code, because FME will do whatever conversions are necessary anyway and all this is hidden from the user. (Except at some point the python call was made available which is what you have stumbled upon).
Note that we have no intention of updating our shape reader. Why? Well, in the case of Shape, the attribute data is actually all stored in the DBF file as...you guessed it...strings. Even if the DBF says it is a number. And so we don't want to take on the expense of converting those strings into numbers to pass through FME because there is an excellent chance we may never need to during the whole translation. If we go shape->shape for example, it is just going to get written out as a string ultimately anyway.
So Takashi's technique of inspecting/using the actual schema feature is truly the only way to reliably know what the original format intended the attribute's type to be. The storage format in FME is not guaranteed to be the same. I apologize for the confusion the python call may have caused, and hope we can find a way to get you the results you need without undo trouble.