The Python community had a very eventful month in the month of July 2021. The Python Software Foundation has filled what is believed to be the world’s first ever CPython Developer-in-Residence job with an individual who will work in a salaried capacity to develop CPython. Tracebacks and error messages have also received some much-needed attention from the CPython development team, as was mentioned in a previous item.
Let’s go into some of the most significant Python-related news from the past.
month!
CPython Has a Full-Time Developer-in-Residence
We highlighted the Python Software Foundation’s statement in our news roundup for the month of June, which said that they were looking to hire a CPython Developer-in-Residence. When Lukasz Langa was brought on board in July, the intentions of the PSF were finally able to be realised.
It’s possible that readers of Real Python are already aware with ukasz, who is a key developer for CPython and an active part of the Python community. On Episode 7 of the Real Python Podcast, presenter Chris Bailey was joined by ukasz to discuss the history of the Black code formatter, his time spent working as the Python release manager for versions 3.8 and 3.9, and how he integrates his passion for music with Python.
ukasz is the first CPython Developer-in-Residence, and as such, he is accountable for a variety of responsibilities.
for:
- Addressing pull requests and issue backlog
- Performing analytical research to understand volunteer hours and funding for CPython
- Investigating project priorities and their tasks going forward
- Working on project priorities
In the statement that he made announcing his new post, Lukasz recalls how he felt when he heard that the PSF was going to be employing new members:
When the Python Software Foundation (PSF) originally announced the Developer in Residence position, I instantly felt an overwhelming sense of optimism for Python. In my opinion, it has the potential to be a game-changing position for the whole project. In a nutshell, I think that the purpose of the Developer in Residence (DIR) programme is to quicken the pace at which everyone else goes through the developer experience. This includes not just the core development team but, more crucially, the drive-by contributors who are generating bugs on the tracker and making pull requests. ( Original Language)
During the week, Lukasz updates his own website with a series of weekly reports that detail the job that he has completed. In the first week that he was on the job, he was responsible for closing fourteen problems and fifty-four pull requests (PRs), reviewing nine PRs, and authoring six PRs of his own.
In his very first weekly report, Lukasz cautions his readers not to “get too enthused about those statistics.” “Because of the way CPython is developed, the majority of changes are implemented first on the main branch, and then they are ported to Python 3.10 and often also to Python 3.9. Hence, some of those changes are magnified by a factor of three.
The openness that is provided by the weekly reports is invigorating, and it gives a one-of-a-kind insight at what goes on behind the scenes of the position. Future candidates will have access to a wonderful resource that will assist them in comprehending what the job requires, what is performing effectively, and what areas have room for development.
ukasz was responsible for writing two weekly reports in
July:
The series has been continuing throughout the month of August. Every report has a section called “Highlights,” which describes a few of the most fascinating problems that Lukasz encountered while working on them over the previous week. This section, in particular, is enjoyable to read due to the extensive discussion of language features and bug solutions that it contains.
Congrats are in order for Lukasz on his recent promotion to the position of CPython Developer-in-Residence. Real Python can’t wait to see what he does during his time in office and is overjoyed that the Python Software Foundation was able to effectively establish and fill the position.
role.
Python 3.11 Gets Enhanced Error Reporting
The release of Python 3.10 is almost around the horizon, and as we noted back in May, the new interpreter will have some enhancements made to it in terms of how it handles error messages. Python 3.11 will see the continuation of work on mistake corrections.
You got it just perfectly! Despite the fact that Python 3.10 won’t be made available to the public until October, development on Python 3.11 has already begun.
way!
Fine-Grained Error Locations in Tracebacks
Pablo Galindo, the release manager for Python 3.10 and 3.11, said in a tweet dated July 16, 2021 that he and the team have successfully completed the implementation of PEP 657. This Python Enhancement Project (PEP) provides support for “fine grained error locations in tracebacks” and represents a considerable boost to the user experience for both novice and seasoned Python programmers. Fun fact: A
The PEP is a.
Python Improvement Proposal and is the main mechanism in which suggested additions to the Python language are documented and communicated within the core Python development team. Reading more about PEPs is one way to get more knowledge about them.
PEP 1 is the very first PEP to be completed!
Consider the following bit of code, which gives the value 1 to the key “d” in a nested dictionary called x. This is a good example of how fine-grained the new error location reporting is since it shows how the value is assigned.
:
x["a"]["b"]["c"]["d"] = 1
Execution of the below code snippet will result in the generation of a TypeError if any of the values associated with the keys “a,” “b,” or “c” are None in any version of Python 3 up to and including Python 3.10. This error will inform you that you cannot subscript a NoneType.
:
Traceback (most recent call last):
File "test.py", line 2, in <module>
x['a']['b']['c']['d'] = 1
TypeError: 'NoneType' object is not subscriptable
This mistake is correct, but it does not contribute in any way to the discussion. Which value is equivalent to None? Which of the values found at x[a], x[b], or x[c] corresponds to the correct one? Identifying the precise position of the issue sometimes calls for more debugging, which may be both time-consuming and expensive.
The same line of code executed with Python 3.11 generates a traceback that includes a number of illuminating comments that pinpoint the location of the None value.
located:
Traceback (most recent call last):
File "test.py", line 2, in <module>
x['a']['b']['c']['d'] = 1
~~~~~~~~~~~^^^^^
TypeError: 'NoneType' object is not subscriptable
The letters that look like carets indicate the precise position of the NoneType. The responsible party is x[“c”]! No more guessing, no more debugging. Just reading the error message will provide you with all of the information that you need to determine what caused the mistake.
The Python community responded positively to this modification by applauding enthusiastically. At the time that this article was being written, Pablo’s tweet had received over four thousand likes, and the comments section was full with Python developers expressing their appreciation.
A number of the developers have been successful in discovering edge situations that aren’t supported at the moment, at least not in the implementation that’s presently in place. Will McGugan, for instance, questioned whether or not the newly implemented location reporting would operate as intended for Asian characters and emojis. This Twitter discussion provided more evidence that there was no support.
The shift will come with its own set of expenses. According to what is stated in the PEP, the implementation calls for “adding new data to every bytecode instruction.” A fun tidbit about Python is that it is often referred to as an
language that has been understood, however this is not quite correct. In point of fact, Python source code is
distilled down to a language with lower-level functionality called
the bytecode format. It is not the Python code you write but rather the bytecode instructions that are produced by the compiler that are interpreted by CPython.
Check out for further information on the inner workings of CPython, which may be found at.
Here on this site is your guide to the CPython source code.
Python in its purest form.
The standard library’s.pyc files have become 22% larger as a direct consequence of the additional bytecode instructions being included in the library. While it may seem like a substantial jump, the actual increase is just approximately 6 megabytes, and the group that is in charge of the PEP is of the opinion that:
[T]
This is a highly acceptable figure due to the fact that the order of magnitude of the overhead is relatively minimal, particularly when taking into consideration the storage capacity and memory capacities of contemporary computers…
We are aware that the additional cost of this information may not be suitable for some users, and as a result, we have proposed an opt-out mechanism. This mechanism will ensure that generated code objects do not contain the additional information, and it will also make it possible for pyc files to avoid including the additional information. (
) Original Source
The opt-out approach includes a brand new PYTHONDEBUGRANGES environment variable in addition to a brand new command line option.
You may learn more about the recently implemented changes to error location reporting by reading PEP 657. Further working examples of this feature may be found in the “What’s New in Python 3.11” section of the documentation.
document.
Improved Error Messages for Circular Imports
In his weekly report for the week of July 19–26, CPython Developer-in-Residence ukasz Langa noted that an improved error message for circular imports had been introduced to Python 3.11.
Take into consideration the following product
structure:
a
├── b
│ ├── c.py
│ └── __init__.py
└── __init__.py
The following line may be found inside the a/b/ init .py file:
code:
import a.b.c
This piece of code may be found in the c.py file.
code:
import a.b
As a consequence of this, the dependency between package b and module c exists, despite the fact that module c also relies on package b. This structure will produce a mysterious error in all versions of Python before to 3.10, including the current version.
message:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/private/tmp/cpymain/a/b/__init__.py", line 1, in <module>
import a.b.c
File "/private/tmp/cpymain/a/b/c.py", line 3, in <module>
a.b
AttributeError: module 'a' has no attribute 'b'
Many Python programmers have been driven to distraction and annoyance by messages just like this one.
The revised error message has been made much more clear as a result of a pull request made by CPython contributor Filipe Lans.
clearer:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/private/tmp/cpymain/a/b/__init__.py", line 1, in <module>
import a.b.c
^^^^^^^^^^^^
File "/private/tmp/cpymain/a/b/c.py", line 3, in <module>
a.b
^^^
AttributeError: cannot access submodule 'b' of module 'a'
(most likely due to a circular import)
Is there any alternative parenthesis that might have prevented so much head-banging?
At the time of this writing, it is not known for certain whether or not this modification has been backported to Python 3.10. It’s possible that you won’t be able to notice the new error until after one more release cycle.
message.
What’s Next for Python?
Python had a number of noteworthy advancements in July. At Real Python, we are really enthusiastic about the future of Python and can’t wait to find out what exciting new things are in store for us in the month of August.
Which of the recent Python-related announcements did you enjoy reading the most? Have we overlooked anything of note? If you let us know in the comments, we could include you in the summary of Python news we do the next month.
Happy Pythoning!