config: make type conversion explicit

[carlosmn]

The type of a config value depends on the tool that interprets
it. Parsing eagerly can lead to a situation where we return a bool
instead of a string or a number.

Let the user specify the type themselves by passing in a (str, type)
tuple into the mapping interface.

[carlosmn]

Well, it seems on python 2 I can only use long, but in python 3, I can only use int. Is there something short of a string that I can use here?

[carlosmn]

Looks like int should actually work everywhere, but I'm using a bad check.

[jdavid]

The API troubles me. The mapping interface is key: value, but the type is not part of the key. This should be implemented as a method.

[carlosmn]

I was trying to stay within the mapping interface, but you're right that it's mixing two different pieces of information.

[carlosmn]

Changed API to have get_bool() and get_int(). The mapping interface returns a string.

Would you like me to squash this into one?

[jdavid]

If anything I would remove the mapping interface and implement get_str() instead, to make the API consistent.

By the way, I get an error building the documentation:

$ make html
    ...
    .../pygit2/docs/config.rst:27: ERROR: Unknown interpreted text role "method".
    .../pygit2/docs/config.rst:27: ERROR: Unknown interpreted text role "method".
    ...

[carlosmn]

This is what happens when you assume instead of setting up paths correctly. For whatever reason the keyword for method is meth instead of method. I'll push up a fix.

[carlosmn]

Re dropping mapping: asking for a single value as a string is a very common operation, which corresponds quite well to dictionary access (even if there's some funky logic as to how the key gets hashed), so I'd like to keep it.

The other operations exist mostly because the config format has its own rules as to what constitutes a boolean value and integers have their own suffix rules.

We could also go the route of providing static functions that expose the parsing, which would get rid of multiple ways of accessing the value itself but still let the user parse with git-config rules, something like

    Config.parse_int(config['core.deltabasecachelimit'])

This would also let the user apply these rules to data that doesn't come directly from the config but which has the same semantics. Come to think of it, we should expose this anyway and then we can think about whether get_{int,bool} should be removed.

[jdavid]

Okey.

By the way, I guess the config stuff is also a good candidate for cffi.

[carlosmn]

Yeah, that's what I was thinking as well. There's a bit of bootstrapping that it needs, but once the remote-cffi PR is merged, I can start working on that.