Change the type of the 'immutable' parameter to boolean

[LeXofLeviafan]

As of now, several BukuDb methods (add_rec(), update_rec(), edit_update_rec()) accept an optional parameter named immutable of integer type. This parameter is functionally boolean (signifying a yes/no condition), so I suggest changing the actual type to boolean as well.

The value corresponds with bit flags, but those check for the exact value anyway, so it's perfectly possible to use the values directly when working with flags (…or better yet, a named constant: IMMUTABLE = 0x01).

The parameter can be made nullable to account for the "noop" value (with explicit is None checks instead of non-transparent == -1 comparisons). …Incidentally, isn't that precisely what Optional is supposed to accomplish? (It's already used in most type definitions of immutable… even though there doesn't seem to be anything in the code to account for it)

P.S. BTW, is this flag ever used/displayed in bukuserver UI? If not, this seems like missing interop between the GUI and the library (i.e. if a user wants to edit individual bookmarks in GUI but apply batch updates via CLI… which appears to be a feature missing in the GUI as well).

[LeXofLeviafan]

As for the argument parsing, the following implementation would retain current CLI behaviour while producing Optional[bool] internally:

def _immutable (s):
    if s not in {'0', '1'}:
        raise argparse.ArgumentTypeError(f'invalid choice: {s} (choose from 0, 1)')
    return s == '1'

addarg('--immutable', type=_immutable, help=hide)

…Alternatively, the following can be done instead; but it would change error output slightly (by adding single-quotes around the values). Then again, neither case prints out the "invalid int value" (can be added manually, I suppose).

class _Immutable(argparse.Action):
    def __call__ (self, parser, namespace, values, option_string=None):
        setattr(namespace, self.dest, values == '1')

addarg('--immutable', choices={'0', '1'}, action=_Immutable, help=hide)

And of course, there's also the option of using y/n as argument values (instead of 1/0). Those are certainly more conventional.

[jarun]

Don't change anything if there is no functional difference. I don't want unnecessary cosmetic changes.

[LeXofLeviafan]

This isn't about cosmetics though – it's about the types used in the API matching their functional purpose.

[jarun]

Third party utilities may already be calling this. Too late to change.