On Fri, 17 Feb 2006 00:33:49 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> 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.b2a_uu(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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
