<div dir="ltr">If you'd like help with the PEP, I'd be happy to assist (subject to time, as always the problem). I think this idea got pretty good support in the discussion (of course, I'm biased because it's one of the few proposed here that I actually really like). Few core developers really chimed in on the matter, so it's hard to say what they might opine about the implementation or supportability.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 10:08 AM, Joseph Hackman <span dir="ltr"><<a href="mailto:josephhackman@gmail.com" target="_blank">josephhackman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Cheers!<br>
<span class="HOEnZb"><font color="#888888">Joseph<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Feb 28, 2017, at 9:46 AM, Michel Desmoulin <<a href="mailto:desmoulinmichel@gmail.com">desmoulinmichel@gmail.com</a>> wrote:<br>
><br>
><br>
>> Le 28/02/2017 à 13:47, Markus Meskanen a écrit :<br>
>> You don't need list comprehension, you can use a for loop.<br>
>><br>
>> You don't need upacking you can use indexing.<br>
>><br>
>> And you don't need lazy, it's just convenient.<br>
>><br>
>><br>
>> With this sole argument you can add almost anything to the language as<br>
>> long as it has at least one use case where it's better than existing<br>
>> tools. I'm not against the lazy proposal in general, but attempting to<br>
>> justify a new keyword to replace this is just silly to me:<br>
>><br>
>> class Config(dict):<br>
>> def lazy_get(self, key, callable=None):<br>
>> if key in self:<br>
>> return self[key]<br>
>> return callable(key)<br>
><br>
> With this sole argument you can reject await / async because we could do<br>
> it with yield from and decorator.<br>
><br>
> With this solve argument you can reject comprehension because we have<br>
> map and filter.<br>
><br>
> With this solve argument you can reject defauldict because we can code<br>
> one ourself.<br>
><br>
> I mean come on, a decorator is just:<br>
><br>
> @decorator<br>
> def decorated():<br>
><br>
> Instead of<br>
><br>
> decorated = decorator(decorated)<br>
><br>
> It's just convenience and elegance.<br>
><br>
> The sweet spot for lazy is a use case where you can't easily modify the<br>
> code to get your getter and setter. You example again makes the<br>
> assumption you can easily add such a wrapper. But if you can't, then you<br>
> have to import it and wrap the config object in every module using it.<br>
> Test all that. Ensure you don't pass the wrapper by accident to<br>
> something that would break on it, etc.<br>
><br>
> And how many time do you have to do that ?<br>
><br>
> You will write your wrapper for lists ? And tuples ?<br>
><br>
> And will you test those ? document those ? Explain to others that to get<br>
> a callable, you need to pass a callable returning a callable ?<br>
><br>
> Then again for your next project or you do a library with all the stuff<br>
> it implies ?<br>
><br>
> It's neither convenient nor elegant.<br>
><br>
> lazy is not only practical, but it's also beautiful. It reads well. It<br>
> solves a problem we all have on a regular basis.<br>
><br>
> Yes we can live without it. I mean, Python is already incredibly<br>
> convenient, of course whatever we suggest now is going to be a cherry on<br>
> top of the language cake.<br>
><br>
> And yes I got a big mouth because it's a lot of work to implement it and<br>
> it's work I'm not capable to do since I can't code in C to save my life.<br>
><br>
> Does it removes the merits from lazy ?<br>
><br>
> Wouldn't you like it to just be able to drop "lazy" in your next 3.7 code ?<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</div>