# Steering Council nomination: Brett Cannon (2023 term)

**URL:** https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078
**Category:** Steering Council Nominations
**Created:** [November 14, 2022, 11:04pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078 "2022-11-14T23:04:08Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)
#### Post date: [November 14, 2022, 11:04pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/1 "2022-11-14T23:04:08Z")

</div>

I am self-nominating myself for the last time consecutively for the steering council; after 2023 I at least want to interrupt my self-nomination run to make sure you all aren’t voting for me just out of habit. 😉

I am currently the only SC member who has been on the council continuously since its founding (which is weird for me considering I was the youngest core developer when I got my commit privileges back in 2003), so if I am lucky enough to be elected again this would make it my 5th year on the council.

As I have said in previous years, if you’ve been happy with the SC then feel free to vote for me, but if you have been unhappy with it then please don’t vote for me.

While being on the SC isn’t about power (and honestly probably hurts you more than anything as you lose your own vote for any PEP you propose 😅), to give you an idea of where my head is and what I want to work on in 2023 I am hoping to develop:

1. Guidelines on the stdlib (i.e. what do we want it to be, guidelines on what should go in, how to manage it, etc.).
2. [WebAssembly](https://webassembly.org/) (and specifically [WASI](https://wasi.dev/)) to a tier 2 platform.

(I’m also still working towards lock/pinned dependencies files on the packaging side and doing stuff with the Python Launcher for Unix, but that’s outside of Python core).

And I’m purposefully keeping this short so you all have less to read. 😁

# Previous nominations

1. [2022](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2022-term/11839)
2. [2021](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2021-term/5633)
3. [2020](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2020-term/2566)
4. [2019](https://discuss.python.org/t/steering-council-nomination-brett-cannon/620)

---

<div class="post-metadata">

### Author: ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)
#### Post date: [November 15, 2022, 6:11pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/2 "2022-11-15T18:11:11Z")

</div>

> [@brettcannon](#):
>
> (I’m also still working towards lock/pinned dependencies files on the packaging side and doing stuff with the Python Launcher for Unix, but that’s outside of Python core).

I sure hope the SC is going to keep encouraging and factoring in these elements, whether “core” or not. They’re far more impactful on our users’ experiences than basically anything we do in the language or runtime right now, and don’t deserve to be left out of any grand visions or designs.

---

<div class="post-metadata">

### Author: ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)
#### Post date: [November 15, 2022, 7:28pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/3 "2022-11-15T19:28:37Z")

</div>

> [@steve.dower](#):
>
> I sure hope the SC is going to keep encouraging and factoring in these elements

I think that leads to a wider question of widening the scope of python-dev then. Since the SC looks after Python core and e.g. packaging is delegated to the PyPA group, one could argue it falls outside our purview. But if you’re suggesting/asking the SC to take a larger, holistic view of **everything** Python, then that feels like an expansion of responsibilities and one that the Python core team will have to agree to. Otherwise we are now starting to take away from the PyPA who don’t even get to vote for the SC.

---

<div class="post-metadata">

### Author: ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)
#### Post date: [November 15, 2022, 7:56pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/4 "2022-11-15T19:56:02Z")

</div>

You’re right. I did what most of us did and read into PEP 13 what I wanted to see, which was taking responsibility for the vision for Python in its entirety (and hence my strong desire to allow external candidates). That’s not in there, so it’s very much just covering python-dev. Too bad.

> [@brettcannon](#):
>
> Since the SC looks after Python core and e.g. packaging is delegated to the PyPA group, one could argue it falls outside our purview.

I would have argued that if the SC has the authority to delegate to PyPA, that by definition it _must_ fall within the purview.

Right now it’s more like a non-compete agreement 😉

---

<div class="post-metadata">

### Author: ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)
#### Post date: [November 15, 2022, 8:05pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/5 "2022-11-15T20:05:26Z")

</div>

> [@steve.dower](#):
>
> I would have argued that if the SC has the authority to delegate to PyPA, that by definition it _must_ fall within the purview.

Strictly speaking, we delegate the ability to accept packaging-related PEPs to the PyPA following their own practices outlined in [PEP 609 – Python Packaging Authority (PyPA) Governance | peps.python.org](https://peps.python.org/pep-0609/) . So if they choose to operate without our delegation by simply not using PEPs they could totally do that.

Otherwise the only other thing I can think of that python-dev controls package-wise, now that distutils is out the door, is `ensurepip`.

> [@steve.dower](#):
>
> Right now it’s more like a non-compete agreement 😉

Yep, or “please deal with this because we don’t want to” agreement depending your viewpoint of packaging. 😉

---

<div class="post-metadata">

### Author: ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)
#### Post date: [November 16, 2022, 8:01pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/6 "2022-11-16T20:01:57Z")

</div>

7 posts were split to a new topic: [Wanting a singular packaging tool/vision](https://discuss.python.org/t/wanting-a-singular-packaging-tool-vision/21141)

---

<div class="post-metadata">

### Author: ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)
#### Post date: [November 27, 2022, 3:30am UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/7 "2022-11-27T03:30:04Z")

</div>

> [@brettcannon](#):
>
> Strictly speaking, we delegate the ability to accept packaging-related PEPs to the PyPA following their own practices outlined in [PEP 609 – Python Packaging Authority (PyPA) Governance | peps.python.org](https://peps.python.org/pep-0609/) . So if they choose to operate without our delegation by simply not using PEPs they could totally do that.

Keeping such a community governance split from happening was one of _my_ key goals in volunteering for the inaugural SC - packaging and the interpreter’s import system and interface stability guarantees are too closely entwined for complete independence to be feasible, and securing Guido’s original standing BDFL delegation to specific PyPA contibutors/supporters genuinely helped resolve some of the political conflicts in the packaging community (as well as providing clarity for the wider Python community), so I wanted to see that continue into the SC era.

The enfranchisement side of the question has definitely been an ongoing concern though, mitigated by the fact that there _are_ several folks that are both PyPA developers and CPython core devs, as well as by the mechanics of the standing delegation process. SC interest in improving the management of that broader scope of responsibility would definitely be appreciated.

---

<div class="post-metadata">

### Author: ![EWDurbin](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ewdurbin/32/3103_2.png) [@EWDurbin](https://discuss.python.org/u/EWDurbin)
#### Post date: [December 15, 2022, 1:01pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/8 "2022-12-15T13:01:04Z")

</div>



---

<div class="post-metadata">

### Author: ![EWDurbin](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ewdurbin/32/3103_2.png) [@EWDurbin](https://discuss.python.org/u/EWDurbin)
#### Post date: [December 15, 2022, 1:01pm UTC](https://discuss.python.org/t/steering-council-nomination-brett-cannon-2023-term/21078/9 "2022-12-15T13:01:07Z")

</div>


