An imitation of reading a C Struct from binary file in python 2.7
A major drawback of this design is that you cannot reuse a single instance of structure.structure to read multiple records.  Instead of s.fill(file_ptr), consider making a method s.read(f) that returns an OrderedDict of the deserialized data.  (By the way, mentioning "pointer" in a parameter name isn't very Pythonic.)  Note that that would also replace your .get_value() method with a dictionary lookup, which can be dealt with more idiomatically. (Or, at least implement dict-compatible iteration and subscripting in your structure class.)

Switching to a reusable .read() method would also eliminate a point of awkwardness in your code, which is that ._table is a dict of dicts, each having a "format" and a "value".

In your implementation of .fill(), why not call .unpack_from(file_ptr) instead of .unpack( file_ptr.read( self.get_size() ) )?

A more natural default endianness would be either big-endian (because that is the standard Network Byte Order) or host byte order (because that is a non-opinionated choice that also happens to be the path of least resistance).

Whatever you design, it should accommodate the opposite operation — serializing data to a file.

Consider allowing a structure to contain nested structures as fields.

The .show() method should probably be .__str__() instead.

I'm not convinced of the benefit of requiring multiple calls to .add_field() to set up the structure.  I'd prefer to have the constructor accept the field specification as a list of 2-tuples.  Not only would the calling code be cleaner, but the implementation of the structure class would be simpler as well if it is immutable.

I'm not a fan of your printed warnings.  Utility code, such as this, has absolutely no business contaminating sys.stdout, and ideally shouldn't print to sys.stderr either.  An end user would be completely clueless about what to do about these "warnings".  A programmer would also be puzzled about where these warnings came from (if it's a large program) and what actually happened as a consequence.  Rather, you should decide to either tolerate these situations gracefully or raise exceptions.  In my opinion…


"Field with name … already exists" should raise an ArgumentError.
"Format cannot be an empty string" should be tolerated (or perhaps an assertion failure).
"There is no such field" would be eliminated altogether based on my suggestion to return an OrderedDict.  If you had to offer a .get_value() method, then you should just let the KeyError propagate.