Thursday, May 26, 2022

PyCon JP Association Awarded the PSF Community Service Award for Q4 2021

The PyCon JP Association team was awarded the 2021 Q4 Community Service Award.

RESOLVED, that the Python Software Foundation award the 2021 Q4 Community Service Award to the following members of the PyCon JP Association for their work in organizing local and regional PyCons, the work of monitoring our trademarks, and in particular organizing the "PyCon JP Charity Talks" raising more than $25,000 USD in funds for the PSF: Manabu Terada, Takanori Suzuki, Takayuki Shimizukawa, Shunsuke Yoshida, Jonas Obrist.

We interviewed Jonas Obrist on behalf of the PyCon JP Association to learn more about their inspiration, their work with the Python community, and supporting the Python Software Foundation - PSF. Débora Azevedo also contributed to this article, by sharing more light on the PyCon JP Association's efforts and commitment to the Python community.

Jonas Obrist Speaks on the motivation behind the PyCon JP Association

What inspired the PyCon JP Association team into raising funds to support the PSF?

We were inspired to raise funds after reading an announcement by the PSF about the impact of the pandemic on the foundation and PyCon US. We could of course empathize with the struggle given that we have a similar situation, even if on a much smaller scale.

We tried to think of a good way to help and either Manabu or Takanori came up with the idea to host online events with presentations by members of the community with all proceeds going to the PSF. We held two such events so far with over a hundred attendees and even managed to gather some companies and individuals as sponsors. 

Thanks to the online nature, costs were kept very low and we were able to make a sizeable donation to the PSF, hopefully softening the financial blow of the pandemic a bit.

How do you think other Python communities can support the PSF?

I think other communities have various ways to support the PSF depending on each community's situation.

We have the fortune to be well established with great support from the wider community and especially local companies, so we were able to make a direct financial contribution

Not all communities are this fortunate, but I think there are still other ways to contribute.

One such way is simply to boost awareness of the Python programming language in the local developer community. ideally, this would eventually lead to companies adopting Python more widely, which in turn could lead to direct support to the PSF, either via direct donations or support of PyCon US by these companies.

Boosting local communities also leads to more Python developers in general, leading to a broader pool of people who could support the PSF in various ways.

The most important thing is for each community to think about what they can do, even if it is just a small thing, given that we owe so much to the PSF.

Débora Azevedo speaks about the impact and significance of the PyCon JP Association

One of the things I am most excited about is seeing the PyCon JP Association team receiving this CSA and realizing that the work being done outside the US-Europe countries is acknowledged.

PyCon JP association has risen to the financial challenge that the PSF went through due to the pandemic and has organized PyCon JP Charity Talks. Aiming to increase awareness within the industry about the importance of the PSF is so meaningful. The charity talks were initiatives by the PyCon JP association, and it was a significant effort on their part. Their work is such an outstanding work that shouldn't be overlooked.

As part of the wider Python community, it warms my heart to see that there are many amazing people worldwide working so we can have a more sustainable Python community.

Seeing local communities contributing to the global community, especially regarding this financial aspect, shows that the community feels the need to have different types of work done and understands the importance and impact of each one of them.

And, as part of the Diversity and Inclusion workgroup and understanding the impact of seeing people from non-US-based communities being acknowledged for doing the work, it feels like we are being heard.

The PyCon JP association's community work is outstanding and I am so grateful to them and for being in a community that values each contribution to its development and growth.

The Python Software Foundation congratulates and celebrates the PyCon JP association team -  Manabu TeradaTakanori SuzukiTakayuki ShimizukawaShunsuke YoshidaJonas Obrist.

You can learn more about making a donation to the PSF here.

Wednesday, May 11, 2022

The 2022 Python Language Summit: Lightning talks

These were a series of short talks, each lasting around five minutes.


Read the rest of the 2022 Python Language Summit coverage here.



Lazy imports, with Carl Meyer

Carl Meyer, an engineer at Instagram, presented on a proposal that has since blossomed into PEP 690: lazy imports, a feature that has already been implemented in Cinder, Instagram’s performance-optimised fork of CPython 3.8.

What’s a lazy import? Meyer explained that the core difference with lazy imports is that the import does not happen until the imported object is referenced.

Examples

In the following Python module, spam.py, with lazy imports activated, the module eggs would never in fact be imported since eggs is never referenced after the import:


# spam.py import sys import eggs def main(): print("Doing some spammy things.") sys.exit(0) if __name__ == "__main__": main()


And in this Python module, ham.py, with lazy imports activated, the function bacon_function is imported – but only right at the end of the script, after we’ve completed a for-loop that’s taken a very long time to finish:


# ham.py
import sys
import time
from bacon import bacon_function def main(): for _ in range(1_000_000_000): print('Doing hammy things') time.sleep(1) bacon_function()
sys.exit(0) if __name__ == "__main__": main()


Meyer revealed that the Instagram team’s work on lazy imports had resulted in startup time improvements of up to 70%, memory usage improvements of up to 40%, and the elimination of almost all import cycles within their code base. (This last point will be music to the ears of anybody who has worked on a Python project larger than a few modules.)

Downsides

Meyer also laid out a number of costs to having lazy imports. Lazy imports create the risk that ImportError (or any other error resulting from an unsuccessful import) could potentially be raised… anywhere. Import side effects could also become “even less predictable than they already weren’t”.

Lastly, Meyer noted, “If you’re not careful, your code might implicitly start to require it”. In other words, you might unexpectedly reach a stage where – because your code has been using lazy imports – it now no longer runs without the feature enabled, because your code base has become a huge, tangled mess of cyclic imports.

Where next for lazy imports?

Python users who have opinions either for or against the proposal are encouraged to join the discussion on discuss.python.org.



Python-Dev versus Discourse, with Thomas Wouters

This was less of a talk, and more of an announcement.

Historically, if somebody wanted to make a significant change to CPython, they were required to post on the python-dev mailing list. The Steering Council now views the alternative venue for discussion, discuss.python.org, to be a superior forum in many respects.

Thomas Wouters, Core Developer and Steering Council member, said that the Steering Council was planning on loosening the requirements, stated in several places, that emails had to be sent to python-dev in order to make certain changes. Instead, they were hoping that discuss.python.org would become the authoritative discussion forum in the years to come.



Asks from Pyston, with Kevin Modzelewski

Kevin Modzelewski, core developer of the Pyston project, gave a short presentation on ways forward for CPython optimisations. Pyston is a performance-oriented fork of CPython 3.8.12.

Modzelewski argued that CPython needed better benchmarks; the existing benchmarks on pyperformance were “not great”. Modzelewski also warned that his “unsubstantiated hunch” was that the Faster CPython team had already accomplished “greater than one-half” of the optimisations that could be achieved within the current constraints. Modzelewski encouraged the attendees to consider future optimisations that might cause backwards-incompatible behaviour changes.



Core Development and the PSF, with Thomas Wouters

This was another short announcement from Thomas Wouters on behalf of the Steering Council. After sponsorship from Google providing funding for the first ever CPython Developer-In-Residence (Łukasz Langa), Meta has provided sponsorship for a second year. The Steering Council also now has sufficient funds to hire a second Developer-In-Residence – and attendees were notified that they were open to the idea of hiring somebody who was not currently a core developer.



“Forward classes”, with Larry Hastings

Larry Hastings, CPython core developer, gave a brief presentation on a proposal he had sent round to the python-dev mailing list in recent days: a “forward class” declaration that would avoid all issues with two competing typing PEPs: PEP 563 and PEP 649. In brief, the proposed syntax would look something like this:



forward class X() continue class X: # class body goes here def __init__(self, key): self.key = key


In theory, according to Hastings, this syntax could avoid issues around runtime evaluation of annotations that have plagued PEP 563, while also circumventing many of the edge cases that unexpectedly fail in a world where PEP 649 is implemented.

The idea was in its early stages, and reaction to the proposal was mixed. The next day, at the Typing Summit, there was more enthusiasm voiced for a plan laid out by Carl Meyer for a tweaked version of Hastings’s earlier attempt at solving this problem: PEP 649.



Better fields access, with Samuel Colvin

Samuel Colvin, maintainer of the Pydantic library, gave a short presentation on a proposal (recently discussed on discuss.python.org) to reduce name clashes between field names in a subclass, and method names in a base class.

The problem is simple. Suppose you’re a maintainer of a library, whatever_library. You release Version 1 of your library, and one user start to use your library to make classes like the following:

from whatever_library import BaseModel class Farmer(BaseModel): name: str fields: list[str]


Both the user and the maintainer are happy, until the maintainer releases Version 2 of the library. Version 2 adds a method, .fields() to BaseModel, which will print out all the field names of a subclass. But this creates a name clash with your user’s existing code, wich has fields as the name of an instance attribute rather than a method.

Colvin briefly sketched out an idea for a new way of looking up names that would make it unambiguous whether the name being accessed was a method or attribute.



class Farmer(BaseModel): $name: str $fields: list[str] farmer = Farmer(name='Jones', fields=['meadow', 'highlands']) print(farmer.$fields) # -> ['meadow', 'highlands'] print(farmer.fields()) # -> ['name', 'fields']