[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?] (original) (raw)

Bengt Richter bokr at oz.net
Fri Feb 17 18:28:45 CET 2006

On Fri, 17 Feb 2006 00:33:49 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:

Josiah Carlson wrote:

I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex', and likely a few others that the two of you may be arguing against should stay as encodings, because strictly speaking, they are defined as encodings of data. They may not be encodings of unicode data, but that doesn't mean that they aren't useful encodings for other kinds of data, some text, some binary, ... To support them, the bytes type would have to gain a .encode method, and I'm -1 on supporting bytes.encode, or string.decode. Why is s.encode("uu") any better than binascii.b2auu(s) One aspect is that dotted notation method calling is serially composable, whereas function calls nest, and you have to find and read from the innermost, which gets hard quickly unless you use multiline formatting. But even then you can't read top to bottom as processing order.

If we had a general serial composition syntax for function calls something like unix piping (which is a big part of the power of unix shells IMO) we could make the choice of appropriate composition semantics better.

Decorators already compose functions in a limited way, but processing order would read like forth horizontally. Maybe '->' ? How about

foo(x, y) -> bar() -> baz(z)

as as sugar for

baz.__get__(bar.__get__(foo(x, y))())(z)

? (Hope I got that right ;-)

I.e., you'd have self-like args to receive results from upstream. E.g.,

def foo(x, y): return 'foo(%s, %s)'%(x,y) ... def bar(stream): return 'bar(%s)'%stream ... def baz(stream, z): return 'baz(%s, %s)'%(stream,z) ... x = 'ex'; y='wye'; z='zed' baz.get(bar.get(foo(x, y))())(z) 'baz(bar(foo(ex, wye)), zed)'

Regards, Bengt Richter

More information about the Python-Dev mailing list