Lightning Talks Part 1 - Python Language Summit 2020

Sumana Harihareswara

What do you need from pip, PyPI, and packaging?

Python packaging has seen relatively quick development in recent years as a result of increased funding; most famously the new PyPI.org website was launched in 2018. The current work in progress includes malware detection and signed packages on PyPI, a new dependency resolver for pip, and a revamp of virtualenv. Much of this work is funded by grants from companies. (Details on the Working Group page.) Sumana Harihareswara from the Packaging Working Group is a prolific grant proposal writer; she presented ideas for further development.

Read more 2020 Python Language Summit coverage.

---

Python packaging ideas for the future include:

• Better specifications, toolchain, and services for building distributions
  
• Robust interoperability testing
  
• Revamp PyPI API
  
• Make setuptools the reference implementation of the distutils API
  
• Provide more standardized editable installations
  
• Add support for pyproject.toml as a way to configure setuptools
  
• Create & maintain a generic wheel-builder
  
• PEP 480: secure the developer-to-user supply chain
  
• Implement perennial manylinux (PEP 600)

Harihareswara solicited packaging ideas from the audience to inform the Python Packaging Authority roadmap and the Fundable Packaging Improvements page, asked them to add their complaints to the packaging problems list, and requested help writing grant proposals.

Since Harihareswara had listed a revamp of virtualenv among the works in progress, Barry Warsaw wondered what advantages virtualenv has over venv, which is now built in to all supported Python versions. Bernat Gabor, who maintains virtualenv, answered that virtualenv is faster, provides a richer API for tools built on it, and serves as a laboratory for ideas that might be merged into venv.

Ernest W. Durbin III provided a status update on malware checking: the framework is in place but only two checks have been implemented, "mainly for demonstration." He has invited security researchers to implement more checks.

David Mertz asked whether pip's new dependency resolver would be able to resolve dependency conflicts. Paul Moore said he is still researching what users want pip to do in the case of conflicts, and what solutions are provided by resolver algorithms. The new resolver is about to be released, but it is still alpha-level and will be turned off by default.

Eric Snow

A Retrospective on My "Multi-Core Python" Project

Of all the schemes for freeing CPython from the Global Interpreter Lock, the frontrunner is Eric Snow's plan to give each subinterpreter its own lock. He proposed the idea in 2015, began discussing and prototyping the idea intensely, and burned out the next year. "I was trying to do too much on my own," said Snow. In 2017 he resumed development, this time with dozens of collaborators, and wrote PEP 554 to expose subinterpreters to pure Python programs, which will ease testing for the multi-core project. He presented his progress to the Language Summit in 2018 and in a 2019 PyCon talk. His TalkPython interview last year was especially effective at drawing attention to the project.

Snow's immediate blocker is PEP 554's acceptance and implementation, but much work remains after that. He told the 2020 Language Summit, "I've just been chugging along, little by little. Lots of little pieces to get this project done!" Hard problems include passing data safely between subinterpreters, the "grind" of removing all the global variables, and reaching the actual goal: creating a distinct GIL per subinterpreter. Snow predicts the split GIL won't land in Python 3.9, but "3.10 for sure."

Snow thanked a large list of contributors, many of them outside the core developer team.

Kyle Stanley asked whether daemon threads should be still be allowed in subinterpreters or not. (Victor Stinner tried to ban them but had to revert his change.) Snow replied that daemon threads in subinterpreters lead to many finalization problems, and their use should be discouraged, but removing them entirely has proven too disruptive for the core team to accomplish any time soon.

The 2020 Python Language Summit

The Python Language Summit is a small gathering of Python language implementers (both the core developers of CPython and alternative Pythons), as well third-party library authors and other Python community members. The Summit features short presentations followed by group discussions. In 2020, the Summit was held over two days by videoconference; questions were asked by a combination of voice and chat. It was led by Łukasz Langa and Mariatta Wijaya.

Thanks to MongoDB for sponsoring the Python Language Summit.

---

Day 1

Should All Strings Become f-strings?
Eric V. Smith

Replacing CPython’s Parser with a PEG-based parser
Pablo Galindo, Lysandros Nikolaou, Guido van Rossum

A Formal Specification for the (C)Python Virtual Machine
Mark Shannon

HPy: a Future-Proof Way of Extending Python?
Antonio Cuni

CPython Documentation: The Next 5 Years
Carol Willing, Ned Batchelder

---

Day 2

Lightning talks round 1
Sumana Harihareswara, Eric Snow

The Path Forward for Typing
Guido van Rossum

Property-Based Testing for Python Builtins and the Standard Library
Zac Hatfield-Dodds

Core Workflow Updates
Mariatta Wijaya

CPython on Mobile Platforms
Russell Keith-Magee

Lighting talks round 2
Zac Hatfield-Dodds, Jim Baker, Eric Holscher, Mariatta Wijaya

---

Image: Natal Rock Python

The path forward for typing - Python Language Summit 2020

"There are a lot of PEPs about typing!" said Guido van Rossum at the Language Summit. Since 2014 there have been ten PEPs approved for Python's type-checking features. Two of them have been approved already this year: the relatively "esoteric" PEP 613: Explicit Type Aliases, and another that will have widespread impact, PEP 585: Type Hinting Generics In Standard Collections, written by Łukasz Langa and mainly implemented by Van Rossum. Thanks to this PEP, types which had been defined like List[int] can now be spelled list[int], with a lowercase "L". As Van Rossum told the Python Language Summit, "We want to avoid a world where users have to remember, 'Here I have to use a capital-L List and here I use a lowercase-L list.'"

Read more 2020 Python Language Summit coverage.

---

A "generic" is a type that can be parameterized with other types. Generics are usually container types. Since Python 3.5, the typing module has provided "type aliases" like List, which can be parametrized with the type of values it contains, like List[str] in this type-annotated function definition:

from typing import List
def greet_all(names: List[str]) -> None:
    for name in names:
        print("Hello", name)

Van Rossum showed the Summit the following code, demonstrating that the ordinary built-in list and dict classes can now be used as generics for type annotations:

>>> p = list[int]
>>> p
list[int]
>>> p.__origin__
<class 'list'>
>>> p.__args__
(<class 'int'>,)
>>> p((1, 2, 3))
[1, 2, 3]
>>> from typing import TypeVar; T = TypeVar("T")
>>> dict[str, T][int]
Dict[str, int]

The syntax list[int] is enabled by implementing __class_getitem__ on list. The built-in containers such as tuple, dict, list and set are supported, along with some standard library containers and abstract base classes, including collections.deque, collections.abc.Iterable, queue.Queue, and re.Pattern. The effect for everyday coders is mainly a matter of spelling, yet as Van Rossum said, "It's probably going to affect everyone's code, or everyone will encounter code like this." Fewer users will have to import type aliases such as List from the typing module; it will be required only for advanced annotations. Van Rossum asked the Summit, "How much of this do we want to make built in?"

Python's approach to type-checking is to add type annotations in the source code, but to check types neither during compilation nor at runtime. Instead, programmers use a separate type-checker (such as mypy or PyCharm). The new PEP 585 type annotations are the same: they do no checking at all, so "nonsense" annotations like list[str, str] are permitted. It is the type checker's job to reject them.

Annotations are not completely free at runtime, however: by default an annotation like List[int] is evaluated to create a type object when it is encountered, usually at module-load time. This can noticeably hurt startup times for big type-annotated programs. PEP 563 Postponed Evaluation of Annotations was introduced in Python 3.7 to solve this problem: type annotations are saved as strings, and evaluated only when a type checker such as mypy requests it. This optimization is currently guarded behind from __future__ import annotations. Van Rossum asked whether postponed evaluation should become the default in Python 3.9, which will be released imminently, or 3.10.

Also in Python 3.10 will be PEP 604, which permits the current Union[t1, t2] annotation to be spelled as t1 | t2, using the vertical bar to express a union of types. The PEP's scope might expand to add syntax that even programs without type annotations would enjoy. For example, isinstance(x, (t1, t2)) could be written isinstance(x, t1 | t2), and an exception handler could be written like except t1 | t2.

Yury Selivanov noted that typing.Optional[t] could be replaced with t | None, and asked whether it could be shortened further as t?. "Every year," replied Van Rossum, "there's another feature that people want to use the question mark for." In his opinion, t | None is convenient enough, and another syntax would be redundant. (Although the new PEG parser would make it easy to implement.)

Stéphane Wirtel asked if Python would ever have exception annotations. "Ouch!" said Van Rossum. The consensus is that Java's checked exceptions were a bad idea, and would probably be bad in Python too. "I don't think I have the stomach for that."

The standard library and most PyPI packages have no type annotations. Type-hinted "package stubs" for this code are hosted in the typeshed repository, but storing all those stubs in a monolithic distribution doesn't scale, and the problem will grow worse. In a GitHub issue thread, Jukka Lehtosalo predicted that in two years, stubs for third-party packages will outnumber those for the standard library, and in five years, typeshed will include more than 1000 third-party packages. As Van Rossum told the Language Summit, Lehtosalo's proposal will split typeshed into separate distributions so users can easily download just the stubs they need, consistent with PEP 561.

Brett Cannon asked whether the standard library's annotations should be shipped with Python, either as stub files or in the code itself. Van Rossum said new stdlib code should be written with annotations inline, but old code includes optimizations and strange legacy behaviors that defy static typing. Currently mypy does not analyze standard library code because "it assumes that the standard library is full of untyped shit," it looks in typeshed instead. If indigenous type annotations grew in the standard library, the core team would have to coordinate with type checker authors to manage the change.

Van Rossum offered an update on mypy. He admitted he hadn't been active on mypy recently, and "my former colleagues at Dropbox have not been able to make as much progress as we did in the past." Support for NumPy is stalled. The same goes for decorators, although once PEP 612 is approved it will provide a prerequisite for decorator support in mypy. Raymond Hettinger asked if mypy development needs funding. Michael Sullivan, a mypy contributor from Dropbox, replied that Dropbox considers mypy mostly complete, and has moved on to projects like their Python 3 migration. Van Rossum said funding could help. Personally he has "moved on to retirement." The Python static typing mailing list is quieter than Van Rossum would like, interested people should join.

There's better news about mypyc, an experimental project to translate type-annotated Python into C. The translator's main use for now is converting mypy to C for speed. There is work in progress to allow a mix of Python and Python-translated-to-C in the same program, and to write documentation. The mypyc project expects a Google Summer of Code student this summer.

CPython Documentation: The Next 5 Years - Python Language Summit 2020

"Documentation is the way we communicate with each other," said Willing. "Historically, we've done a great job with documentation." But the environment is changing: Python's BDFL has retired, and Python's user base is expanding, becoming more global, and moving away (to some degree) from lower-level programming to higher-level applications. These changes impose new documentation burdens on the small core team. Willing said, "We don't scale well."

Read more 2020 Python Language Summit coverage.

---

Willing and Ned Batchelder proposed a new Python Steering Council workgroup called the "Documentation Editorial Board". Its members would include core developers and community members; they would write style guides, manage translations into non-English languages, and create a landing page that guides different kinds of users to the documentation that suits them. (Daniele Procida had shared earlier a guide to writing docs for a variety of users' needs.) The core team need not write all the docs themselves—they should be owned and written by the community, along with the core team, overseen by the new Editorial Board.

In the Editorial Board's first year it would focus on governance, translations, the new landing page, and tutorials. Willing was inspired by the core team's overhaul of the asyncio docs; they added tutorials and split the high-level information from the low-level. The rest of the standard library would serve users better with more tutorials like asyncio's. Style guides would ensure consistency and best practices. As Ned Batchelder pointed out, Python has two PEPs for code style (one for C and one for Python), but none for documentation.

In its second year, the Board would measure its effectiveness so far, and begin running documentation sprints. Willing recommends the Board begin annual editorial reviews, seeking patterns of user confusion: "When users ask questions on mailing lists and the bug tracker, it means something's not clear to them." Updating the documentation to fix common misunderstandings would save time in the long run for users and the core team.

Batchelder observed that "twenty-five years ago, our main audience seemed to be refugees from C," but most readers of the Python docs today are not career software developers at all; they need different docs.

Raymond Hettinger asked, "Any thoughts on why no one stepped up to write any docs for the walrus operator? I'm not seeing people volunteering for major documentation efforts. Mostly the contributions are minor, micro edits." Willing replied that the walrus operator specifically was a "hot potato" that deterred volunteers. In general, the Python core team doesn't encourage others to lead big documentation projects; community members don't have a sense of ownership over the docs, nor the authority to merge their changes, so skilled writers take their efforts elsewhere. The proposed new Editorial Board would help to change that.

Sumana Harihareswara asked how documentation work would be funded, and whether professional technical writers might be involved. Willing replied that the PSF will fund some work, but she emphasized recruiting volunteers from the community. Several in the audience asked about making a "core documenter" role analogous to "core developer"; Batchelder replied that fine-grained roles and permissions in open source projects are counterproductive. People who write excellent documentation should simply be promoted to core developers.

HPy: a future-proof way of extending Python? - Python Language Summit 2020

Antonio Cuni presented HPy (pronounced "aitch pi"), an attempt at a replacement C API that is compatible and performant across several interpreter implementations. The idea was born at EuroPython last year from a discussion among CPython, PyPy, and Cython developers.

Read more 2020 Python Language Summit coverage.

---

CPython's API for C extensions is tightly coupled with the interpreter's internals. Another interpreter such as Jython, if it wants to support the same C extensions, must emulate these internals, pretending to the C extension that the interpreter works the same as CPython. Even CPython suffers: any of its internals that are exposed in the C API can't be improved without breaking compatibility. Python objects in the C API are pointers to CPython's PyObject structs, whose internal layout is partly exposed to extensions. Extensions expect each PyObject pointer to be constant for the object's lifetime, which prevents a memory manager like PyPy's from moving objects during garbage collection.

Most prominently, the C API requires extensions to control objects' lifetimes by incrementing and decrementing their reference counts. Any Python implementation that does not have a reference-counting memory manager, such as PyPy, must emulate refcounts for the sake of the C API. Cuni calls this a "massive amount of precious developer hours wasted," an impediment to performance, and the main obstacle for Larry Hastings's GILectomy.

Victor Stinner has already outlined the design for a better C API that hides some internals, but still depends on reference-counting; Cuni confronts the same questions and gives a more radical answer.

HPy is a new C API that is interpreter-agnostic. Instead of PyObject pointers, HPy presents handles (hence the "H" in its name). Where a C API user would incref a PyObject when copying a reference to it, an HPy user would duplicate a handle. Each handle is distinct and must be closed independently. Cuni showed this code example:

/* C API */
PyObject *a = PyLong_FromLong(42);
PyObject *b = a;
Py_INCREF(b);
Py_DECREF(a);
Py_DECREF(a); // Ok
/* HPy */
HPy a = HPyLong_FromLong(ctx, 42);
HPy b = HPy_Dup(ctx, a);
HPy_Close(a);
HPy_Close(a); // WRONG!

Handles are HPy's basic departure from the C API. The independence of handles' liftimes, said Cuni, decouples HPy from CPython's ref-counting memory manager, and makes HPy a natural, fast C interface for other Pythons. PyPy, for example, will maintain a map of handles to objects; when its garbage collector moves objects in memory, it only needs to update the map. Handles permit precise debugging: if a handle is leaked, HPy prints the line number where it was created. (The HPy context parameter ctx that is passed everywhere allows for subinterpreters, and perhaps other features in the future.)

Brett Cannon asked whether HPy will be a minimalist API for extension development, or if it will include specialized APIs for speed. For example, the current C API has a generic PyObject_GetItem, and a fast PyDict_GetItem specialized for dicts. Cuni said he prefers a smaller API, but benchmarks would guide him.

Cannon asked whether a tool could semi-automatically port C code from the C API to HPy. It could not, according to Cuni, because the problem of closing each handle exactly once must be solved carefully by a human. HPy's debug messages will be a great help. "In theory," Cuni said, "it should be as easy as adding an 'H' to all C API calls, renaming Py_INCREF to HPy_Dup, putting HPy_Close here and there, and then see if the debug mode is happy or complains."

Victor Stinner asked whether his draft proposal to incrementally modify the C API to hide internals would eventually solve PyPy's problems with C extensions. Cuni replied, "It's not enough for PyPy because of reference counting and the fact that PyObject* is not a good representation for objects that can move in memory." But he acknowledged that Stinner's proposal goes in the right direction.

Cuni said the "HPy strategy to conquer the world" is to create a zero-overhead façade that maps HPy to the C API (using compile-time macros), then port third-party C extensions to pure HPy, one function at a time. It must be faster on alternative implementations than their existing C API emulations; early benchmarks show a 3x speedup on PyPy and 2x on GraalPython, a JVM-based Python.

HPy is currently missing type objects, but Cuni said it "basically works." An HPy extension can be compiled to the CPython ABI or to an "HPy universal ABI" that allows the same compiled extension to work with multiple interpreters. In the future, a new Cython backend will target HPy instead of the C API. Cuni and his collaborators have ported ujson to HPy; they plan to port a subset of NumPy next, and eventually to write a PEP and merge HPy into the official CPython distribution, where it will live alongside the existing C API. Cuni hopes the core developers will endorse HPy for third-party C extension development; in a "hypothetical sci-fi future" CPython might port its standard library C modules to HPy.

A formal specification for the (C)Python virtual machine - Python Language Summit 2020

Mark Shannon began his presentation saying, "This should actually be titled A Semi-Formal Specification. I don't think we'll ever get to the stage of ML," a language described with mathematical rigor. However, a more formal definition of Python would be useful. Authors of alternative Python implementations would have a standard to go by, besides reading CPython's source and testing for equivalent behavior on a variety of programs. "It seems to work for Java so I don't see why it wouldn't work for Python," said Shannon. It would be particularly helpful for anyone who wants to examine a part of the language. Today, one cannot understand CPython's bytecode interpreter without studying all its quirky interactions with the C API, the code loader, and so on; a Python specification would break down the language into domains that could be grasped separately.

A specification would clean up edge cases. Shannon said there are "too many weird bugs relating to interactions of threads and generators and locals and various other bits and pieces." If the language were defined, developers would at least know how it's supposed to behave.

Read more 2020 Python Language Summit coverage.

---

Shannon proposed to split Python's specifications into major components: code loading (including imports and parsing), execution, and the C API. The components' specs would be allowed to refer to each other, but only at a high level. In his Language Summit presentation, Shannon focused on the execution component.

A Python execution spec would define the virtual machine (VM) as a set of variables, such as the list of threads and their call stacks, and it would define small steps that transition from one VM state to the next. For example, a Python function call involves these steps:

• Create a new stack frame
  
• Move arguments from current frame to the new one
  
• Save the next instruction pointer
  
• Push the new frame onto the call stack
  
• Continue

Every definition ends with "continue", meaning that the interpreter proceeds to the next step.
Writing a specification for Python is a chance to rethink how its parts relate. CPython's generators are implemented in terms of iterators, because iterators were built first. But generators are a more basic and flexible concept; starting from scratch it's natural to define iterators in terms of generators. Shannon presented a sketch of such a definition.

The next steps for Shannon's project are to define the spec's format, list its components, and decide what to do about "awkward" language features such as sys.settrace(). He concluded that a semi-formal spec of Python would help alternative implementations match CPython, would make PEPs less ambiguous, and would clarify whether any existing "odd behavior is a feature or a bug." It would be possible to reason about the correctness of optimizations. However, writing the spec is work, and it could deter good PEPs in the future if authors are daunted by writing their proposals in terms of the spec.

The audience's questions revealed their confusion about Shannon's idea. Larry Hastings admitted he had "lots of trouble following this." Was Shannon proposing a new language implementation based on the spec? Shannon said no, the spec's purpose was to describe and reason about CPython and other implementations. A. Jesse Jiryu Davis wondered if the spec would be written in a formal modeling language like TLA+ or Alloy, but Shannon felt that would discourage contributors. English would be the language of the spec; the JVM spec demonstrates this approach.

Brett Cannon asked if PEPs for new language features would require spec patches. Shannon replied that PEPs for deep changes, similar to the introduction of yield from in Python 3.3, would benefit if they were described in terms of the spec.

The presentation ended with the attendees saying a Python specification might be a good idea, but struggling to envision it and how it would be used in practice.

Replacing CPython’s parser - Python Language Summit 2020

Since its start, Python’s grammar has been LL(1): it needs only a left-to-right parser that looks one token ahead to resolve ambiguities. The standard CPython parser is produced by a simple custom parser generator. There are some costs to this simplicity, however. First, the official Python grammar file does not capture the language exactly. There are invalid constructs allowed by the grammar, for example, this assignment expression (using the new walrus operator):

[x for x in y] := [1, 2, 3]

This expression is illegal, because the left side of the walrus operator must be a name, not an arbitrary sub-expression like [x for x in y]. Python’s LL(1) parser is not powerful enough to enforce this rule, though, so it must be enforced after parsing by special-case logic that runs while transforming the parse tree into the abstract syntax tree (AST).

Worse, there is Python code that we would like to write but cannot, because it can’t be parsed. Parenthesized with-statements look reasonable but they’re currently prohibited:

with (
    open("a_really_long_foo") as foo,
    open("a_really_long_baz") as baz,
    open("a_really_long_bar") as bar
):
    ...

Read more 2020 Python Language Summit coverage.

---

Guido van Rossum, Pablo Galindo, and Lysandros Nikolaou wrote a new Python parser to excise these warts, and proposed PEP 617 to adopt it in CPython. The new parser is written in a more powerful style called a parsing expression grammar (PEG), so the project is named “PEGEN”.

When a PEG parser reads the beginning of a token sequence that could match several grammar rules, the parser tries each of those rules, from left to right, until one succeeds. For example, given a set of rules:

rule: A | B | C

The parser first tries to apply rule A to its input sequence. If A succeeds, the parser ignores B and C. Otherwise, the parser moves on and tries to apply rule B, and so on. Unlike an LL(1) parser, a PEG parser can look ahead as far as necessary to disambiguate a sequence. The grammar is deterministic: in cases where multiple rules match, the leftmost wins. Some sequences would require exponential time to find the matching rule; to prevent this, most PEG parsers (including the new Python parser) implement the “packrat” method to cache intermediate results. A packrat parser can process any input in linear time, but spends some memory on its cache.

PEGEN’s grammar is far more legible than the old one’s, and the grammar exactly matches all legal Python programs.

CPython’s old parser progresses in stages: the tokenizer feeds the LL(1) parser, which produces a concrete syntax tree (CST), which is transformed into the AST. The CST stage is necessary because the parser does not support left recursion. Consider this expression:

a + b + c

The old parser’s CST is too flat, as the presenters showed in this slide:

In real life, the expression will be evaluated at runtime by first adding a to b, then adding c. Unfortunately the CST does not encode this nested evaluation, so the LL(1) parser must transform the program a second time to turn the CST into an AST in the properly nested form, which can then generate bytecode. PEGEN, on the other hand, directly generates the AST. Depending on the program, PEGEN may use more or less memory: what it spends on the packrat method, it may save by skipping the CST.

Emily Morehouse tested PEGEN against the old parser by verifying they produce the same AST for every module in the standard library and the top 3800 PyPI packages. (PEGEN parses the standard library slightly faster than the old parser, but uses 10% more memory.)

Once Python has a non-LL(1) parser, its syntax may grow more grammatically complex; Victor Stinner asked if third-party Python parsers (such as linters and IDEs) might have difficulty. Van Rossum felt certain they could adopt more powerful parsers themselves, if necessary.

The authors plan to switch CPython to the new parser cautiously. In Python 3.9 alpha 6 the new parser will be opt-in; it will become the default in beta 1 and in the official 3.9 release, with the old parser still available by a command line switch. As soon as the new parser is enabled, parenthesized with-statements will be allowed! In Python 3.10 the old parser will be deleted. PEP 617 must still be approved, however, and the new code needs a final review.

The proposal met no opposition; in fact, several in the audience asked whether it could become the default sooner.

Building a Python community in Colombia: John Roa, 2018 Q4 CSA Recipient

PyCons take place throughout many parts of the world. Each PyCon is different in its own way;  drawing from its own geographical location as well as local history and culture. In 2017 another beautiful country opened its doors to a new PyCon, with the launch of PyCon Colombia. 

PyCon Columbia stands out for its attention to detail, superb planning, and well-curated content. "What struck me about PyCon Colombia was how well thought out and organized it is. Particularly for a fairly new conference, it was exceptional in how carefully and completely things had been organized," says Naomi Ceder, Chair of the PSF Board of Directors, who delivered the keynote at PyCon Colombia 2018. Reflecting this dedication, on the PyCon Colombia website the conference comments that it is one "made with love." Like a ship needs a captain for smooth sailing, a PyCon needs one too. John Rao is that person for PyCon Colombia as he has been the chair of PyCon Colombia since its first edition in 2017. It is for this reason that the Python Software Foundation is pleased to recognize John Roa for the 2018 Q4 Community Service Award:

The Q4 award also went to John Roa for his work as a founder and Conference Chair of PyCon Colombia.

PyCon Colombia: The beginning and challenges

In planning for the future of PyCon Colombia, John shared that the community is looking to:

Naomi speaks of John as a calm and warm ('but professional') person. She notes that he has all the qualities to give shape to and run a successful conference. Even in the preparation for this article, what was evident in the email conversations was his dedication to his team and the community. Lorena Mesa, a Director at the PSF, has worked with John before and describes him as a "wonderful person."  

 In his day job, John is the Director of Engineering at Lendingfront, a fin-tech company based in NYC. He started coding at the age of 15. Initially, John started his engineering career as a Java developer. In his own words, he never chose Python, but "Python chose me." The company he previously worked with, had Java as their primary technology but had a  side project written in Python too. He started working on that and fell in love with the simplicity of the language. 

In 2015 he partnered with his colleagues to reboot the Python community in Medellin, Colombia. This marked the beginning of a new journey, his journey towards the first PyCon Columbia. Since then these Pythonistas have been instrumental in organizing several Python meetups and workshops all over the city.  

Python Bogota and Python Cali started just a bit before John dedicated himself to rebooting the Medellin community, respectively in 2012 and 2014. Colombia had "the talent, the market" and the demand from the local developers to learn the language. There were all the elements for developing larger projects, but there was no place to bring the community together and to help it grow. Therein sparked the interest in starting a national Python conference and John decided to make it happen.

Like other conferences, PyCon Colombia also had its problems. First, in Colombia the native language spoken is Spanish. The local development community has some familiarity with English. But the more significant struggle was with attracting foreign speakers, who could neither speak nor understand Spanish. It was hard to get past the language barrier. To address this problem, they started a social media campaign for PyCon Colombia using both languages. They also took another approach to encourage Columbian speakers to give their talks in English. It was a significant step towards improving their skills and gaining confidence, and also it helped to minimize the language gap.

But according to John, the biggest challenge faced was "organizing volunteers, the difference between ‘I want to’ and ‘I am going to do it’" While organizing community events, many ideas and opinions will be shared, adding difficulties with execution. There are only a few people who do the hard work of actually carrying out all the details and ensuring the event comes to fruition. Moreover, for the volunteers trying to bring the plan forward, it was, "challenging to make room in their schedule to contribute to these projects."  Ultimately, John and his team were victorious and together they held the first PyCon Colombia in 2017. 

PyCon Colombia: Planning for the future

In planning for the future of PyCon Colombia, John shared that the community is looking to:

·  Develop Pycon Colombia into a renowned brand, initially in Latin America

· Reach over 500 attendees in 2021 

· Add other  Colombian cities to host 

· Continue to make the conference more inclusive and diverse.

 In order to reach these goals, the Python Colombia team will need to continue to work together and identify challenges, overcoming them together. This is all possible since as John says about his team "I admire how the co-organizers commit to a final goal and take full ownership of their tasks or responsibilities, they are always thinking on how to make the conference better, how to make a better impact in society with it, how to deliver more value to the participants."

So what is next for PyCon Colombia? PyCon Colombia 2020?

PyCon Colombia 2020 will be held in Medellin for three days starting on Friday, February 7th and ending on Sunday, February 9th.

And if that isn’t enough motivation to attend PyCon Colombia 2020, John shared an inspirational story of 12-year old David Martinez, who contacted the team seeking a scholarship to attend. The team was amazed to know that he is entirely self-taught from Codecademy and Udemy courses. He learned English at school and with Duolingo. He aims to become an AI developer. John says this "is such a great example of hope, for the childhood of this country."

We on behalf of the Python community wish John and PyCon Colombia team a successful PyCon Colombia 2020! 

Thank you to donors & sponsors

PyCon 2020 in Pittsburgh, PA was cancelled due to COVID-19 and that impacted the PSF's finances. Our blog from March 31st estimated that the PSF would need to use $627,000 of its financial reserve to get through 2020. 

Since the time we cancelled PyCon 2020, the PSF staff and PyCon volunteers have been working on PyCon 2020 Online, which is launching April 15 (subscribe here to get the content launch emails)!

During our planning process, we have seen an overwhelming amount of support from sponsors and registrants.

Over 40 sponsors have agreed to participate in PyCon 2020 Online and 418 individuals donated and/or converted their registration fees to donations. 

Thank you individual donors!

Thank you to the individuals that donated to the PSF as they registered for PyCon. Thank you to those that converted part or all of their PyCon registration fees into PSF donations. Thank you to the messages and tweets of support. Our hearts are full and our eyes are teary from the tremendous generosity we have seen.

Thank you sponsors!

Thank you to the sponsors that are participating in PyCon 2020 Online. Thank you to the organizations that stepped up from the beginning to stand by PyCon regardless. Thank you to the sponsors that checked-in on our staff throughout the process as well. Seeing those emails and being on calls with you all lifted our spirits in a very stressful time. Every video we put online will have this slide inserted because none of this could be possible with out these organizations:

Update on financial impact

Thanks to generosity of individual and corporate donors and decreasing PyCon 2020 expenses, we estimate that the PSF will now only need $141,713 from its financial reserve to get through 2020.  That is 77% better than what we initially anticipated!


In the coming month, the PSF will reassess its strategic goals for the coming year. Even though we will have to reevaluate taking on new projects, our team is going to work diligently to get the PSF back on track!

Python Software Foundation Fellow Members for Q1 2020

We are happy to announce our newest PSF Fellow Members for Q1 2020!

Q1 2020

Al Sweigart
Website, Twitter, GitHub

Alexandre Savio
Twitter, Website

Darya Chyzhyk
Twitter, GitHub, LinkedIn

Kenneth Love

Kevin O'Brien
Twitter, GitHub, LinkedIn

Serhiy Storchaka

Thea Flowers
Website, Blog, GitHub

Tom Christie
Website, Twitter

Congratulations! Thank you for your continued contributions. We have added you to our Fellow roster online.

The above members have contributed to the Python ecosystem by teaching Python, creating education material, contributing to circuitpython, contributing to and maintaining packaging, organizing Python events and conferences, starting Python communities in their home countries, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

Let's continue to recognize Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: https://www.python.org/psf/fellows/. If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at python.org. We are accepting nominations for quarter 2 through May 20, 2020.

Help Wanted!

The Fellow Work Group is looking for more members from all around the world! If you are a PSF Fellow and would like to help review nominations, please email us at psf-fellow at python.org. More information is available at: https://www.python.org/psf/fellows/.

Announcing a new Sponsorship Program for Python Packaging

The Packaging Working Group of the Python Software Foundation is launching an all-new sponsorship program to sustain and improve Python's packaging ecosystem. Funds raised through this program will go directly towards improving the tools that your company uses every day and sustaining the continued operation of the Python Package Index.

With this program we are asking companies that rely on Python, its ecosystem of packaging tools, and PyPI to help us build a dependable basis to continue our efforts. 

Improving the packaging ecosystem

Since 2017, the Packaging Working Group has secured multiple grants, completed one contract, and received a generous gift -- all with the goal of improving the Python packaging ecosystem for all users. Most of these projects were funded by not-for-profit organizations and all of them were one-time awards with specific objectives.

Results from these funded projects include:

• The successful relaunch of the Python Package Index, powered by the new 'Warehouse' codebase in 2018
• Adding security features to PyPI, including two-factor authentication in 2019
• Improving PyPI's web interface for users with disabilities and adding support for multiple locales in 2019
• Additional security-focused features for PyPI in 2019 and 2020
• Overhauling pip's user experience and dependency resolver in 2020

Companies have asked us how they can help fund the platform they depend on. With this new sponsorship program, the Working Group can sustainably fund packaging improvements not directed by a specific grant or contract and benefit millions of Python users around the world. Greater budget flexibility and a deeper reserve will help us invest in what the community needs.

Sustaining PyPI

As of April 2020, the Python Package Index responds to 800 million requests and delivers 200 million packages totalling 400 terabytes, during the typical day. Our users include hobbyists, scientists, companies, students, governments, nonprofits, and more.

Existing sponsors donate their services, which keeps PyPI free to users and to the PSF, aside from a subset of one staff member's time. Without these donations, the costs to operate PyPI each month would be staggering.

These critical service donations must not be taken for granted. Sponsoring the Packaging Working Group through this new program creates and maintains a stable reserve. We'll need that reserve in the event that we lose any of these in-kind service donations and must pay some or all of PyPI's operating costs.

Show your support!

As a company, your team can review the details of this new sponsorship program in our prospectus. Should you have any questions you can contact us at sponsorship@pypi.org. When you're ready, apply here. We are excited to hear from you!

If your company cannot donate: Even as an individual, your contributions count! No matter the size or frequency, please support us if you are able at donate.pypi.org.