<story><title>PyParallel: How we removed the GIL and exploited all cores</title><url>https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores</url></story><parent_chain><item><author>jnbiche</author><text>I&amp;#x27;m really glad to see some of the Python committers taking a serious look at the GIL.  Python is either posed for great victory (given its rapid rate of adoption in academia) or slow failure (given the rapid rate at which server apps are starting to migrate from Python to Go).&lt;p&gt;However, between accomplishments like Micropython (huge potential for Python on mobile&amp;#x2F;resource constrained devices) , PyPy&amp;#x27;s slow but steady gains, and projects like this, it&amp;#x27;s at least an interesting time for Pythonistas.&lt;p&gt;Now, if we could only get an optional static type checker... (heresy, I know).  Dynamic typing is great for quick prototyping, and I would never want to lose that in Python, but I&amp;#x27;m very uneasy now taking on any large projects or long-term projects without static typing. Mypy holds some promise here, but I think it will take sponsorship from a big company to push something like this to a mature state.</text></item></parent_chain><comment><author>masklinn</author><text>&amp;gt; I&amp;#x27;m really glad to see some of the Python committers taking a serious look at the GIL.&lt;p&gt;People have been taking serious looks at the GIL for a long time (there were technically working GIL-less versions of 1.5). The issue has never been that no one wanted to work on it (let alone that it was impossible), but that so far the single-threaded performance hit has been too large to be acceptable to the core team.&lt;p&gt;&amp;gt; Now, if we could only get an optional static type checker... (heresy, I know).&lt;p&gt;Er… how would that be heretic when Python 3&amp;#x27;s annotations were introduced to support exactly this?</text></comment>
<story><title>PyParallel: How we removed the GIL and exploited all cores</title><url>https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores</url></story><parent_chain><item><author>jnbiche</author><text>I&amp;#x27;m really glad to see some of the Python committers taking a serious look at the GIL.  Python is either posed for great victory (given its rapid rate of adoption in academia) or slow failure (given the rapid rate at which server apps are starting to migrate from Python to Go).&lt;p&gt;However, between accomplishments like Micropython (huge potential for Python on mobile&amp;#x2F;resource constrained devices) , PyPy&amp;#x27;s slow but steady gains, and projects like this, it&amp;#x27;s at least an interesting time for Pythonistas.&lt;p&gt;Now, if we could only get an optional static type checker... (heresy, I know).  Dynamic typing is great for quick prototyping, and I would never want to lose that in Python, but I&amp;#x27;m very uneasy now taking on any large projects or long-term projects without static typing. Mypy holds some promise here, but I think it will take sponsorship from a big company to push something like this to a mature state.</text></item></parent_chain><comment><author>ak217</author><text>There are a lot of ideas out there on how to do optional runtime type checking in a Pythonic way. My contribution is ensure (&lt;a href=&quot;https://github.com/kislyuk/ensure&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;kislyuk&amp;#x2F;ensure&lt;/a&gt;), for example check out the ensure_annotations decorator (&lt;a href=&quot;https://ensure.readthedocs.org/en/latest/#ensure.ensure_annotations&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ensure.readthedocs.org&amp;#x2F;en&amp;#x2F;latest&amp;#x2F;#ensure.ensure_anno...&lt;/a&gt;).</text></comment>