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 <desmoulinmic...@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
