Suggest changing base64 module to better handle encoding schemes that don't use padding. 
Because RFC4648 [1] allows other RFCs that implement RFC4648-compliant base64url encoding to explicitly stipulate that there is no padding. Dropping the padding is lossless when we know the length [2].
Various standard specifications require this - often crypto related (e.g., JWS [3] or named hashes [4]).

RFC4648 specifically makes an exemption for this and it should be better supported in Python's standard library. There is a related closed issue [5] asking for the padding to be removed or altered which wouldn't comply with the spec. This request is different with a view to better support the wider specification.

Proposed behaviour adapted from resolution that ruby discussion on same topic [6]:

- base64.urlsafe_b64encode(s) should continue to produce padded output, but have an additional argument, padding, which defaults to True.
- base64.urlsafe_b64decode(s) should accept both padded and unpadded inputs. It can still reject incorrectly-padded input.


If that sounds sensible I'd like to put a patch/PR together.

From wikipedia [7]:

> Some variants allow or require omitting the padding '=' signs to avoid them being confused with field separators, or require that any such padding be percent-encoded. Some libraries will encode '=' to '.'.

- [1] https://tools.ietf.org/html/rfc4648#page-4
- [2] http://stackoverflow.com/questions/4080988/why-does-base64-encoding-requires-padding-if-the-input-length-is-not-divisible-b
- [3] https://tools.ietf.org/html/rfc7515
- [4] https://tools.ietf.org/html/rfc6920#section-3
- [5] http://bugs.python.org/issue1661108 
- [6] https://bugs.ruby-lang.org/issues/10740
- [7] https://en.wikipedia.org/wiki/Base64#Output_Padding