PEP 3101 (Advanced string formatting) base 36 integer presentation type
I would like to suggest adding an integer presentation type for base 36 to PEP 3101. I can't imagine that it would be a whole lot more difficult than the existing types. Python's builtin long integers provide a nice way to prototype and demonstrate cryptographic operations, especially with asymmetric cryptography. (Alice and Bob stuff.) Builtin functions provide modular reduction, modular exponentiation, and lots of nice number theory stuff that supports a variety of protocols and algorithms. A frequent need is to represent a message by a number. Base 36 provides a way to represent all 26 letters in a semistandard way, and simple string transformations can efficiently make zeros into spaces or vice versa. long() can already take a radix argument of 36 to parse base 36 numbers. If a base 36 presentation type (say, 'z' or something) was available, it would be possible to base 36 numbers as a simple way to interpret a message as a number in number theoretic/asymmetric cryptographic applications. The standard answer (see, for example, the Wikipedia Base 36 article) is to code up a quick routine to loop around and generate each digit, but:  The kinds of numbers used in cryptographic applications are big, as in thousands of digits. Providing some sort of direct support would nicely facilitate computational efficiency as it would avoid going around an interpreted loop thousands of times for each conversion.  All the the examples I've seen on in a quick Google search use the horrible antiidiom of building up a string by repeated concatenation. Obviously, doing it efficiently is not trivial. It would be nice to get it right and be done with it.  Yes, one could write his own routine to do it, but this would serve as an unnecessary distraction where the purpose of the code is to illustrate a cryptographic algorithm or protocol  Yes, one could write his own module, define his own type, and override everything, but it's a fair amount of work to cover everything off (longs are a part of the language's core syntax) and even then, you still have the clutter of manually invoking constructors to make your new type instead of the builtint type. It's also kind of a trivial thing to justify promulgating a standard module for, and without a standard module, it's one more preliminary that has to be done before you can get to the main algorithm.  "Batteries included" is kind of a nice philosophy. Is it practical to add a base36 integer presentation type (say, 'z' or 'Z' similar to hexadecimal's 'x' or 'X') to the existing integer presentation types list in PEP 3101 (or do I need to raise a brand new PEP for this neartriviality)? It would be a very parallel thing to the hexadecimal one which is doing almost all the same things. I can't imagine it breaking anything because it defines something new that previously wasn't defined as anything useful at all. Jeffrey <jss.bulk@@gmail.com <mailto:jeffrey.streifling@gmail.com>>
On Fri, Oct 7, 2011 at 8:14 PM, Jeffrey <jss.bulk@gmail.com> wrote:
I would like to suggest adding an integer presentation type for base 36 to PEP 3101. I can't imagine that it would be a whole lot more difficult than the existing types. <snip> Is it practical to add a base36 integer presentation type (say, 'z' or 'Z' similar to hexadecimal's 'x' or 'X') to the existing integer presentation types list in PEP 3101 (or do I need to raise a brand new PEP for this neartriviality)? It would be a very parallel thing to the hexadecimal one which is doing almost all the same things.
Related past discussions, albeit focused on arbitraryradix solutions: http://mail.python.org/pipermail/pythonideas/2009August/005611.html http://mail.python.org/pipermail/pythonideas/2009September/005727.html http://mail.python.org/pipermail/pythondev/2006January/059789.html http://bugs.python.org/issue6783 Cheers, Chris  http://rebertia.com
On Fri, 07 Oct 2011 21:14:44 0600 Jeffrey <jss.bulk@gmail.com> wrote:
I would like to suggest adding an integer presentation type for base 36 to PEP 3101. I can't imagine that it would be a whole lot more difficult than the existing types. Python's builtin long integers provide a nice way to prototype and demonstrate cryptographic operations, especially with asymmetric cryptography. (Alice and Bob stuff.) Builtin functions provide modular reduction, modular exponentiation, and lots of nice number theory stuff that supports a variety of protocols and algorithms. A frequent need is to represent a message by a number. Base 36 provides a way to represent all 26 letters in a semistandard way, and simple string transformations can efficiently make zeros into spaces or vice versa.
Why base 36 rather than, say, base 64 or even base 80?
Antoine Pitrou wrote:
On Fri, 07 Oct 2011 21:14:44 0600 Jeffrey <jss.bulk@gmail.com> wrote:
I would like to suggest adding an integer presentation type for base 36 to PEP 3101. I can't imagine that it would be a whole lot more difficult than the existing types. Python's builtin long integers provide a nice way to prototype and demonstrate cryptographic operations, especially with asymmetric cryptography. (Alice and Bob stuff.) Builtin functions provide modular reduction, modular exponentiation, and lots of nice number theory stuff that supports a variety of protocols and algorithms. A frequent need is to represent a message by a number. Base 36 provides a way to represent all 26 letters in a semistandard way, and simple string transformations can efficiently make zeros into spaces or vice versa.
Why base 36 rather than, say, base 64 or even base 80?
Because there are 26 ascii letters and 10 ascii digits? ~Ethan~
On Sat, 08 Oct 2011 08:44:52 0700 Ethan Furman <ethan@stoneleaf.us> wrote:
Antoine Pitrou wrote:
On Fri, 07 Oct 2011 21:14:44 0600 Jeffrey <jss.bulk@gmail.com> wrote:
I would like to suggest adding an integer presentation type for base 36 to PEP 3101. I can't imagine that it would be a whole lot more difficult than the existing types. Python's builtin long integers provide a nice way to prototype and demonstrate cryptographic operations, especially with asymmetric cryptography. (Alice and Bob stuff.) Builtin functions provide modular reduction, modular exponentiation, and lots of nice number theory stuff that supports a variety of protocols and algorithms. A frequent need is to represent a message by a number. Base 36 provides a way to represent all 26 letters in a semistandard way, and simple string transformations can efficiently make zeros into spaces or vice versa.
Why base 36 rather than, say, base 64 or even base 80?
Because there are 26 ascii letters and 10 ascii digits?
That's not really answering the question. Are people used to reading and manipulating numbers in base 36? If not, why not use the most compact representation? (if you are not interested in the most compact representation, then you can simply use base 10 or 16) Regards Antoine.
participants (4)

Antoine Pitrou

Chris Rebert

Ethan Furman

Jeffrey