[Feature Request] Flesh out Base64 module

[lsh]

Review Mojo's priorities

• [X] I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

Right now the Base64 module only has b64encode.

Ideally we'd at least have

alias Bytes = DynamicVector[UInt8] # in lieu of a more specific type
fn b64decode(bytes: borrowed Bytes) -> Bytes
fn b64encode(bytes: borrowed Bytes) -> String
fn b16decode(bytes: borrowed Bytes) -> Bytes
fn b16encode(bytes: borrowed Bytes) -> String

What is your motivation for this change?

These methods are foundational for working with Cryptography.

Any other details?

I think Base64 is not a great name for this module.

Consider:

import Base64

# redundant
Base64.b64encode(bytes)

# strange
Base64.b16encode(bytes)

I think simply Encodings would be a good name.

[drunkwcodes]

But encoding in python is usually used as string to bytes encoding, such as utf-8, GB 2312, Big5 etc.

b16encode is also in base64 module in python, so I think it's fine to add those functions in Base64 module in mojo.

[lsh]

But encoding in python is usually used as string to bytes encoding, such as utf-8, GB 2312, Big5 etc.

I'm not sure this a particularly compelling argument. Python also uses errors as a common key word argument name, but I still think the Error module is descriptively named.

But I also don't want to distract from the main issue, and it was more of an offhand comment, so it might be best to move this somewhere else.

[drunkwcodes]

@lsh I can not recall errors kwarg in python standard libraries. But errors are errors, there are no ambiguity. Character encoding and base64 encoding are almost two totally different categories.

This kind of incompatibility with python is a non-starter for me. C'mon, SUPERSET! So Base64 is the best name for the module.

The module names with PascalCase are confusing me that they seem to be callable, like python classes. But this is trivial.

If this feature is pending to post-release, I'm willing to contribute to this module.

[gryznar]

Being a superset does not mean, that Mojo should copy Python 1:1. It only means, that Mojo should be compatible with Python. It is a big opportunity to do some stuff better in stdlib

[drunkwcodes]

What's the opportunities?

I like Python stdlib, though the ecosystem is better. They are all decent. They are the GOAT!

Copy them then there is no discount on quality. Stealing them is necessity if there is no license. They are so gorgeous.

[ksandvik]

This will also help with code migration, keep it in .py until changing the code to .mojo and the mojo rules. Also makes a good demarcation between python 1:1 and mojo specific features.

[ksandvik]

Oh, I just realized that having a mixture of .py and .mojo code could cause issues with LSP, debuggers, code formatters and so on...