I dunno, I think this might be useful.  A binary representation is itself a
string, and takes formatting as such (ditto for hex, as hex(int()) returns
a string:

In [20]: a
Out[20]: IPv4Address('1.2.3.4')

In [92]: f'{a}'
Out[92]: '1.2.3.4'

In [21]: int(a)
Out[21]: 16909060

In [22]: f'{bin(int(a)):42s}'
Out[22]: '0b1000000100000001100000100               '

In [24]: f'{a:b}'
Out[24]: '00000001000000100000001100000100'

In [25]: f'{a:b42s}'
Out[25]: '1.2.3.4'

That last one should return '1000000100000001100000100            '.  I was
worried about going down a really deep rabbit hole trying to support a lot
of string format stuff with no use case, but there's not much more which
could be done which makes any sense.  's' seems reasonable.

My current code supports [b, x, n] integer presentation types.  I need to
add [X], that's just an oversight.  Supporting [b, x, X, n] means that an
IP address is considered an integer, and should get the subset of integer
presentations which make sense. Not the full set - neither octal nor
character are good fits.  But support for some sort of alignment padding
seems reasonable.  Consider:

In [61]: f'{42:30}'
Out[61]: '                            42'

In [62]: f'{int(a):30}'
Out[62]: '                      16909060'

In [63]: f'{a:30}'
Out[63]: '1.2.3.4'

In [66]: f'{a:42b}'
Out[66]: '00000001000000100000001100000100'

Those last two seem odd.  I think f'{a:30}' should return the same thing as
this:

In [69]: f'{str(a):30}'
Out[69]: '1.2.3.4                       '

and f'{a:42b'} should return the same thing as this:

In [77]: f'{bin(int(a)):42}'
Out[77]: '0b1000000100000001100000100               '

This also means supporting [>,<,^] alignment.  And, of course, ignoring any
length spec too short, as is done with regular integer formatting:

In [86]: b
Out[86]: 16909060

In [87]: f'{b:6}'
Out[87]: '16909060'

Thoughts?

eric