<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 1 Feb 2018 at 07:34 Pau Freixes <<a href="mailto:pfreixes@gmail.com">pfreixes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Maybe it is happening but not in the way that you would expect<div dir="auto"><br></div><div dir="auto"><a href="https://mail.python.org/pipermail/python-dev/2018-January/152029.html" target="_blank">https://mail.python.org/pipermail/python-dev/2018-January/152029.html</a><br></div><div dir="auto"><br></div></div></blockquote><div><br></div><div>As one of the people who works at Microsoft and has Steve as a teammate I'm well aware of what MS contributes. :) My point is even with the time Steve, me, and our fellow core devs at MS get to spend on Python, it still pales in comparison to what some other languages get with dedicated staffing.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">Anyway, do we conclude, or at least a significant part, that is something desiderable but some constraints do not allow to work on that?</div></div></blockquote><div><br></div><div>I'm not sure what you're referencing as "something desirable", but I think we all want to see Python improve if possible.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Also, more technically Iwouls like to have your point of view of two questions, sorry if these sound kind stupid.</div><div dir="auto"><br></div><div dir="auto">1) Is CPython 4 a good place to start to think on make the default execution mone debuggale. Having an explicit -g operand that by default is disabled, shouldnt be an open window for changing many thinks behind the scenes?</div></div></blockquote><div><br></div><div>Don't view Python 4 as a magical chance to do a ton of breaking changes like Python 3.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">2) Regarding the Yuris proposal to cache bultin functions, why this strategy cant be used for objects and their attributes within the function scope? Technically which is the red flag?</div></div></blockquote><div><br></div><div>Descriptors are the issue for attributes. After that it's a question of whether it's worth the overhead of other scope levels (built-ins are somewhat unique in that they are very rarely changed).<br><br></div><div>The key point is that all of this requires people's time and we just don't have tons of that available at the moment.<br></div><div><br></div><div>-Brett<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Cheers,</div></div><div class="gmail_extra"><br><div class="gmail_quote">El 29/01/2018 18:10, "Brett Cannon" <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 27, 2018, 23:36 Pau Freixes, <<a href="mailto:pfreixes@gmail.com" target="_blank">pfreixes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> At a technical level, the biggest problems relate to the way we<br>
> manipulate frame objects at runtime, including the fact that we expose<br>
> those frames programmatically for the benefit of debuggers and other<br>
> tools.<br>
<br>
Shoudnt be something that could be tackled with the introduction of a<br>
kind of "-g" flag ? Asking the user to make explicit that is willing<br>
on having all of this extra information that in normal situations<br>
won't be there.<br>
<br>
><br>
> More broadly, the current lack of perceived commercial incentives for<br>
> large corporations to invest millions in offering a faster default<br>
> Python runtime, the way they have for the other languages you<br>
> mentioned in your initial post :)<br>
<br>
Agree, at least from my understanding, Google has had a lot of<br>
initiatives to improve the JS runtime. But at the same moment, these<br>
last years and with the irruption of Asyncio many companies such as<br>
Facebook are implementing their systems on top of CPython meaning that<br>
they are indirectly inverting on it.<br></blockquote></div><div><br></div><div>I find that's a red herring. There are plenty of massive companies that have relied on Python for performance-critical workloads in timespans measuring in decades and they have not funded core Python development or the PSF in a way even approaching the other languages Python was compared against in the original email. It might be the feeling of community ownership that keeps companies from making major investments in Python, but regardless it's important to simply remember the core devs are volunteers so the question of "why hasn't this been solved" usually comes down to "lack of volunteer time".</div><div><br></div><div>-Brett</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
--pau<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>