[Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

[Joseph Hackman]

Yes I do think this is precisely where a lazy or delayed feature would work well. I'm working on writing up a complete PEP now, and have made some progress on the things left unsolved in the other thread. I will post again when the PEP is closer to complete. 

Fundamentally, anything can be done, but I don't think that altering the code of others for one case is Pythonic, and though it happens, I think there is value in making it less necessary. 

Cheers!
Joseph

> On Feb 28, 2017, at 9:46 AM, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
> 
> 
>> Le 28/02/2017 à 13:47, Markus Meskanen a écrit :
>>    You don't need list comprehension, you can use a for loop.
>> 
>>    You don't need upacking you can use indexing.
>> 
>>    And you don't need lazy, it's just convenient.
>> 
>> 
>> With this sole argument you can add almost anything to the language as
>> long as it has at least one use case where it's better than existing
>> tools. I'm not against the lazy proposal in general, but attempting to
>> justify a new keyword to replace this is just silly to me:
>> 
>> class Config(dict):
>>    def lazy_get(self, key, callable=None):
>>        if key in self:
>>            return self[key]
>>        return callable(key)
> 
> With this sole argument you can reject await / async because we could do
> it with yield from and decorator.
> 
> With this solve argument you can reject comprehension because we have
> map and filter.
> 
> With this solve argument you can reject defauldict because we can code
> one ourself.
> 
> I mean come on, a decorator is just:
> 
> @decorator
> def decorated():
> 
> Instead of
> 
> decorated = decorator(decorated)
> 
> It's just convenience and elegance.
> 
> The sweet spot for lazy is a use case where you can't easily modify the
> code to get your getter and setter. You example again makes the
> assumption you can easily add such a wrapper. But if you can't, then you
> have to import it and wrap the config object in every module using it.
> Test all that. Ensure you don't pass the wrapper by accident to
> something that would break on it, etc.
> 
> And how many time do you have to do that ?
> 
> You will write your wrapper for lists ? And tuples ?
> 
> And will you test those ? document those ? Explain to others that to get
> a callable, you need to pass a callable returning a callable ?
> 
> Then again for your next project or you do a library with all the stuff
> it implies ?
> 
> It's neither convenient nor elegant.
> 
> lazy is not only practical, but it's also beautiful. It reads well. It
> solves a problem we all have on a regular basis.
> 
> Yes we can live without it. I mean, Python is already incredibly
> convenient, of course whatever we suggest now is going to be a cherry on
> top of the language cake.
> 
> And yes I got a big mouth because it's a lot of work to implement it and
> it's work I'm not capable to do since I can't code in C to save my life.
> 
> Does it removes the merits from lazy ?
> 
> Wouldn't you like it to just be able to drop "lazy" in your next 3.7 code ?
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/