extension color_type returns long

[Neon22]

When making an extension the user can select type color.
e.g. in inx file:
<!-- color is just like an int. BUT only single use on a page-->
<param name="strokeColour" type="color" gui-text="Line colour: ">0</param>

In py file:
self.OptionParser.add_option('-f', '--strokeColour', action = 'store',
                                     type = 'string', dest = 'strokeColour',
                                     default = 896839168, # Blue (see below how to discover value to put here)
                                     help = 'The line colour.')

Type does not affect result. The value returned is a signed long. It should be a string in color form.

This signed value can be converted by this function into a color string.
def getColorString(self, longColor, verbose=False):
        """ Convert the long into a #RRGGBB color value
            - verbose=true pops up value for use in defaults
            conversion back is A + B*256^1 + G*256^2 + R*256^3
        """
        if verbose: inkex.debug("%s ="%(longColor))
        longColor = long(longColor)
        if longColor <0: longColor = long(longColor) & 0xFFFFFFFF
        hexColor = hex(longColor)[2:-3]
        hexColor = '#' + hexColor.rjust(6, '0').upper()
        if verbose: inkex.debug(" %s for color default value"%(hexColor))
        return hexColor

Request:
It should be returning a string in form "#RRGGBB".
This would also mean the default value could be a color string. ATM it needs to be a signed long.

For compatibility with existing extensions - some solution needs to be worked out, or just break them and we will fix them.

[Neon22 (neon22)]

FWIW - I concur with su_v

[su_v (suv-lp)]

<opinion>
I'm personally opposed to this kind of API break to allow a more "readable" type for the default value to be specified - INX-based dialogs are used with built-in extensions (e.g. custom predefined filter effects, C++) as well as with script-based extensions bundled with Inkscape, and with an unknown number of externally developed and maintained custom extensions. The recent breakages (units, translations) were bad enough IMvHO - if possible, the project should attempt to prevent invalidating (built-in, bundled or custom) extensions (at least as long as there does not exist some kind of versioning scheme for extensions).
</opinion>

--
replaces comment #1 with proposal not relevant to the motivation of the requested API break (format for the default value).