🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 178 (from laksa053)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa178.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://www.infoworld.com/article/2338862/python-moves-to-remove-the-gil-and-boost-concurrency.html\')), getAhrefsUnparsedNoserviceFromURL(\'https://www.infoworld.com/article/2338862/python-moves-to-remove-the-gil-and-boost-concurrency.html\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/www.infoworld.com\/article\/2338862\/python-moves-to-remove-the-gil-and-boost-concurrency.html","crawl_time":1775691167,"first_indexed_time":1718587310,"http_code":200,"src_unparsed":"com,infoworld!www,\/article\/2338862\/python-moves-to-remove-the-gil-and-boost-concurrency.html s443","src_root_hash":"11067585635464083778","history_drop_reason":null,"meta_title":"Python moves to remove the GIL and boost concurrency | InfoWorld","meta_descriptions":["Formal plans for a Python that supports true parallelism are finally on the table. Here’s how a GIL-free Python will finally come together."],"attrs_boilerpipe_text":"news analysis\nAug 4, 2023\n7 mins\nAfter much debate, the Python Steering Council intends to approve a proposal,\nPEP 703\n, “Making the Global Interpreter Lock Optional in\nCPython\n.”\nThis proposal is the culmination of many attempts over the years to\nremove Python’s Global Interpreter Lock, or GIL\n. Removing the GIL removes a major obstacle to multi-threading, making Python a truly multi-core language and significantly improving its performance for workloads that benefit from parallelism.\nWith this proposal, first-class support for multi-threading and concurrency in Python is a step closer to becoming reality.\nWhy remove Python’s GIL?\nPython’s memory management system keeps track of object usage by maintaining counts of the number of references to each object. When the reference count for an object falls to zero, the object is slated for removal.\nBecause\nPython\nwas created at a time when multi-processor systems were a rarity, and multi-core processors were non-existent, this reference count mechanism isn’t thread-safe. Instead, Python achieves thread safety by allowing only one thread to access an object at a time. This is the purpose of the GIL.\nMany projects over the years have attempted to remove the GIL. They did enable multi-threaded programs to run faster, but at the cost of degrading the performance of single-threaded programs. Given the vast majority of Python applications are single-threaded, this was a poor trade-off. Although refinements to the GIL have improved its handling of multi-threaded apps, it’s still a serious bottleneck.\nPython’s core developers finally decided to remove the GIL from CPython, but only if it could be done without slowing down single-threaded programs.\nHow a GIL-free Python will work\nThe current proposals for a no-GIL edition of Python use a mix of techniques to make reference counting thread-safe, and leave the speed of single-threaded programs untouched or impact it only minimally.\nBiased reference counting.\nCounts for objects accessed by only a single thread would be handled differently (and more quickly) than counts for objects accessed by multiple threads. Since most objects are accessed by only one thread, the impact on single-threaded programs is minimized.\nImmortalization.\nSome objects, like\nNone\n, never need to be deallocated, so their reference counts do not need to be tracked.\nThread-safe memory allocation.\nA new memory allocation system for CPython objects will make it easier to trace objects in the garbage collector, and to allocate memory in a thread-safe way.\nDeferred reference counting.\nReference counts for some objects, like top-level functions in a module, can be safely deferred. This saves both time and resources.\nA revised garbage collector.\nThe CPython garbage collector cleans up cyclical object references, where two or more objects hold references to each other. The no-GIL build\nmakes many changes\nto the garbage collector, such as removing the “generations” system for tracking objects.\nHow a GIL-free Python will be phased in\nImplementing PEP 703 is a long-term project that will take place in multiple stages over several years. During this time, the CPython interpreter will transition to make the no-GIL version first optional, then supported, and finally the standard version of CPython.\nTo accomplish this, CPython’s developers will add an experimental “no-GIL”\nbuild\nmode to CPython, so that one can compile a version of CPython with or without the GIL. Eventually, the no-GIL build will become the default.\nHere is how the plan to remove the GIL from CPython is set to unfold.\nStep 1: No-GIL CPython is optional\nThe first incarnations of a no-GIL CPython will be experimental, for both CPython developers and the larger Python community. This experimental phase has several goals:\nGet the rest of the Python community involved.\nAny major change to Python needs buy-in from the wider Python community. The experimental builds give Python users a way to safely experiment with testing their code, and to see how both non-threaded and threaded code will behave.\nGive Python distributions the option, not the requirement, to ship a GIL-less Python.\nPython distributions like Conda or WinPython need to guarantee compatibility with stock CPython. During the transition phase, they could provide the option to install the regular or GIL-less version of CPython. This would allow Conda or WinPython users to pick the version most compatible with their needs.\nDetermine whether the no-GIL project is worthwhile.\nIf the community tries out the GIL-less builds at scale and is unhappy with the results, the core CPython developers reserve the right to back out. Having dual builds means a heavier maintenance burden in the short term, but provides an escape hatch if the no-GIL project proves unworthy.\nStep 2: No-GIL CPython is supported\nThe next stage will be to offer the no-GIL build as a supported alternative build for CPython. A user would have the choice of installing either the no-GIL or GIL build, with either one being a formally supported version of CPython that receives bug fixes, security patches, and updates.\nOne big goal of this stage is to set a target date for making no-GIL the default. This will likely happen on the same timeline as the deprecation and removal of other Python features—at least two or three versions, meaning at least two or three years.\nStep 3: No-GIL CPython is the default\nThe final stage would be to make the no-GIL version of CPython the default build, and to remove\nall\nGIL-related code from CPython. “We don’t want to wait too long with this,”\nwrote Thomas Wouters\n, CPython core developer, “because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.”\nThe biggest challenges to removing the GIL\nThe biggest challenges present in this plan aren’t only technical, although the technical challenges are daunting. What looms even larger is how to bring the rest of the Python ecosystem into line with these changes—and make sure a GIL-less Python doesn’t create more problems than it solves.\nAccording to Wouters, “… any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).”\nThe other big challenge, as mentioned above, is “to bring along the rest of the Python community,” said Wouters, “… and make sure the changes we want to make, and the changes we want them to make, are palatable.\n“Before we commit to switching entirely to the no-GIL build, we need to see community support for it,” Wouters said. “We can’t just flip the default and expect the community to figure out what work they need to do to support it.”\nThe Python community experienced huge growing pains when transitioning from Python 2 to Python 3, so any big changes like removing the GIL would have to be thoroughly backwards compatible. As Wouters put it, “We do not want another Python 3 situation.”\nBeyond the perils and challenges lies a great reward: A Python that finally supports the parallelism that programmers have come to expect in the 21st century.\nSenior Writer\nSerdar Yegulalp is a senior writer at\nInfoWorld\n. A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024\nNeal Award\nand a 2025\nAzbee Award\nfor best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly\nDev with Serdar\nvideos for programming tips and techniques and close looks at programming libraries and tools.\nMore from this author","attrs_markdown":"1. Topics\n2. [Latest](https:\/\/www.infoworld.com\/news\/)\n3. [Newsletters](https:\/\/www.infoworld.com\/newsletters\/signup\/)\n4. [Resources](https:\/\/us.resources.infoworld.com\/)\n5. [Buyer’s Guides](https:\/\/www.infoworld.com\/enterprise-buyers-guide\/)\n\n## About\n- [About Us](https:\/\/www.infoworld.com\/about-us\/)\n- [Advertise](https:\/\/foundryco.com\/our-brands\/infoworld\/)\n- [Contact Us](https:\/\/www.infoworld.com\/contact-us\/)\n- [Editorial Ethics Policy](https:\/\/www.infoworld.com\/editorial-ethics-policy\/)\n- [Foundry Careers](https:\/\/foundryco.com\/work-here\/)\n- [Newsletters](https:\/\/www.infoworld.com\/newsletters\/signup\/)\n- [Reprints](https:\/\/www.infoworld.com\/contact-us\/#republication-permissions)\n- [Add InfoWorld as a Preferred Source in Google Search](https:\/\/www.google.com\/preferences\/source?q=infoworld.com)\n\n## Policies\n- [Terms of Service](https:\/\/foundryco.com\/terms-of-service-agreement\/)\n- [Privacy Policy](https:\/\/foundryco.com\/privacy-policy\/)\n- [Cookie Policy](https:\/\/foundryco.com\/cookie-policy\/)\n- [Copyright Notice](https:\/\/foundryco.com\/copyright-notice\/)\n- [Member Preferences](https:\/\/www.infoworld.com\/member-preferences\/)\n- [About AdChoices](https:\/\/foundryco.com\/ad-choices\/)\n- [Your California Privacy Rights](https:\/\/foundryco.com\/ccpa\/)\n\n## Our Network\n- [CIO](https:\/\/www.cio.com\/)\n- [Computerworld](https:\/\/www.computerworld.com\/)\n- [CSO](https:\/\/www.csoonline.com\/)\n- [Network World](https:\/\/www.networkworld.com\/)\n\n## More\n- [News](https:\/\/www.infoworld.com\/news\/)\n- [Features](https:\/\/www.infoworld.com\/features\/)\n- [Blogs](https:\/\/www.infoworld.com\/blogs\/)\n- [BrandPosts](https:\/\/www.infoworld.com\/brandposts\/)\n- [Events](https:\/\/www.infoworld.com\/events\/)\n- [Videos](https:\/\/www.infoworld.com\/videos\/)\n- [Enterprise Buyer’s Guides](https:\/\/www.infoworld.com\/enterprise-buyers-guide\/)\n\nClose\n\n- [Analytics](https:\/\/www.infoworld.com\/analytics\/)\n- [Artificial Intelligence](https:\/\/www.infoworld.com\/artificial-intelligence\/)\n- [Generative AI](https:\/\/www.infoworld.com\/generative-ai\/)\n- [Careers](https:\/\/www.infoworld.com\/careers\/)\n- [Cloud Computing](https:\/\/www.infoworld.com\/cloud-computing\/)\n- [Data Management](https:\/\/www.infoworld.com\/data-management\/)\n- [Databases](https:\/\/www.infoworld.com\/database\/)\n- [Emerging Technology](https:\/\/www.infoworld.com\/emerging-technology\/)\n- [Technology Industry](https:\/\/www.infoworld.com\/technology-business\/)\n- [Security](https:\/\/www.infoworld.com\/security\/)\n- [Software Development](https:\/\/www.infoworld.com\/software-development\/)\n\n- [Microsoft .NET](https:\/\/www.infoworld.com\/microsoft-net\/)\n- [Development Tools](https:\/\/www.infoworld.com\/development-tools\/)\n- [Devops](https:\/\/www.infoworld.com\/devops\/)\n- [Open Source](https:\/\/www.infoworld.com\/open-source\/)\n- [Programming Languages](https:\/\/www.infoworld.com\/programming-languages\/)\n- [Java](https:\/\/www.infoworld.com\/java\/)\n- [JavaScript](https:\/\/www.infoworld.com\/javascript\/)\n- [Python](https:\/\/www.infoworld.com\/python\/)\n- [IT Leadership](https:\/\/www.infoworld.com\/it-leadership\/)\n- [Enterprise Buyer’s Guides](https:\/\/www.infoworld.com\/enterprise-buyers-guide\/)\n\nBack\n\nClose\n\nBack\n\nClose\n\nPopular Topics\n\n- [Artificial Intelligence](https:\/\/www.infoworld.com\/artificial-intelligence\/)\n- [Cloud Computing](https:\/\/www.infoworld.com\/cloud-computing\/)\n\n- [Data Management](https:\/\/www.infoworld.com\/data-management\/)\n- [Software Development](https:\/\/www.infoworld.com\/software-development\/)\n\n- Search\n\n- Topics\n- [Latest](https:\/\/www.infoworld.com\/news\/)\n- [Newsletters](https:\/\/www.infoworld.com\/newsletters\/signup\/)\n- [Resources](https:\/\/us.resources.infoworld.com\/)\n- [Buyer’s Guides](https:\/\/www.infoworld.com\/enterprise-buyers-guide\/)\n- About\n- Policies\n- Our Network\n- More\n\nBack\n\n## Topics\n- [Analytics](https:\/\/www.infoworld.com\/analytics\/)\n- [Artificial Intelligence](https:\/\/www.infoworld.com\/artificial-intelligence\/)\n- [Generative AI](https:\/\/www.infoworld.com\/generative-ai\/)\n- [Careers](https:\/\/www.infoworld.com\/careers\/)\n- [Cloud Computing](https:\/\/www.infoworld.com\/cloud-computing\/)\n- [Data Management](https:\/\/www.infoworld.com\/data-management\/)\n- [Databases](https:\/\/www.infoworld.com\/database\/)\n- [Emerging Technology](https:\/\/www.infoworld.com\/emerging-technology\/)\n- [Technology Industry](https:\/\/www.infoworld.com\/technology-business\/)\n- [Security](https:\/\/www.infoworld.com\/security\/)\n- [Software Development](https:\/\/www.infoworld.com\/software-development\/)\n- [Microsoft .NET](https:\/\/www.infoworld.com\/microsoft-net\/)\n- [Development Tools](https:\/\/www.infoworld.com\/development-tools\/)\n- [Devops](https:\/\/www.infoworld.com\/devops\/)\n- [Open Source](https:\/\/www.infoworld.com\/open-source\/)\n- [Programming Languages](https:\/\/www.infoworld.com\/programming-languages\/)\n- [Java](https:\/\/www.infoworld.com\/java\/)\n- [JavaScript](https:\/\/www.infoworld.com\/javascript\/)\n- [Python](https:\/\/www.infoworld.com\/python\/)\n- [IT Leadership](https:\/\/www.infoworld.com\/it-leadership\/)\n- [Enterprise Buyer’s Guides](https:\/\/www.infoworld.com\/enterprise-buyers-guide\/)\n\nBack\n\n## About\n- [About Us](https:\/\/www.infoworld.com\/about-us\/)\n- [Advertise](https:\/\/foundryco.com\/our-brands\/infoworld\/)\n- [Contact Us](https:\/\/www.infoworld.com\/contact-us\/)\n- [Editorial Ethics Policy](https:\/\/www.infoworld.com\/editorial-ethics-policy\/)\n- [Foundry Careers](https:\/\/foundryco.com\/work-here\/)\n- [Newsletters](https:\/\/www.infoworld.com\/newsletters\/signup\/)\n- [Reprints](https:\/\/www.infoworld.com\/contact-us\/#republication-permissions)\n- [Add InfoWorld as a Preferred Source in Google Search](https:\/\/www.google.com\/preferences\/source?q=infoworld.com)\n\nBack\n\n## Policies\n- [Terms of Service](https:\/\/foundryco.com\/terms-of-service-agreement\/)\n- [Privacy Policy](https:\/\/foundryco.com\/privacy-policy\/)\n- [Cookie Policy](https:\/\/foundryco.com\/cookie-policy\/)\n- [Copyright Notice](https:\/\/foundryco.com\/copyright-notice\/)\n- [Member Preferences](https:\/\/www.infoworld.com\/member-preferences\/)\n- [About AdChoices](https:\/\/foundryco.com\/ad-choices\/)\n- [Your California Privacy Rights](https:\/\/foundryco.com\/ccpa\/)\n\nBack\n\n## Our Network\n- [CIO](https:\/\/www.cio.com\/)\n- [Computerworld](https:\/\/www.computerworld.com\/)\n- [CSO](https:\/\/www.csoonline.com\/)\n- [Network World](https:\/\/www.networkworld.com\/)\n\nBack\n\n## More\n- [News](https:\/\/www.infoworld.com\/news\/)\n- [Features](https:\/\/www.infoworld.com\/features\/)\n- [Blogs](https:\/\/www.infoworld.com\/blogs\/)\n- [BrandPosts](https:\/\/www.infoworld.com\/brandposts\/)\n- [Events](https:\/\/www.infoworld.com\/events\/)\n- [Videos](https:\/\/www.infoworld.com\/videos\/)\n- [Enterprise Buyer’s Guides](https:\/\/www.infoworld.com\/enterprise-buyers-guide\/)\n\n1. [Home](https:\/\/www.infoworld.com\/)\n2. [Software Development](https:\/\/www.infoworld.com\/software-development\/)\n3. [Programming Languages](https:\/\/www.infoworld.com\/programming-languages\/)\n4. [Python](https:\/\/www.infoworld.com\/python\/)\n\n![Serdar Yegulalp](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/2817-0-77746700-1775638957-serdaryegulalp2_crop-100796854-orig.jpg?quality=50&strip=all&w=150)\n\nby [Serdar Yegulalp](https:\/\/www.infoworld.com\/profile\/serdar-yegulalp\/)\n\nSenior Writer\n\n# Python moves to remove the GIL and boost concurrency\nnews analysis\n\nAug 4, 20237 mins\n\n## Formal plans for a Python that supports true parallelism are finally on the table. Here’s how a GIL-free Python will finally come together.\n![women spinning plates asynchronous programming synchrony multi tasking by graemenicholson getty ima](https:\/\/www.infoworld.com\/wp-content\/uploads\/2025\/01\/2338862-0-42021800-1736999842-women-spinning-plates_asynchronous-programming_synchrony_multi-tasking_by-graemenicholson-getty-images-2400x1600-100818018-orig.jpg?quality=50&strip=all&w=1024)\n\nCredit: graemenicholson \/ Getty Images\n\nAfter much debate, the Python Steering Council intends to approve a proposal, [PEP 703](https:\/\/peps.python.org\/pep-0703\/), “Making the Global Interpreter Lock Optional in [CPython](https:\/\/www.infoworld.com\/article\/2262455\/what-is-cython-python-at-the-speed-of-c.html).”\n\nThis proposal is the culmination of many attempts over the years to [remove Python’s Global Interpreter Lock, or GIL](https:\/\/www.infoworld.com\/article\/2337804\/is-it-finally-time-to-remove-the-python-gil.html). Removing the GIL removes a major obstacle to multi-threading, making Python a truly multi-core language and significantly improving its performance for workloads that benefit from parallelism.\n\n#### \\[ [Also on InfoWorld: Is it finally time to remove Python’s GIL?](https:\/\/www.infoworld.com\/article\/2337804\/is-it-finally-time-to-remove-the-python-gil.html) \\]\nWith this proposal, first-class support for multi-threading and concurrency in Python is a step closer to becoming reality.\n\n## Why remove Python’s GIL?\nPython’s memory management system keeps track of object usage by maintaining counts of the number of references to each object. When the reference count for an object falls to zero, the object is slated for removal.\n\nBecause [Python](https:\/\/www.infoworld.com\/article\/2253770\/what-is-python-powerful-intuitive-programming.html) was created at a time when multi-processor systems were a rarity, and multi-core processors were non-existent, this reference count mechanism isn’t thread-safe. Instead, Python achieves thread safety by allowing only one thread to access an object at a time. This is the purpose of the GIL.\n\nMany projects over the years have attempted to remove the GIL. They did enable multi-threaded programs to run faster, but at the cost of degrading the performance of single-threaded programs. Given the vast majority of Python applications are single-threaded, this was a poor trade-off. Although refinements to the GIL have improved its handling of multi-threaded apps, it’s still a serious bottleneck.\n\nPython’s core developers finally decided to remove the GIL from CPython, but only if it could be done without slowing down single-threaded programs.\n\n## How a GIL-free Python will work\nThe current proposals for a no-GIL edition of Python use a mix of techniques to make reference counting thread-safe, and leave the speed of single-threaded programs untouched or impact it only minimally.\n\n- **Biased reference counting.** Counts for objects accessed by only a single thread would be handled differently (and more quickly) than counts for objects accessed by multiple threads. Since most objects are accessed by only one thread, the impact on single-threaded programs is minimized.\n- **Immortalization.** Some objects, like `None`, never need to be deallocated, so their reference counts do not need to be tracked.\n- **Thread-safe memory allocation.** A new memory allocation system for CPython objects will make it easier to trace objects in the garbage collector, and to allocate memory in a thread-safe way.\n- **Deferred reference counting.** Reference counts for some objects, like top-level functions in a module, can be safely deferred. This saves both time and resources.\n- **A revised garbage collector.** The CPython garbage collector cleans up cyclical object references, where two or more objects hold references to each other. The no-GIL build [makes many changes](https:\/\/peps.python.org\/pep-0703\/#garbage-collection-cycle-collection) to the garbage collector, such as removing the “generations” system for tracking objects.\n## How a GIL-free Python will be phased in\nImplementing PEP 703 is a long-term project that will take place in multiple stages over several years. During this time, the CPython interpreter will transition to make the no-GIL version first optional, then supported, and finally the standard version of CPython.\n\nTo accomplish this, CPython’s developers will add an experimental “no-GIL” *build* mode to CPython, so that one can compile a version of CPython with or without the GIL. Eventually, the no-GIL build will become the default.\n\nHere is how the plan to remove the GIL from CPython is set to unfold.\n\n### Step 1: No-GIL CPython is optional\nThe first incarnations of a no-GIL CPython will be experimental, for both CPython developers and the larger Python community. This experimental phase has several goals:\n\n- **Get the rest of the Python community involved.** Any major change to Python needs buy-in from the wider Python community. The experimental builds give Python users a way to safely experiment with testing their code, and to see how both non-threaded and threaded code will behave.\n- **Give Python distributions the option, not the requirement, to ship a GIL-less Python.** Python distributions like Conda or WinPython need to guarantee compatibility with stock CPython. During the transition phase, they could provide the option to install the regular or GIL-less version of CPython. This would allow Conda or WinPython users to pick the version most compatible with their needs.\n- **Determine whether the no-GIL project is worthwhile.** If the community tries out the GIL-less builds at scale and is unhappy with the results, the core CPython developers reserve the right to back out. Having dual builds means a heavier maintenance burden in the short term, but provides an escape hatch if the no-GIL project proves unworthy.\n### Step 2: No-GIL CPython is supported\nThe next stage will be to offer the no-GIL build as a supported alternative build for CPython. A user would have the choice of installing either the no-GIL or GIL build, with either one being a formally supported version of CPython that receives bug fixes, security patches, and updates.\n\nOne big goal of this stage is to set a target date for making no-GIL the default. This will likely happen on the same timeline as the deprecation and removal of other Python features—at least two or three versions, meaning at least two or three years.\n\n### Step 3: No-GIL CPython is the default\nThe final stage would be to make the no-GIL version of CPython the default build, and to remove *all* GIL-related code from CPython. “We don’t want to wait too long with this,” [wrote Thomas Wouters](https:\/\/discuss.python.org\/t\/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython\/30474), CPython core developer, “because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.”\n\n#### \\[ [Tune into Dev with Serdar to get Python coding tips in 5 minutes or less](https:\/\/www.infoworld.com\/video\/series\/8675\/dev-with-serdar) \\]\n## The biggest challenges to removing the GIL\nThe biggest challenges present in this plan aren’t only technical, although the technical challenges are daunting. What looms even larger is how to bring the rest of the Python ecosystem into line with these changes—and make sure a GIL-less Python doesn’t create more problems than it solves.\n\nAccording to Wouters, “… any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).”\n\nThe other big challenge, as mentioned above, is “to bring along the rest of the Python community,” said Wouters, “… and make sure the changes we want to make, and the changes we want them to make, are palatable.\n\n“Before we commit to switching entirely to the no-GIL build, we need to see community support for it,” Wouters said. “We can’t just flip the default and expect the community to figure out what work they need to do to support it.”\n\nThe Python community experienced huge growing pains when transitioning from Python 2 to Python 3, so any big changes like removing the GIL would have to be thoroughly backwards compatible. As Wouters put it, “We do not want another Python 3 situation.”\n\nBeyond the perils and challenges lies a great reward: A Python that finally supports the parallelism that programmers have come to expect in the 21st century.\n\n[Python](https:\/\/www.infoworld.com\/python\/)[Programming Languages](https:\/\/www.infoworld.com\/programming-languages\/)[Software Development](https:\/\/www.infoworld.com\/software-development\/)\n\n## Related content\n[news Z.ai unveils GLM-5.1, enabling AI coding agents to run autonomously for hours By Prasanth Aby Thomas Apr 8, 2026 4 mins Artificial Intelligence Development Tools Open Source](https:\/\/www.infoworld.com\/article\/4155622\/z-ai-unveils-glm-5-1-enabling-ai-coding-agents-to-run-autonomously-for-hours-2.html)\n\n[news Microsoft’s new Agent Governance Toolkit targets top OWASP risks for AI agents By Anirban Ghoshal Apr 8, 2026 3 mins Artificial Intelligence Development Tools Security](https:\/\/www.infoworld.com\/article\/4155591\/microsofts-new-agent-governance-toolkit-targets-top-owasp-risks-for-ai-agents.html)\n\n[feature Get started with Python’s new frozendict type By Serdar Yegulalp Apr 8, 2026 5 mins Programming Languages Python Software Development](https:\/\/www.infoworld.com\/article\/4152654\/get-started-with-pythons-new-frozendict-type.html)\n\n[opinion The winners and losers of AI coding By Nick Hodges Apr 8, 2026 4 mins Developer Generative AI Roles](https:\/\/www.infoworld.com\/article\/4155139\/the-winners-and-losers-of-ai-coding.html)\n\n## Other Sections\n- [Resources](https:\/\/us.resources.infoworld.com\/)\n- [Videos](https:\/\/www.infoworld.com\/videos\/)\n\n![Serdar Yegulalp](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/2817-0-77746700-1775638957-serdaryegulalp2_crop-100796854-orig.jpg?quality=50&strip=all&w=250)\n\nby  [Serdar Yegulalp](https:\/\/www.infoworld.com\/profile\/serdar-yegulalp\/)\n\nSenior Writer\n\n1. [Follow Serdar Yegulalp on X](https:\/\/www.twitter.com\/syegulalp)\n\nSerdar Yegulalp is a senior writer at [InfoWorld](https:\/\/www.infoworld.com\/). A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024 [Neal Award](https:\/\/siia.net\/neals\/) and a 2025 [Azbee Award](https:\/\/siia.net\/neals\/) for best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly [Dev with Serdar](https:\/\/www.youtube.com\/playlist?list=PLYaGSokOr0MNgQlbnq_qY7BJs9-TOAxHA) videos for programming tips and techniques and close looks at programming libraries and tools.\n\n## More from this author\n- [featurePEP 816: How Python is getting serious about Wasm Apr 1, 2026 7 mins](https:\/\/www.infoworld.com\/article\/4150052\/how-python-is-getting-serious-about-wasm.html)\n- [analysisOn the pleasures and dangers of open source Python Mar 27, 2026 3 mins](https:\/\/www.infoworld.com\/article\/4150170\/on-the-pleasures-and-dangers-of-open-source-python.html)\n- [how-toSpeed boost your Python programs with new lazy imports Mar 25, 2026 6 mins](https:\/\/www.infoworld.com\/article\/4145854\/speed-boost-your-python-programs-with-new-lazy-imports.html)\n- [featureI ran Qwen3.5 locally instead of Claude Code. Here’s what happened. Mar 18, 2026 9 mins](https:\/\/www.infoworld.com\/article\/4144487\/i-ran-qwen3-5-locally-instead-of-claude-code-heres-what-happened.html)\n- [analysisMigrating Python to Rust with Claude: What could go wrong? Mar 13, 2026 3 mins](https:\/\/www.infoworld.com\/article\/4143158\/migrating-python-to-rust-with-claude-what-could-go-wrong.html)\n- [featureFirst look: Electrobun for TypeScript-powered desktop apps Mar 11, 2026 7 mins](https:\/\/www.infoworld.com\/article\/4137964\/first-look-electrobun-for-typescript-powered-desktop-apps.html)\n- [featureWhat I learned using Claude Sonnet to migrate Python to Rust Mar 4, 2026 11 mins](https:\/\/www.infoworld.com\/article\/4135218\/what-i-learned-using-claude-sonnet-to-migrate-python-to-rust.html)\n- [featureThe best new features in MariaDB Feb 25, 2026 7 mins](https:\/\/www.infoworld.com\/article\/4131626\/the-best-new-features-in-mariadb.html)\n\n## Show me more\nPopular\n\nArticles\n\nVideos\n\n[news GitHub Copilot CLI adds Rubber Duck review agent By Paul Krill Apr 7, 20263 mins Artificial IntelligenceDevelopment ToolsGenerative AI ![Image](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/4155289-0-95390000-1775604595-shutterstock_2288028173-100941497-orig.jpg?quality=50&strip=all&w=444)](https:\/\/www.infoworld.com\/article\/4155289\/github-copilot-cli-adds-rubber-duck-review-agent.html)\n\n[opinion The Terraform scaling problem: When infrastructure-as-code becomes infrastructure-as-complexity By Neel Shah Apr 7, 202614 mins Cloud ManagementDevelopment ToolsDevops ![Image](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/4154543-0-98448200-1775565715-infrastructure-as-code.jpg?quality=50&strip=all&w=444)](https:\/\/www.infoworld.com\/article\/4154543\/the-terraform-scaling-problem-when-infrastructure-as-code-becomes-infrastructure-as-complexity.html)\n\n[news Nvidia’s SchedMD acquisition puts open-source AI scheduling under scrutiny By Gyana Swain Apr 7, 20265 mins Artificial IntelligenceOpen SourceSoftware Development ![Image](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/4154989-0-56929100-1775564027-Jensen-Huang-Nvidia.jpg?quality=50&strip=all&w=375)](https:\/\/www.infoworld.com\/article\/4154989\/nvidias-schedmd-acquisition-puts-open-source-ai-scheduling-under-scrutiny.html)\n\n[video Python's new frozendict type Apr 2, 20264 mins Python ![Image](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/4153873-0-51930400-1775143797-youtube-thumbnail-CD_8mAIdH9M_ddd0a5.jpg?quality=50&strip=all&w=444)](https:\/\/www.infoworld.com\/video\/4153873\/pythons-new-frozendict-type.html)\n\n[video How to boost app performance with Python 3.15's lazy import Mar 31, 20266 mins Python ![Image](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/03\/4152630-0-43887000-1774980243-youtube-thumbnail-XMHBeBs64cg_fd88a0.jpg?quality=50&strip=all&w=444)](https:\/\/www.infoworld.com\/video\/4152630\/how-to-boost-app-performance-with-python-3-15s-lazy-import.html)\n\n[video How to run your own little local Claude Code (sort of!) Mar 26, 20267 mins Python ![Image](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/03\/4150783-0-18851500-1774547343-youtube-thumbnail-XzxM0hdIxLE_ee4769.jpg?quality=50&strip=all&w=444)](https:\/\/www.infoworld.com\/video\/4150783\/how-to-run-your-own-little-local-claude-code-sort-of.html)\n\nAbout\n\n- [About Us](https:\/\/www.infoworld.com\/about-us\/)\n- [Advertise](https:\/\/foundryco.com\/our-brands\/infoworld\/)\n- [Contact Us](https:\/\/www.infoworld.com\/contact-us\/)\n- [Editorial Ethics Policy](https:\/\/www.infoworld.com\/editorial-ethics-policy\/)\n- [Foundry Careers](https:\/\/foundryco.com\/work-here\/)\n- [Reprints](https:\/\/www.infoworld.com\/contact-us\/#republication-permissions)\n- [Newsletters](https:\/\/www.infoworld.com\/newsletters\/signup\/)\n- [BrandPosts](https:\/\/www.infoworld.com\/brandposts\/)\n- [Add InfoWorld as a Preferred Source in Google Search](https:\/\/www.google.com\/preferences\/source?q=infoworld.com)\n\nPolicies\n\n- [Terms of Service](https:\/\/foundryco.com\/terms-of-service-agreement\/)\n- [Privacy Policy](https:\/\/foundryco.com\/privacy-policy\/)\n- [Cookie Policy](https:\/\/foundryco.com\/cookie-policy\/)\n- [Copyright Notice](https:\/\/foundryco.com\/copyright-notice\/)\n- [Member Preferences](https:\/\/www.infoworld.com\/member-preferences\/)\n- [About AdChoices](https:\/\/foundryco.com\/ad-choices\/)\n- [Your California Privacy Rights](https:\/\/foundryco.com\/ccpa\/)\n- [Privacy Settings]()\n\nOur Network\n\n- [CIO](https:\/\/www.cio.com\/)\n- [Computerworld](https:\/\/www.computerworld.com\/)\n- [CSO](https:\/\/www.csoonline.com\/)\n- [Network World](https:\/\/www.networkworld.com\/)\n\n- [Facebook](https:\/\/www.facebook.com\/InfoWorld)\n- [X](https:\/\/twitter.com\/infoworld)\n- [YouTube](https:\/\/www.youtube.com\/@InfoWorld)\n- [Google News](https:\/\/news.google.com\/publications\/CAAqIggKIhxDQkFTRHdvSkwyMHZNRFY1ZEhaNUVnSmxiaWdBUAE)\n- [LinkedIn](https:\/\/www.linkedin.com\/company\/164364)\n\n[© 2026 FoundryCo, Inc. All Rights Reserved.](https:\/\/foundryco.com\/terms-of-service-agreement\/)","attrs_readable_markdown":"news analysis\n\nAug 4, 20237 mins\n\nAfter much debate, the Python Steering Council intends to approve a proposal, [PEP 703](https:\/\/peps.python.org\/pep-0703\/), “Making the Global Interpreter Lock Optional in [CPython](https:\/\/www.infoworld.com\/article\/2262455\/what-is-cython-python-at-the-speed-of-c.html).”\n\nThis proposal is the culmination of many attempts over the years to [remove Python’s Global Interpreter Lock, or GIL](https:\/\/www.infoworld.com\/article\/2337804\/is-it-finally-time-to-remove-the-python-gil.html). Removing the GIL removes a major obstacle to multi-threading, making Python a truly multi-core language and significantly improving its performance for workloads that benefit from parallelism.\n\nWith this proposal, first-class support for multi-threading and concurrency in Python is a step closer to becoming reality.\n\n## Why remove Python’s GIL?\nPython’s memory management system keeps track of object usage by maintaining counts of the number of references to each object. When the reference count for an object falls to zero, the object is slated for removal.\n\nBecause [Python](https:\/\/www.infoworld.com\/article\/2253770\/what-is-python-powerful-intuitive-programming.html) was created at a time when multi-processor systems were a rarity, and multi-core processors were non-existent, this reference count mechanism isn’t thread-safe. Instead, Python achieves thread safety by allowing only one thread to access an object at a time. This is the purpose of the GIL.\n\nMany projects over the years have attempted to remove the GIL. They did enable multi-threaded programs to run faster, but at the cost of degrading the performance of single-threaded programs. Given the vast majority of Python applications are single-threaded, this was a poor trade-off. Although refinements to the GIL have improved its handling of multi-threaded apps, it’s still a serious bottleneck.\n\nPython’s core developers finally decided to remove the GIL from CPython, but only if it could be done without slowing down single-threaded programs.\n\n## How a GIL-free Python will work\nThe current proposals for a no-GIL edition of Python use a mix of techniques to make reference counting thread-safe, and leave the speed of single-threaded programs untouched or impact it only minimally.\n\n- **Biased reference counting.** Counts for objects accessed by only a single thread would be handled differently (and more quickly) than counts for objects accessed by multiple threads. Since most objects are accessed by only one thread, the impact on single-threaded programs is minimized.\n- **Immortalization.** Some objects, like `None`, never need to be deallocated, so their reference counts do not need to be tracked.\n- **Thread-safe memory allocation.** A new memory allocation system for CPython objects will make it easier to trace objects in the garbage collector, and to allocate memory in a thread-safe way.\n- **Deferred reference counting.** Reference counts for some objects, like top-level functions in a module, can be safely deferred. This saves both time and resources.\n- **A revised garbage collector.** The CPython garbage collector cleans up cyclical object references, where two or more objects hold references to each other. The no-GIL build [makes many changes](https:\/\/peps.python.org\/pep-0703\/#garbage-collection-cycle-collection) to the garbage collector, such as removing the “generations” system for tracking objects.\n## How a GIL-free Python will be phased in\nImplementing PEP 703 is a long-term project that will take place in multiple stages over several years. During this time, the CPython interpreter will transition to make the no-GIL version first optional, then supported, and finally the standard version of CPython.\n\nTo accomplish this, CPython’s developers will add an experimental “no-GIL” *build* mode to CPython, so that one can compile a version of CPython with or without the GIL. Eventually, the no-GIL build will become the default.\n\nHere is how the plan to remove the GIL from CPython is set to unfold.\n\n### Step 1: No-GIL CPython is optional\nThe first incarnations of a no-GIL CPython will be experimental, for both CPython developers and the larger Python community. This experimental phase has several goals:\n\n- **Get the rest of the Python community involved.** Any major change to Python needs buy-in from the wider Python community. The experimental builds give Python users a way to safely experiment with testing their code, and to see how both non-threaded and threaded code will behave.\n- **Give Python distributions the option, not the requirement, to ship a GIL-less Python.** Python distributions like Conda or WinPython need to guarantee compatibility with stock CPython. During the transition phase, they could provide the option to install the regular or GIL-less version of CPython. This would allow Conda or WinPython users to pick the version most compatible with their needs.\n- **Determine whether the no-GIL project is worthwhile.** If the community tries out the GIL-less builds at scale and is unhappy with the results, the core CPython developers reserve the right to back out. Having dual builds means a heavier maintenance burden in the short term, but provides an escape hatch if the no-GIL project proves unworthy.\n### Step 2: No-GIL CPython is supported\nThe next stage will be to offer the no-GIL build as a supported alternative build for CPython. A user would have the choice of installing either the no-GIL or GIL build, with either one being a formally supported version of CPython that receives bug fixes, security patches, and updates.\n\nOne big goal of this stage is to set a target date for making no-GIL the default. This will likely happen on the same timeline as the deprecation and removal of other Python features—at least two or three versions, meaning at least two or three years.\n\n### Step 3: No-GIL CPython is the default\nThe final stage would be to make the no-GIL version of CPython the default build, and to remove *all* GIL-related code from CPython. “We don’t want to wait too long with this,” [wrote Thomas Wouters](https:\/\/discuss.python.org\/t\/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython\/30474), CPython core developer, “because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.”\n\n## The biggest challenges to removing the GIL\nThe biggest challenges present in this plan aren’t only technical, although the technical challenges are daunting. What looms even larger is how to bring the rest of the Python ecosystem into line with these changes—and make sure a GIL-less Python doesn’t create more problems than it solves.\n\nAccording to Wouters, “… any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).”\n\nThe other big challenge, as mentioned above, is “to bring along the rest of the Python community,” said Wouters, “… and make sure the changes we want to make, and the changes we want them to make, are palatable.\n\n“Before we commit to switching entirely to the no-GIL build, we need to see community support for it,” Wouters said. “We can’t just flip the default and expect the community to figure out what work they need to do to support it.”\n\nThe Python community experienced huge growing pains when transitioning from Python 2 to Python 3, so any big changes like removing the GIL would have to be thoroughly backwards compatible. As Wouters put it, “We do not want another Python 3 situation.”\n\nBeyond the perils and challenges lies a great reward: A Python that finally supports the parallelism that programmers have come to expect in the 21st century.\n\n![Serdar Yegulalp](https:\/\/www.infoworld.com\/wp-content\/uploads\/2026\/04\/2817-0-77746700-1775638957-serdaryegulalp2_crop-100796854-orig.jpg?quality=50&strip=all&w=250)\n\nSenior Writer\n\nSerdar Yegulalp is a senior writer at [InfoWorld](https:\/\/www.infoworld.com\/). A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024 [Neal Award](https:\/\/siia.net\/neals\/) and a 2025 [Azbee Award](https:\/\/siia.net\/neals\/) for best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly [Dev with Serdar](https:\/\/www.youtube.com\/playlist?list=PLYaGSokOr0MNgQlbnq_qY7BJs9-TOAxHA) videos for programming tips and techniques and close looks at programming libraries and tools.\n\nMore from this author","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

11 hours ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	0 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://www.infoworld.com/article/2338862/python-moves-to-remove-the-gil-and-boost-concurrency.html
Last Crawled	2026-04-08 23:32:47 (11 hours ago)
First Indexed	2024-06-17 01:21:50 (1 year ago)
HTTP Status Code	200
Meta Title	Python moves to remove the GIL and boost concurrency \| InfoWorld
Meta Description	Formal plans for a Python that supports true parallelism are finally on the table. Here’s how a GIL-free Python will finally come together.
Meta Canonical	null
Boilerpipe Text	news analysis Aug 4, 2023 7 mins After much debate, the Python Steering Council intends to approve a proposal, PEP 703 , “Making the Global Interpreter Lock Optional in CPython .” This proposal is the culmination of many attempts over the years to remove Python’s Global Interpreter Lock, or GIL . Removing the GIL removes a major obstacle to multi-threading, making Python a truly multi-core language and significantly improving its performance for workloads that benefit from parallelism. With this proposal, first-class support for multi-threading and concurrency in Python is a step closer to becoming reality. Why remove Python’s GIL? Python’s memory management system keeps track of object usage by maintaining counts of the number of references to each object. When the reference count for an object falls to zero, the object is slated for removal. Because Python was created at a time when multi-processor systems were a rarity, and multi-core processors were non-existent, this reference count mechanism isn’t thread-safe. Instead, Python achieves thread safety by allowing only one thread to access an object at a time. This is the purpose of the GIL. Many projects over the years have attempted to remove the GIL. They did enable multi-threaded programs to run faster, but at the cost of degrading the performance of single-threaded programs. Given the vast majority of Python applications are single-threaded, this was a poor trade-off. Although refinements to the GIL have improved its handling of multi-threaded apps, it’s still a serious bottleneck. Python’s core developers finally decided to remove the GIL from CPython, but only if it could be done without slowing down single-threaded programs. How a GIL-free Python will work The current proposals for a no-GIL edition of Python use a mix of techniques to make reference counting thread-safe, and leave the speed of single-threaded programs untouched or impact it only minimally. Biased reference counting. Counts for objects accessed by only a single thread would be handled differently (and more quickly) than counts for objects accessed by multiple threads. Since most objects are accessed by only one thread, the impact on single-threaded programs is minimized. Immortalization. Some objects, like None , never need to be deallocated, so their reference counts do not need to be tracked. Thread-safe memory allocation. A new memory allocation system for CPython objects will make it easier to trace objects in the garbage collector, and to allocate memory in a thread-safe way. Deferred reference counting. Reference counts for some objects, like top-level functions in a module, can be safely deferred. This saves both time and resources. A revised garbage collector. The CPython garbage collector cleans up cyclical object references, where two or more objects hold references to each other. The no-GIL build makes many changes to the garbage collector, such as removing the “generations” system for tracking objects. How a GIL-free Python will be phased in Implementing PEP 703 is a long-term project that will take place in multiple stages over several years. During this time, the CPython interpreter will transition to make the no-GIL version first optional, then supported, and finally the standard version of CPython. To accomplish this, CPython’s developers will add an experimental “no-GIL” build mode to CPython, so that one can compile a version of CPython with or without the GIL. Eventually, the no-GIL build will become the default. Here is how the plan to remove the GIL from CPython is set to unfold. Step 1: No-GIL CPython is optional The first incarnations of a no-GIL CPython will be experimental, for both CPython developers and the larger Python community. This experimental phase has several goals: Get the rest of the Python community involved. Any major change to Python needs buy-in from the wider Python community. The experimental builds give Python users a way to safely experiment with testing their code, and to see how both non-threaded and threaded code will behave. Give Python distributions the option, not the requirement, to ship a GIL-less Python. Python distributions like Conda or WinPython need to guarantee compatibility with stock CPython. During the transition phase, they could provide the option to install the regular or GIL-less version of CPython. This would allow Conda or WinPython users to pick the version most compatible with their needs. Determine whether the no-GIL project is worthwhile. If the community tries out the GIL-less builds at scale and is unhappy with the results, the core CPython developers reserve the right to back out. Having dual builds means a heavier maintenance burden in the short term, but provides an escape hatch if the no-GIL project proves unworthy. Step 2: No-GIL CPython is supported The next stage will be to offer the no-GIL build as a supported alternative build for CPython. A user would have the choice of installing either the no-GIL or GIL build, with either one being a formally supported version of CPython that receives bug fixes, security patches, and updates. One big goal of this stage is to set a target date for making no-GIL the default. This will likely happen on the same timeline as the deprecation and removal of other Python features—at least two or three versions, meaning at least two or three years. Step 3: No-GIL CPython is the default The final stage would be to make the no-GIL version of CPython the default build, and to remove all GIL-related code from CPython. “We don’t want to wait too long with this,” wrote Thomas Wouters , CPython core developer, “because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.” The biggest challenges to removing the GIL The biggest challenges present in this plan aren’t only technical, although the technical challenges are daunting. What looms even larger is how to bring the rest of the Python ecosystem into line with these changes—and make sure a GIL-less Python doesn’t create more problems than it solves. According to Wouters, “… any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).” The other big challenge, as mentioned above, is “to bring along the rest of the Python community,” said Wouters, “… and make sure the changes we want to make, and the changes we want them to make, are palatable. “Before we commit to switching entirely to the no-GIL build, we need to see community support for it,” Wouters said. “We can’t just flip the default and expect the community to figure out what work they need to do to support it.” The Python community experienced huge growing pains when transitioning from Python 2 to Python 3, so any big changes like removing the GIL would have to be thoroughly backwards compatible. As Wouters put it, “We do not want another Python 3 situation.” Beyond the perils and challenges lies a great reward: A Python that finally supports the parallelism that programmers have come to expect in the 21st century. Senior Writer Serdar Yegulalp is a senior writer at InfoWorld . A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024 Neal Award and a 2025 Azbee Award for best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly Dev with Serdar videos for programming tips and techniques and close looks at programming libraries and tools. More from this author
Markdown	1. Topics 2. [Latest](https://www.infoworld.com/news/) 3. [Newsletters](https://www.infoworld.com/newsletters/signup/) 4. [Resources](https://us.resources.infoworld.com/) 5. [Buyer’s Guides](https://www.infoworld.com/enterprise-buyers-guide/) ## About - [About Us](https://www.infoworld.com/about-us/) - [Advertise](https://foundryco.com/our-brands/infoworld/) - [Contact Us](https://www.infoworld.com/contact-us/) - [Editorial Ethics Policy](https://www.infoworld.com/editorial-ethics-policy/) - [Foundry Careers](https://foundryco.com/work-here/) - [Newsletters](https://www.infoworld.com/newsletters/signup/) - [Reprints](https://www.infoworld.com/contact-us/#republication-permissions) - [Add InfoWorld as a Preferred Source in Google Search](https://www.google.com/preferences/source?q=infoworld.com) ## Policies - [Terms of Service](https://foundryco.com/terms-of-service-agreement/) - [Privacy Policy](https://foundryco.com/privacy-policy/) - [Cookie Policy](https://foundryco.com/cookie-policy/) - [Copyright Notice](https://foundryco.com/copyright-notice/) - [Member Preferences](https://www.infoworld.com/member-preferences/) - [About AdChoices](https://foundryco.com/ad-choices/) - [Your California Privacy Rights](https://foundryco.com/ccpa/) ## Our Network - [CIO](https://www.cio.com/) - [Computerworld](https://www.computerworld.com/) - [CSO](https://www.csoonline.com/) - [Network World](https://www.networkworld.com/) ## More - [News](https://www.infoworld.com/news/) - [Features](https://www.infoworld.com/features/) - [Blogs](https://www.infoworld.com/blogs/) - [BrandPosts](https://www.infoworld.com/brandposts/) - [Events](https://www.infoworld.com/events/) - [Videos](https://www.infoworld.com/videos/) - [Enterprise Buyer’s Guides](https://www.infoworld.com/enterprise-buyers-guide/) Close - [Analytics](https://www.infoworld.com/analytics/) - [Artificial Intelligence](https://www.infoworld.com/artificial-intelligence/) - [Generative AI](https://www.infoworld.com/generative-ai/) - [Careers](https://www.infoworld.com/careers/) - [Cloud Computing](https://www.infoworld.com/cloud-computing/) - [Data Management](https://www.infoworld.com/data-management/) - [Databases](https://www.infoworld.com/database/) - [Emerging Technology](https://www.infoworld.com/emerging-technology/) - [Technology Industry](https://www.infoworld.com/technology-business/) - [Security](https://www.infoworld.com/security/) - [Software Development](https://www.infoworld.com/software-development/) - [Microsoft .NET](https://www.infoworld.com/microsoft-net/) - [Development Tools](https://www.infoworld.com/development-tools/) - [Devops](https://www.infoworld.com/devops/) - [Open Source](https://www.infoworld.com/open-source/) - [Programming Languages](https://www.infoworld.com/programming-languages/) - [Java](https://www.infoworld.com/java/) - [JavaScript](https://www.infoworld.com/javascript/) - [Python](https://www.infoworld.com/python/) - [IT Leadership](https://www.infoworld.com/it-leadership/) - [Enterprise Buyer’s Guides](https://www.infoworld.com/enterprise-buyers-guide/) Back Close Back Close Popular Topics - [Artificial Intelligence](https://www.infoworld.com/artificial-intelligence/) - [Cloud Computing](https://www.infoworld.com/cloud-computing/) - [Data Management](https://www.infoworld.com/data-management/) - [Software Development](https://www.infoworld.com/software-development/) - Search - Topics - [Latest](https://www.infoworld.com/news/) - [Newsletters](https://www.infoworld.com/newsletters/signup/) - [Resources](https://us.resources.infoworld.com/) - [Buyer’s Guides](https://www.infoworld.com/enterprise-buyers-guide/) - About - Policies - Our Network - More Back ## Topics - [Analytics](https://www.infoworld.com/analytics/) - [Artificial Intelligence](https://www.infoworld.com/artificial-intelligence/) - [Generative AI](https://www.infoworld.com/generative-ai/) - [Careers](https://www.infoworld.com/careers/) - [Cloud Computing](https://www.infoworld.com/cloud-computing/) - [Data Management](https://www.infoworld.com/data-management/) - [Databases](https://www.infoworld.com/database/) - [Emerging Technology](https://www.infoworld.com/emerging-technology/) - [Technology Industry](https://www.infoworld.com/technology-business/) - [Security](https://www.infoworld.com/security/) - [Software Development](https://www.infoworld.com/software-development/) - [Microsoft .NET](https://www.infoworld.com/microsoft-net/) - [Development Tools](https://www.infoworld.com/development-tools/) - [Devops](https://www.infoworld.com/devops/) - [Open Source](https://www.infoworld.com/open-source/) - [Programming Languages](https://www.infoworld.com/programming-languages/) - [Java](https://www.infoworld.com/java/) - [JavaScript](https://www.infoworld.com/javascript/) - [Python](https://www.infoworld.com/python/) - [IT Leadership](https://www.infoworld.com/it-leadership/) - [Enterprise Buyer’s Guides](https://www.infoworld.com/enterprise-buyers-guide/) Back ## About - [About Us](https://www.infoworld.com/about-us/) - [Advertise](https://foundryco.com/our-brands/infoworld/) - [Contact Us](https://www.infoworld.com/contact-us/) - [Editorial Ethics Policy](https://www.infoworld.com/editorial-ethics-policy/) - [Foundry Careers](https://foundryco.com/work-here/) - [Newsletters](https://www.infoworld.com/newsletters/signup/) - [Reprints](https://www.infoworld.com/contact-us/#republication-permissions) - [Add InfoWorld as a Preferred Source in Google Search](https://www.google.com/preferences/source?q=infoworld.com) Back ## Policies - [Terms of Service](https://foundryco.com/terms-of-service-agreement/) - [Privacy Policy](https://foundryco.com/privacy-policy/) - [Cookie Policy](https://foundryco.com/cookie-policy/) - [Copyright Notice](https://foundryco.com/copyright-notice/) - [Member Preferences](https://www.infoworld.com/member-preferences/) - [About AdChoices](https://foundryco.com/ad-choices/) - [Your California Privacy Rights](https://foundryco.com/ccpa/) Back ## Our Network - [CIO](https://www.cio.com/) - [Computerworld](https://www.computerworld.com/) - [CSO](https://www.csoonline.com/) - [Network World](https://www.networkworld.com/) Back ## More - [News](https://www.infoworld.com/news/) - [Features](https://www.infoworld.com/features/) - [Blogs](https://www.infoworld.com/blogs/) - [BrandPosts](https://www.infoworld.com/brandposts/) - [Events](https://www.infoworld.com/events/) - [Videos](https://www.infoworld.com/videos/) - [Enterprise Buyer’s Guides](https://www.infoworld.com/enterprise-buyers-guide/) 1. [Home](https://www.infoworld.com/) 2. [Software Development](https://www.infoworld.com/software-development/) 3. [Programming Languages](https://www.infoworld.com/programming-languages/) 4. [Python](https://www.infoworld.com/python/) ![Serdar Yegulalp](https://www.infoworld.com/wp-content/uploads/2026/04/2817-0-77746700-1775638957-serdaryegulalp2_crop-100796854-orig.jpg?quality=50&strip=all&w=150) by [Serdar Yegulalp](https://www.infoworld.com/profile/serdar-yegulalp/) Senior Writer # Python moves to remove the GIL and boost concurrency news analysis Aug 4, 20237 mins ## Formal plans for a Python that supports true parallelism are finally on the table. Here’s how a GIL-free Python will finally come together. ![women spinning plates asynchronous programming synchrony multi tasking by graemenicholson getty ima](https://www.infoworld.com/wp-content/uploads/2025/01/2338862-0-42021800-1736999842-women-spinning-plates_asynchronous-programming_synchrony_multi-tasking_by-graemenicholson-getty-images-2400x1600-100818018-orig.jpg?quality=50&strip=all&w=1024) Credit: graemenicholson / Getty Images After much debate, the Python Steering Council intends to approve a proposal, [PEP 703](https://peps.python.org/pep-0703/), “Making the Global Interpreter Lock Optional in [CPython](https://www.infoworld.com/article/2262455/what-is-cython-python-at-the-speed-of-c.html).” This proposal is the culmination of many attempts over the years to [remove Python’s Global Interpreter Lock, or GIL](https://www.infoworld.com/article/2337804/is-it-finally-time-to-remove-the-python-gil.html). Removing the GIL removes a major obstacle to multi-threading, making Python a truly multi-core language and significantly improving its performance for workloads that benefit from parallelism. #### \[ [Also on InfoWorld: Is it finally time to remove Python’s GIL?](https://www.infoworld.com/article/2337804/is-it-finally-time-to-remove-the-python-gil.html) \] With this proposal, first-class support for multi-threading and concurrency in Python is a step closer to becoming reality. ## Why remove Python’s GIL? Python’s memory management system keeps track of object usage by maintaining counts of the number of references to each object. When the reference count for an object falls to zero, the object is slated for removal. Because [Python](https://www.infoworld.com/article/2253770/what-is-python-powerful-intuitive-programming.html) was created at a time when multi-processor systems were a rarity, and multi-core processors were non-existent, this reference count mechanism isn’t thread-safe. Instead, Python achieves thread safety by allowing only one thread to access an object at a time. This is the purpose of the GIL. Many projects over the years have attempted to remove the GIL. They did enable multi-threaded programs to run faster, but at the cost of degrading the performance of single-threaded programs. Given the vast majority of Python applications are single-threaded, this was a poor trade-off. Although refinements to the GIL have improved its handling of multi-threaded apps, it’s still a serious bottleneck. Python’s core developers finally decided to remove the GIL from CPython, but only if it could be done without slowing down single-threaded programs. ## How a GIL-free Python will work The current proposals for a no-GIL edition of Python use a mix of techniques to make reference counting thread-safe, and leave the speed of single-threaded programs untouched or impact it only minimally. - Biased reference counting. Counts for objects accessed by only a single thread would be handled differently (and more quickly) than counts for objects accessed by multiple threads. Since most objects are accessed by only one thread, the impact on single-threaded programs is minimized. - Immortalization. Some objects, like `None`, never need to be deallocated, so their reference counts do not need to be tracked. - Thread-safe memory allocation. A new memory allocation system for CPython objects will make it easier to trace objects in the garbage collector, and to allocate memory in a thread-safe way. - Deferred reference counting. Reference counts for some objects, like top-level functions in a module, can be safely deferred. This saves both time and resources. - A revised garbage collector. The CPython garbage collector cleans up cyclical object references, where two or more objects hold references to each other. The no-GIL build [makes many changes](https://peps.python.org/pep-0703/#garbage-collection-cycle-collection) to the garbage collector, such as removing the “generations” system for tracking objects. ## How a GIL-free Python will be phased in Implementing PEP 703 is a long-term project that will take place in multiple stages over several years. During this time, the CPython interpreter will transition to make the no-GIL version first optional, then supported, and finally the standard version of CPython. To accomplish this, CPython’s developers will add an experimental “no-GIL” build mode to CPython, so that one can compile a version of CPython with or without the GIL. Eventually, the no-GIL build will become the default. Here is how the plan to remove the GIL from CPython is set to unfold. ### Step 1: No-GIL CPython is optional The first incarnations of a no-GIL CPython will be experimental, for both CPython developers and the larger Python community. This experimental phase has several goals: - Get the rest of the Python community involved. Any major change to Python needs buy-in from the wider Python community. The experimental builds give Python users a way to safely experiment with testing their code, and to see how both non-threaded and threaded code will behave. - Give Python distributions the option, not the requirement, to ship a GIL-less Python. Python distributions like Conda or WinPython need to guarantee compatibility with stock CPython. During the transition phase, they could provide the option to install the regular or GIL-less version of CPython. This would allow Conda or WinPython users to pick the version most compatible with their needs. - Determine whether the no-GIL project is worthwhile. If the community tries out the GIL-less builds at scale and is unhappy with the results, the core CPython developers reserve the right to back out. Having dual builds means a heavier maintenance burden in the short term, but provides an escape hatch if the no-GIL project proves unworthy. ### Step 2: No-GIL CPython is supported The next stage will be to offer the no-GIL build as a supported alternative build for CPython. A user would have the choice of installing either the no-GIL or GIL build, with either one being a formally supported version of CPython that receives bug fixes, security patches, and updates. One big goal of this stage is to set a target date for making no-GIL the default. This will likely happen on the same timeline as the deprecation and removal of other Python features—at least two or three versions, meaning at least two or three years. ### Step 3: No-GIL CPython is the default The final stage would be to make the no-GIL version of CPython the default build, and to remove all GIL-related code from CPython. “We don’t want to wait too long with this,” [wrote Thomas Wouters](https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474), CPython core developer, “because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.” #### \[ [Tune into Dev with Serdar to get Python coding tips in 5 minutes or less](https://www.infoworld.com/video/series/8675/dev-with-serdar) \] ## The biggest challenges to removing the GIL The biggest challenges present in this plan aren’t only technical, although the technical challenges are daunting. What looms even larger is how to bring the rest of the Python ecosystem into line with these changes—and make sure a GIL-less Python doesn’t create more problems than it solves. According to Wouters, “… any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).” The other big challenge, as mentioned above, is “to bring along the rest of the Python community,” said Wouters, “… and make sure the changes we want to make, and the changes we want them to make, are palatable. “Before we commit to switching entirely to the no-GIL build, we need to see community support for it,” Wouters said. “We can’t just flip the default and expect the community to figure out what work they need to do to support it.” The Python community experienced huge growing pains when transitioning from Python 2 to Python 3, so any big changes like removing the GIL would have to be thoroughly backwards compatible. As Wouters put it, “We do not want another Python 3 situation.” Beyond the perils and challenges lies a great reward: A Python that finally supports the parallelism that programmers have come to expect in the 21st century. [Python](https://www.infoworld.com/python/)[Programming Languages](https://www.infoworld.com/programming-languages/)[Software Development](https://www.infoworld.com/software-development/) ## Related content [news Z.ai unveils GLM-5.1, enabling AI coding agents to run autonomously for hours By Prasanth Aby Thomas Apr 8, 2026 4 mins Artificial Intelligence Development Tools Open Source](https://www.infoworld.com/article/4155622/z-ai-unveils-glm-5-1-enabling-ai-coding-agents-to-run-autonomously-for-hours-2.html) [news Microsoft’s new Agent Governance Toolkit targets top OWASP risks for AI agents By Anirban Ghoshal Apr 8, 2026 3 mins Artificial Intelligence Development Tools Security](https://www.infoworld.com/article/4155591/microsofts-new-agent-governance-toolkit-targets-top-owasp-risks-for-ai-agents.html) [feature Get started with Python’s new frozendict type By Serdar Yegulalp Apr 8, 2026 5 mins Programming Languages Python Software Development](https://www.infoworld.com/article/4152654/get-started-with-pythons-new-frozendict-type.html) [opinion The winners and losers of AI coding By Nick Hodges Apr 8, 2026 4 mins Developer Generative AI Roles](https://www.infoworld.com/article/4155139/the-winners-and-losers-of-ai-coding.html) ## Other Sections - [Resources](https://us.resources.infoworld.com/) - [Videos](https://www.infoworld.com/videos/) ![Serdar Yegulalp](https://www.infoworld.com/wp-content/uploads/2026/04/2817-0-77746700-1775638957-serdaryegulalp2_crop-100796854-orig.jpg?quality=50&strip=all&w=250) by [Serdar Yegulalp](https://www.infoworld.com/profile/serdar-yegulalp/) Senior Writer 1. [Follow Serdar Yegulalp on X](https://www.twitter.com/syegulalp) Serdar Yegulalp is a senior writer at [InfoWorld](https://www.infoworld.com/). A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024 [Neal Award](https://siia.net/neals/) and a 2025 [Azbee Award](https://siia.net/neals/) for best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly [Dev with Serdar](https://www.youtube.com/playlist?list=PLYaGSokOr0MNgQlbnq_qY7BJs9-TOAxHA) videos for programming tips and techniques and close looks at programming libraries and tools. ## More from this author - [featurePEP 816: How Python is getting serious about Wasm Apr 1, 2026 7 mins](https://www.infoworld.com/article/4150052/how-python-is-getting-serious-about-wasm.html) - [analysisOn the pleasures and dangers of open source Python Mar 27, 2026 3 mins](https://www.infoworld.com/article/4150170/on-the-pleasures-and-dangers-of-open-source-python.html) - [how-toSpeed boost your Python programs with new lazy imports Mar 25, 2026 6 mins](https://www.infoworld.com/article/4145854/speed-boost-your-python-programs-with-new-lazy-imports.html) - [featureI ran Qwen3.5 locally instead of Claude Code. Here’s what happened. Mar 18, 2026 9 mins](https://www.infoworld.com/article/4144487/i-ran-qwen3-5-locally-instead-of-claude-code-heres-what-happened.html) - [analysisMigrating Python to Rust with Claude: What could go wrong? Mar 13, 2026 3 mins](https://www.infoworld.com/article/4143158/migrating-python-to-rust-with-claude-what-could-go-wrong.html) - [featureFirst look: Electrobun for TypeScript-powered desktop apps Mar 11, 2026 7 mins](https://www.infoworld.com/article/4137964/first-look-electrobun-for-typescript-powered-desktop-apps.html) - [featureWhat I learned using Claude Sonnet to migrate Python to Rust Mar 4, 2026 11 mins](https://www.infoworld.com/article/4135218/what-i-learned-using-claude-sonnet-to-migrate-python-to-rust.html) - [featureThe best new features in MariaDB Feb 25, 2026 7 mins](https://www.infoworld.com/article/4131626/the-best-new-features-in-mariadb.html) ## Show me more Popular Articles Videos [news GitHub Copilot CLI adds Rubber Duck review agent By Paul Krill Apr 7, 20263 mins Artificial IntelligenceDevelopment ToolsGenerative AI ![Image](https://www.infoworld.com/wp-content/uploads/2026/04/4155289-0-95390000-1775604595-shutterstock_2288028173-100941497-orig.jpg?quality=50&strip=all&w=444)](https://www.infoworld.com/article/4155289/github-copilot-cli-adds-rubber-duck-review-agent.html) [opinion The Terraform scaling problem: When infrastructure-as-code becomes infrastructure-as-complexity By Neel Shah Apr 7, 202614 mins Cloud ManagementDevelopment ToolsDevops ![Image](https://www.infoworld.com/wp-content/uploads/2026/04/4154543-0-98448200-1775565715-infrastructure-as-code.jpg?quality=50&strip=all&w=444)](https://www.infoworld.com/article/4154543/the-terraform-scaling-problem-when-infrastructure-as-code-becomes-infrastructure-as-complexity.html) [news Nvidia’s SchedMD acquisition puts open-source AI scheduling under scrutiny By Gyana Swain Apr 7, 20265 mins Artificial IntelligenceOpen SourceSoftware Development ![Image](https://www.infoworld.com/wp-content/uploads/2026/04/4154989-0-56929100-1775564027-Jensen-Huang-Nvidia.jpg?quality=50&strip=all&w=375)](https://www.infoworld.com/article/4154989/nvidias-schedmd-acquisition-puts-open-source-ai-scheduling-under-scrutiny.html) [video Python's new frozendict type Apr 2, 20264 mins Python ![Image](https://www.infoworld.com/wp-content/uploads/2026/04/4153873-0-51930400-1775143797-youtube-thumbnail-CD_8mAIdH9M_ddd0a5.jpg?quality=50&strip=all&w=444)](https://www.infoworld.com/video/4153873/pythons-new-frozendict-type.html) [video How to boost app performance with Python 3.15's lazy import Mar 31, 20266 mins Python ![Image](https://www.infoworld.com/wp-content/uploads/2026/03/4152630-0-43887000-1774980243-youtube-thumbnail-XMHBeBs64cg_fd88a0.jpg?quality=50&strip=all&w=444)](https://www.infoworld.com/video/4152630/how-to-boost-app-performance-with-python-3-15s-lazy-import.html) [video How to run your own little local Claude Code (sort of!) Mar 26, 20267 mins Python ![Image](https://www.infoworld.com/wp-content/uploads/2026/03/4150783-0-18851500-1774547343-youtube-thumbnail-XzxM0hdIxLE_ee4769.jpg?quality=50&strip=all&w=444)](https://www.infoworld.com/video/4150783/how-to-run-your-own-little-local-claude-code-sort-of.html) About - [About Us](https://www.infoworld.com/about-us/) - [Advertise](https://foundryco.com/our-brands/infoworld/) - [Contact Us](https://www.infoworld.com/contact-us/) - [Editorial Ethics Policy](https://www.infoworld.com/editorial-ethics-policy/) - [Foundry Careers](https://foundryco.com/work-here/) - [Reprints](https://www.infoworld.com/contact-us/#republication-permissions) - [Newsletters](https://www.infoworld.com/newsletters/signup/) - [BrandPosts](https://www.infoworld.com/brandposts/) - [Add InfoWorld as a Preferred Source in Google Search](https://www.google.com/preferences/source?q=infoworld.com) Policies - [Terms of Service](https://foundryco.com/terms-of-service-agreement/) - [Privacy Policy](https://foundryco.com/privacy-policy/) - [Cookie Policy](https://foundryco.com/cookie-policy/) - [Copyright Notice](https://foundryco.com/copyright-notice/) - [Member Preferences](https://www.infoworld.com/member-preferences/) - [About AdChoices](https://foundryco.com/ad-choices/) - [Your California Privacy Rights](https://foundryco.com/ccpa/) - [Privacy Settings]() Our Network - [CIO](https://www.cio.com/) - [Computerworld](https://www.computerworld.com/) - [CSO](https://www.csoonline.com/) - [Network World](https://www.networkworld.com/) - [Facebook](https://www.facebook.com/InfoWorld) - [X](https://twitter.com/infoworld) - [YouTube](https://www.youtube.com/@InfoWorld) - [Google News](https://news.google.com/publications/CAAqIggKIhxDQkFTRHdvSkwyMHZNRFY1ZEhaNUVnSmxiaWdBUAE) - [LinkedIn](https://www.linkedin.com/company/164364) [© 2026 FoundryCo, Inc. All Rights Reserved.](https://foundryco.com/terms-of-service-agreement/)
Readable Markdown	news analysis Aug 4, 20237 mins After much debate, the Python Steering Council intends to approve a proposal, [PEP 703](https://peps.python.org/pep-0703/), “Making the Global Interpreter Lock Optional in [CPython](https://www.infoworld.com/article/2262455/what-is-cython-python-at-the-speed-of-c.html).” This proposal is the culmination of many attempts over the years to [remove Python’s Global Interpreter Lock, or GIL](https://www.infoworld.com/article/2337804/is-it-finally-time-to-remove-the-python-gil.html). Removing the GIL removes a major obstacle to multi-threading, making Python a truly multi-core language and significantly improving its performance for workloads that benefit from parallelism. With this proposal, first-class support for multi-threading and concurrency in Python is a step closer to becoming reality. ## Why remove Python’s GIL? Python’s memory management system keeps track of object usage by maintaining counts of the number of references to each object. When the reference count for an object falls to zero, the object is slated for removal. Because [Python](https://www.infoworld.com/article/2253770/what-is-python-powerful-intuitive-programming.html) was created at a time when multi-processor systems were a rarity, and multi-core processors were non-existent, this reference count mechanism isn’t thread-safe. Instead, Python achieves thread safety by allowing only one thread to access an object at a time. This is the purpose of the GIL. Many projects over the years have attempted to remove the GIL. They did enable multi-threaded programs to run faster, but at the cost of degrading the performance of single-threaded programs. Given the vast majority of Python applications are single-threaded, this was a poor trade-off. Although refinements to the GIL have improved its handling of multi-threaded apps, it’s still a serious bottleneck. Python’s core developers finally decided to remove the GIL from CPython, but only if it could be done without slowing down single-threaded programs. ## How a GIL-free Python will work The current proposals for a no-GIL edition of Python use a mix of techniques to make reference counting thread-safe, and leave the speed of single-threaded programs untouched or impact it only minimally. - Biased reference counting. Counts for objects accessed by only a single thread would be handled differently (and more quickly) than counts for objects accessed by multiple threads. Since most objects are accessed by only one thread, the impact on single-threaded programs is minimized. - Immortalization. Some objects, like `None`, never need to be deallocated, so their reference counts do not need to be tracked. - Thread-safe memory allocation. A new memory allocation system for CPython objects will make it easier to trace objects in the garbage collector, and to allocate memory in a thread-safe way. - Deferred reference counting. Reference counts for some objects, like top-level functions in a module, can be safely deferred. This saves both time and resources. - A revised garbage collector. The CPython garbage collector cleans up cyclical object references, where two or more objects hold references to each other. The no-GIL build [makes many changes](https://peps.python.org/pep-0703/#garbage-collection-cycle-collection) to the garbage collector, such as removing the “generations” system for tracking objects. ## How a GIL-free Python will be phased in Implementing PEP 703 is a long-term project that will take place in multiple stages over several years. During this time, the CPython interpreter will transition to make the no-GIL version first optional, then supported, and finally the standard version of CPython. To accomplish this, CPython’s developers will add an experimental “no-GIL” build mode to CPython, so that one can compile a version of CPython with or without the GIL. Eventually, the no-GIL build will become the default. Here is how the plan to remove the GIL from CPython is set to unfold. ### Step 1: No-GIL CPython is optional The first incarnations of a no-GIL CPython will be experimental, for both CPython developers and the larger Python community. This experimental phase has several goals: - Get the rest of the Python community involved. Any major change to Python needs buy-in from the wider Python community. The experimental builds give Python users a way to safely experiment with testing their code, and to see how both non-threaded and threaded code will behave. - Give Python distributions the option, not the requirement, to ship a GIL-less Python. Python distributions like Conda or WinPython need to guarantee compatibility with stock CPython. During the transition phase, they could provide the option to install the regular or GIL-less version of CPython. This would allow Conda or WinPython users to pick the version most compatible with their needs. - Determine whether the no-GIL project is worthwhile. If the community tries out the GIL-less builds at scale and is unhappy with the results, the core CPython developers reserve the right to back out. Having dual builds means a heavier maintenance burden in the short term, but provides an escape hatch if the no-GIL project proves unworthy. ### Step 2: No-GIL CPython is supported The next stage will be to offer the no-GIL build as a supported alternative build for CPython. A user would have the choice of installing either the no-GIL or GIL build, with either one being a formally supported version of CPython that receives bug fixes, security patches, and updates. One big goal of this stage is to set a target date for making no-GIL the default. This will likely happen on the same timeline as the deprecation and removal of other Python features—at least two or three versions, meaning at least two or three years. ### Step 3: No-GIL CPython is the default The final stage would be to make the no-GIL version of CPython the default build, and to remove all GIL-related code from CPython. “We don’t want to wait too long with this,” [wrote Thomas Wouters](https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474), CPython core developer, “because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.” ## The biggest challenges to removing the GIL The biggest challenges present in this plan aren’t only technical, although the technical challenges are daunting. What looms even larger is how to bring the rest of the Python ecosystem into line with these changes—and make sure a GIL-less Python doesn’t create more problems than it solves. According to Wouters, “… any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).” The other big challenge, as mentioned above, is “to bring along the rest of the Python community,” said Wouters, “… and make sure the changes we want to make, and the changes we want them to make, are palatable. “Before we commit to switching entirely to the no-GIL build, we need to see community support for it,” Wouters said. “We can’t just flip the default and expect the community to figure out what work they need to do to support it.” The Python community experienced huge growing pains when transitioning from Python 2 to Python 3, so any big changes like removing the GIL would have to be thoroughly backwards compatible. As Wouters put it, “We do not want another Python 3 situation.” Beyond the perils and challenges lies a great reward: A Python that finally supports the parallelism that programmers have come to expect in the 21st century. ![Serdar Yegulalp](https://www.infoworld.com/wp-content/uploads/2026/04/2817-0-77746700-1775638957-serdaryegulalp2_crop-100796854-orig.jpg?quality=50&strip=all&w=250) Senior Writer Serdar Yegulalp is a senior writer at [InfoWorld](https://www.infoworld.com/). A veteran technology journalist, Serdar has been writing about computers, operating systems, databases, programming, and other information technology topics for 30 years. Before joining InfoWorld in 2013, Serdar wrote for Windows Magazine, InformationWeek, Byte, and a slew of other publications. At InfoWorld, Serdar has covered software development, devops, containerization, machine learning, and artificial intelligence, winning several B2B journalism awards including a 2024 [Neal Award](https://siia.net/neals/) and a 2025 [Azbee Award](https://siia.net/neals/) for best instructional content and best how-to article, respectively. He currently focuses on software development tools and technologies and major programming languages including Python, Rust, Go, Zig, and Wasm. Tune into his weekly [Dev with Serdar](https://www.youtube.com/playlist?list=PLYaGSokOr0MNgQlbnq_qY7BJs9-TOAxHA) videos for programming tips and techniques and close looks at programming libraries and tools. More from this author
Shard	178 (laksa)
Root Hash	11067585635464083778
Unparsed URL	com,infoworld!www,/article/2338862/python-moves-to-remove-the-gil-and-boost-concurrency.html s443