Would prefer if this constant was named for readability along with _FLOAT32_INVALID_VALUE:

_FLOAT32_RANGE = (-3.4028235e+38, 3.4028235e+38)

in_range=lambda x: x if _FLOAT32_RANGE[0] < x < _FLOAT32_RANGE[1] else _FLOAT32_INVALID_VALUE

Maybe should polish this part, maybe subclass BaseType and use merge in_range into unparse.

Can simplify by using the Iterable type from the collections module:

from collections import Iterable

def is_iterable(obj):
    return not isinstance(obj, (str, bytes)) and isinstance(obj, Iterable)

See https://stackoverflow.com/questions/1952464
isinstance(obj, Iterable) does not cover all use cases. However, for most of situations, isinstance is OK. Maybe should do it to speed up the code a bit.

Huh, I actually had no idea that defining __getitem__ on a class would cause it to become iterable. Seems like a legacy feature that was kept in for backwards compatibility after PEP234 was implemented. I did some tests in 2.7/3.6 and it seems that the basic types all implement __iter__ now so as long as custom classes do the same it should be fine.

The fitdump script is user-facing and should therefore convert units to SI by default. Getting the raw values from the file could be useful in some cases, but should be put behind a flag (--raw-values?) if it's going to be added.

This change is a mistake, thanks.

str is still used as a typecheck in get_messages in the following code:

names = set([
    int(n) if (isinstance(n, str) and n.isdigit()) else n
    for n in names
])

However, looking at it now, this code can probably be refactored to:

def try_int(obj):
    try:
        return int(obj)
    except ValueError:
        return obj

names = set(try_int(n) for n in names)

This would remove the typecheck so the shim wouldn't be needed.

IMO this code should be removed - the caller should make sure a message number is int, not str if wants to use the number.

@pR0Ps Should I remove this from the FitFile?

Any reason to not put these defaults in the function definition? Would be more self-documenting.

Not any reason, just a mistake, thanks.

In general, allowing multiple ways to specify a parameter can get confusing (how do they interact?). In this case I would either raise an error if the endianness is specified in both parameters or just not allow it in the fmt at all since (as far as I can tell) it's only used for the CRC.

IMO it's a design flaw in the fitparse base, already. E.g. see test.py func generate_fitfile() - there is copy&paste of the struct.pack spec for the FIT header and Crc. I've tried to fix that for Crc at least. But I can copy&paste the endianness for the Crc, too.

It doesn't look like this class allows for creating chained FIT files (basically multiple FIT files concatenated together, see the commit that added support for parsing them). Not saying it has to, just letting you know that it's a possibility since it's a bit of an obscure part of the spec.

In fact, if you want to support chained FIT files, it should probably be taken care of by higher-level code that basically just does an itertools.chain(*fileishs) for the fileishs written by this class.

Exactly, the code itself allows to append to a file, too. Just the file has to be opened by the user code. So, chaining is the task for the user code. Should not burden the core code.

I get that it shouldn't be done as part of the normal encoding since it's at a higher level than messing around with the bytes of the file, but that doesn't mean it can't be included in the library.

If it's a common operation, pushing it into user code just means that everyone is going to have to write their own implementation. A better way would be to provide all the functionality the user would need, but let them decide when to use it. For example, one way would be to have a small method chain on the class that does something like (untested):

def chain(self, *fits):
    if not self.completed:
        raise Exception("Can't chain more files onto an incomplete FIT file")

    for fit in fits:
        if isinstance(fit, FitFile):
            data = fit._file
        else:
            data = fileish_open(fit, 'rb')

        while True:
            block = data.read(BLOCK_SIZE)
            if not block:
                break
            self._write(block)

This way the library can check for issues (like appending data to an incomplete fit datastream) as well as handle compatibility with library objects (the FitFile shim), but it doesn't complicate the rest of the encoding process in any way.

You can already chain with this code:

with FitFileEncoder(open(fitname, 'ab') as fit:
   ...
with FitFileEncoder(open(fitname, 'ab') as fit:
   ...

I have not seen any particular support for chaining in the FIT SDK, I think they support it the same way.