Yes it is IEEE-754 specific. I think any binary floating point will have similar pitfalls though.
Python has a Decimal type that can represent decimal values exactly. It must be imported first though. It is probably much slower than IEEE-754 floating point, but for many uses that is not an issue.
http://docs.python.org/library/decimal.html
The alternative is a revision of IEEE 754 to include "decimal floating-Point arithmetic," which is apparently something "in progress" because the interests of those involved can't result in agreement. I'd really like to read anything from some insider. I know that IBM did the most of the work in that direction. Decimal Floating Point is the thing to have, but who know when that can happen in processors or in wider use. I know from Brendan Eich that there were attempts to add DFP in Javascript but that even there no agreement was achieved.
Edit: or it was standardized but still not gaining acceptance:
There is alternatives but don't forget that it is hardware issue not software. It looks like http://en.wikipedia.org/wiki/IEEE_754-2008 has decimal format thus it should address that.
It is both specific and non-specific depending on what you are trying to achieve.
In the special case of 0.1 + 0.2 != 0.3, this is specific, and using decimal will "fix" it. But decimal, or for that matter any representation will have the exact same issue for other cases. Arbitrary precision means exactly that: arbitrary, as in not infinite precision. How will you represent irrational numbers with decimal ? It is theoretically impossible.
That's why most advices about using decimals instead of IEEE 754 are not appropriate. In the special case of accounting, it is appropriate, but I am somewhat doubtful most people don't need to do occasional computation with their numbers involving transcendental functions (e.g. log, exp, etc...). As soon as you start using this, you will see the issue cropping up, whatever representation you may want to use. And IEEE 754 representation has been conceived by people who really knew what they were doing (e.g. W. Kahan)
In any practical sense, no. The inconvenience is overwhelmingly offset by it working the same everywhere. And as others have said, you can sacrifice speed for it working "properly" anytime.
If so, are there any IEEE-754 alternatives?