This old draft PEP came up in an in-person conversation. It turns out to be almost vanished from the internet; the only source of it I could find is on Launchpad: https://code.launchpad.net/~jyasskin/python/memory-model-pep So, I'm assigning it a number, marking it Withdrawn, and checking it in so as not to lose a historical record.
Later on in the same file, it says that the .zip example can't possibly work: "[source distributions] will be gzipped tar archives, with the .tar.gz extension. Zip archives, or other compression formats for tarballs, are not allowed at present."
This, and other documentation issues not fixed here, was noted in a blog post I was reading: https://blog.schuetze.link/2018/07/21/a-dive-into-packaging-native-python-extensions.html -- full credit to @konstin.
* PEP 8016: more tweaks based on discussion
* Removed the requirement that council members have to be core team
members; added the requirement that non-core-team council candidates
need to be nominated by a core team member. Rationale: Steve Dower
is worried that we may have a shortage of core team members who are
willing to serve on the council. I'm not worried myself, but I like
Steve and don't want him to worry; this is an easy way to help with
that. Requiring a core team member nomination should be harmless,
since any candidate that can't get a nomination is certainly not
going to win a vote, and it lets us filter out random jokers early.
* Added some language to emphasize that emeritus core team members
will still be listed on the website and their past contributions
will continue to be recorded.
* Changed the vote tie-breaker from "seniority as a core team member"
to "mutual agreement or random chance". Victor pointed out that
seniority is not always known or unique, and anyway this doesn't
make much sense if we're allowing non-core-team member candidates.
The goal was always just to have some unambiguous resolution that
doesn't require voting again, and this seems like a simpler and more
reliable option.
* Clarified that in the never-going-to-happen edge case where a core
team member misbehaves so badly that the project has to kick them
out AND that core team member is on the council, then they're also
removed from the council.
* Added link to the second discussion thread.
* Made a few small wording tweaks and fixed some ReST formatting.
* PEP 8016: fix the definition of "Python committer" to match reality
* Rephrase the emeritus text again, to hopefully be even more clear
* One more wording tweak
* s/emeritus/inactive/, and remove the [TBD]
* PEP 8015: Committee has 5 members
* The Steering Committee is now made of 5 people instead of 3.
* There are no term limits (instead of a limit of 2 mandates:
6 years in total).
* When a Steering Committee member moves to the same company than
other members, they don't have to resign anymore.
* A committee member can now be a PEP delegate.
* keep constraint on employer
* Remove outdated sentence
* Steering Committee: move Roles before Election
* Use Schulze viriant of the Condorcet method
* Suggest CIVS service for online voting
* Change required majority
* Add also a "Annex: Summary on votes" section.
* Company acquisition
Previously, the PEP contained roughly the following three rules, in sequence:
1. Never use spaces around `=` when used to indicate a parameter default
2. Something unrelated
3. DO use spaces around `=` when used to indicate a parameter default if there is also a parameter annotation present
This commit attempts to clarify this part of the PEP by:
* Combining the first and third rules listed above into a single rule that addresses both annotated and unannotated parameters
* Rephrasing the first rule to indicate that it applies only to unannotated parameters, to eliminate the logical contradiction