RFC: arbitrary transformation for renderables

[Роман Донченко]

I don't see how that would work.

IMO, renderer and Transform are very different things. The former creates  
a new renderable based on a user-defined function; the latter combines  
existing renderables based on a user-defined transformation. They can't  
(and shouldn't) be implemented by the same function.

Dustin J. Mitchell <dustin at v.igoro.us> писал в своём письме Sun, 04 Oct  
2015 16:55:46 +0300:

> Could you possibly extend renderer to handle that case?
>
> Dustin
>
> On Fri, Oct 2, 2015 at 4:17 PM, Роман Донченко <dpb at corrigendum.ru>  
> wrote:
>
>> Pierre Tardy <tardyp at gmail.com> писал в своём письме Fri, 02 Oct 2015
>> 00:25:36 +0300:
>>
>> Hi Roman,
>>>
>>> There is already a renderer function which is similar simplification of
>>> the
>>> renderable pattern.
>>> You can do
>>>
>>> renderer(lambda _: datetime.date.today().isoformat()
>>> renderer(lambda b: os.path.relpath(p.getProperty('buildir'))
>>>
>>> The latter is a little bit more chars than your solution, but probably
>>> more
>>> easy to follow.
>>>
>>
>> I know this, but it doesn't work when the arguments are arbitrary
>> renderables (since you have to account for the possibility that they  
>> return
>> a Deferred). The brevity is nice to have, too.
>>
>> _______________________________________________
>> devel mailing list
>> devel at buildbot.net
>> https://lists.buildbot.net/mailman/listinfo/devel