[python-committers] Re: Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")

[Jason R. Coombs]

Sgtm

Sent from my comm

On Mar 22, 2022, at 21:31, Gregory P. Smith  wrote:



On Tue, Mar 22, 2022 at 4:36 PM Barry Warsaw 
mailto:ba...@python.org>> wrote:
PEP 2 will have to be “un-superseded”, and presumably the devguide (which PEP 2 
points to) will also need to be updated.

we discussed that a bit.  the dev guide makes sense as a "how to do it" purpose 
document, useful for constructing PRs.  The PEP makes sense as a "here's the 
policy before merging or spending too much time on it". they'd link to each 
other, but they have distinct roles.


I think it’s probably fine to drop the idea of provisional APIs.  Aside from 
the limit benefit of evolution within the stdlib, code still gets written 
against provisional APIs and people still complain when they break in 
non-backward compatible ways, so we might as well avoid the whole thing.

-Barry

> On Mar 22, 2022, at 16:26, Brett Cannon 
> mailto:br...@python.org>> wrote:
>
> I had kicked off a discussion a while back at 
> https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681
>  about how to manage the stdlib (this has nothing to with what the stdlib is 
> and thus what belongs in it). It finally bubbled up in the SC agenda and 
> after discussing things we have three proposals:
>   • Update PEP 2 to say a PEP is necessary to add a module to the stdlib
>   • Update PEP 4 to say that a PEP is necessary to deprecate/remove a 
> module
>   • Mark PEP 411 as obsolete and thus dropping the idea of provisional 
> modules
> The PEP requirements are because the stdlib is important to manage 
> appropriately and since it's a shared resource it should be something we all 
> discuss. The PEP process seems like a good mechanism for both keeping what we 
> bring in under control while also making sure people don't break people's 
> code needlessly with removals.
>
> The dropping of the concept of provisional modules is from simply having not 
> seen any true benefit that could have been had in other ways (e.g. typing, 
> asyncio, importlib.metadata). In pretty much all cases the APIs could have 
> evolved publicly first and then been brought into the stdlib once stable (if 
> at all), so the concept of "provisional" just doesn't seem worth keeping 
> around.
>
> We wanted to see if there was consensus around any of these ideas, hence this 
> email. 
> ___
> python-committers mailing list -- 
> python-committers@python.org
> To unsubscribe send an email to 
> python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list -- 
python-committers@python.org
To unsubscribe send an email to 
python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SKD3XJQF44F2BB6BCCACCPDZDRWTCSWC/
Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/GQKYSLUAZRS2H2DPU7ONFUOPJNO5BARO/
Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UA3LI6KLQC3ECKFHYRXLSV3VG7XOMUAV/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please make sure you're following good security practices with your GitHub account

[Jason R. Coombs]

I use a mobile device to store TOTP tokens (one time use passcodes), but as I 
also wish to use my workstation device to generate these tokens, I’ve 
historically used a tool called oathtool 
to generate these one time tokens (from a stored secret), but due to 
portability issues with the tool, I ended up porting it to Python. Now with 
keyring and 
oathtool and 
jaraco.clipboard, I’m able to (a) 
store the Github-generated key in a secure location, (b) generate tokens from 
the command line, and (c) copy them to the clipboard for easy pasting into a 
form (independent of platform). Since I use xonsh for my shell, I’m able to 
readily create aliases for each of the sites I use thus:

```xonsh
def get_oath(system, user):
code = keyring.get_password(system, user).replace(' ', '')
otp = $(oathtool @(code)).rstrip()
jaraco.clipboard.copy(otp)


def add_mfa(alias, system, user):
aliases[alias] = functools.partial(get_oath, system, user)

add_mfa('github-mfa', 'GitHub MFA', 'jaraco')
```

Now, when I type `github-mfa` in my shell, keyring retrieves the key from a 
secure storage, oathtool converts that to a valid one time passcode, and then 
jaraco.clipboard puts that on the clipboard, all using nothing but Python and a 
few libs.

The workflow may not be the best for you, and is probably not quite as secure 
as a hardware token like Yubikey, but as long as the password store is kept as 
secure as the hardware token, it’s comparable, and a fair deal more secure than 
with a password and does supply a second factor. I welcome others to copy all 
or part of the approach.


On 14 Jun, 2021, at 18:29, Terry Reedy 
mailto:tjre...@udel.edu>> wrote:

On 6/14/2021 3:38 PM, Brett Cannon wrote:
I have discovered someone tried to break into my GitHub account (you can check 
yourself by going to https://github.com/settings/security-log 
 and looking for "failed to login" 
attempts for potentially odd geographical locations for yourself).

I checked and the only logins are me, at home, with the same IP address. (I 
realize that this could change.) My only development system is on my desktop, 
so github *could* let me check a box to use the location as a quasi 2nd factor. 
 If the IP address changes, they *could* immediately email (if requested).

TJR

___
python-committers mailing list -- 
python-committers@python.org
To unsubscribe send an email to 
python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/IZPTKBBDWK3FA2GVJRZ4HBL2CJRUA76Q/
Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/7QQYG7NST66LQMXF5RB4GCAQ6B3RANGF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: core-dev chat

[Jason R. Coombs]

For CPython, I’ve been present on IRC and Zulip and Slack and Discord (and 
would prefer them in the reverse of that order).

I’ve used Gitter for CherryPy and Setuptools and Xonsh, but found the interface 
kinda meh compared to Slack and Discord.

Would be delighted if there was a preferred platform for chat and that platform 
be documented (and allowed to change as solutions and the community evolves).

On 14 May, 2021, at 14:07, Brett Cannon 
mailto:br...@python.org>> wrote:



On Fri, May 14, 2021 at 6:48 AM Senthil Kumaran 
mailto:sent...@python.org>> wrote:
On Fri, May 14, 2021 at 09:36:52AM +0200, Antoine Pitrou wrote:
> #python-dev on IRC has been wildly successful until perhaps 2015.
> Personally, I would have no problem using IRC if wanted to connect to a chat
> for CPython at all.

I know, it was useful, and #python is still. The bot, github, buildbot
made it more alerts only. Looks like Victor and few others still use it.


> Similarly, I would have no problem using Zulip.  I would even say that Zulip
> is by far the best chat system I've ever used, and the alternatives don't
> come near.  Its threading system is really superior to everything else.

With Zulip, I find it hard to understand, why I need two namespaces (for
lack of better term) before I start writing my text in Zulip chat.

#topic->subtopic [content]

I have not been a part of the community that uses Zulip effectively, so
I haven't learnt it well.

> The idea that if people don't use IRC and Zulip, then we should try another
> chat system, sounds like magical thought. What kind of properties do Slack,
> Gitter or Discord have that Zulip doesn't? They are actually quite annoying
> in my experience.

Some have community advantage. K8s, Golang people are on Slack. Multiple
Companies are on Slack, technical barrier is very low. Similar is the
case with Discord.

Yeah, I don't know if the Python community as a whole has totally settled on a 
platform.


Community usage, and usability _perhaps_ go hand in hand. General numbers
could support for this.

That said. If we (a quorum) feel comfortable using anything like IRC,
Zulip, I agree, we don't need another one.

You could launch a poll on discuss.python.org and 
see if there's a clear winner.

-Brett


--
Senthil
___
python-committers mailing list -- 
python-committers@python.org
To unsubscribe send an email to 
python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/LYK567UL32MQS7IBRFADWM5WIN3AY57Q/
Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list -- 
python-committers@python.org
To unsubscribe send an email to 
python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CG4MJEDHXTKT76DY5UARV4SSFZYX7VQ7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/BXKZI5Y2DJ3SHX2JZYLUCJHNERTNDTYK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: CI tests are broken

[Jason R. Coombs]

One of the reasons I might be tempted to merge a pull request before the tests 
is completed is because there’s no mechanism to merge a pull request after the 
tests have completed (when there’s no reviewer).

I imagine it’s allowed because there still is the case where tests can fail for 
some reason unrelated to the pull request at hand.

In short, the system isn’t reliable or fast or flexible enough to depend solely 
on automated systems, so it still relies on human judgment.

At least, that’s my suspicion.

> On 31 Mar, 2021, at 06:52, Mark Shannon  wrote:
> 
> Hi,
> 
> My PR tests are failing seemingly due to some bug in enum.rst
> Which might be caused by https://github.com/python/cpython/pull/22392
> (that's the superficial cause, it might not be the root cause).
> 
> Example failure:
> https://github.com/python/cpython/pull/25069
> https://github.com/python/cpython/pull/25069/checks?check_run_id=2235991560
> 
> Why are we merging PRs that fail the CI tests?
> Why is that even allowed?
> 
> Cheers,
> Mark.
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/322BYODJ5ETK557Q62NW6GP64V2F4TQD/
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/LQHG2M6N4HRRXVHZYPXSKSEZEQ76HCNQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Cannot release 3.9.0a4

[Jason R. Coombs]

The Fedora failures in shutil and zipfile are "no space left on device". Seems 
like an environment/infrastructure issue.

The failures in the Windows build also seem to implicate importlib (though with 
an obscure error). I looked into those and they don't appear to relate to 
anything I've worked on, but someone please let me know if find otherwise.

From: Łukasz Langa 
Sent: Monday, February 17, 2020 19:13
To: python-committers 
Subject: [python-committers] Cannot release 3.9.0a4

Currently Buildbots are reporting that master is not in a releasable state:
https://buildbot.python.org/all/#/release_status

Namely, it does not build on Windows 7:
- https://buildbot.python.org/all/#/builders/150/builds/338
- https://buildbot.python.org/all/#/builders/81/builds/390

and suffers from test failures on:
- macOS (importlib) - https://buildbot.python.org/all/#/builders/275/builds/249
- Fedora (shutil and zipfile) - 
https://buildbot.python.org/all/#/builders/449/builds/31


Please look at this, especially the Windows compile failure. I will be 
attempting 3.9.0a4 next week with 3.8.2 final.

- Ł
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/BPDDW63JA26QU3IMSWCY7W3ULO3ZAMVY/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [RELEASE] Python 3.8.1rc1 is now available for testing

[Jason R. Coombs]

I think I missed the announcement of the cutoff date for 3.8.1; I was hoping to 
get some bug fixes in for 
importlib.metadata.

These aren’t crucial bugfixes, but it would be nice not to have them linger for 
months. Would you consider including these, especially as the code changes are 
pre-vetted in the backport (released 12-01)? Or maybe only if there’s another 
RC for another reason?

If it’s too disruptive, that’s no big deal. Your call.

Thanks for the release work.

On 10 Dec, 2019, at 04:22, Łukasz Langa 
mailto:luk...@langa.pl>> wrote:


Python 3.8.1rc1 is the release candidate of the first maintenance release of 
Python 3.8.

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.1rc1 
here:

https://www.python.org/downloads/release/python-381rc1/

Assuming no critical problems are found prior to 2019-12-16, the scheduled 
release date for 3.8.1 as well as Ned Deily's birthday, no code changes are 
planned between this release candidate and the final release.

That being said, please keep in mind that this is a pre-release of 3.8.1 and as 
such its main purpose is testing.

See the “What’s New in Python 
3.8” document for more 
information about features included in the 3.8 series. Detailed information 
about all changes made in 3.8.0 can be found in its change log.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.2 planned for February 2020.

We hope you enjoy Python 3.8!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

https://www.python.org/psf/

___
python-committers mailing list -- 
python-committers@python.org
To unsubscribe send an email to 
python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/IGJ6ZOAOT2WFY5ZIPRQNTHOSUMPUAO2H/
Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YX4DTT26DNYQFUBW5EHPODYMRGT4ZOQX/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

[Jason R. Coombs]

+1

On 2 May, 2018, at 10:49, Victor Stinner 
> wrote:

* +1: you like the PEP
* -1: you dislike the PEP
* 0: you are not sure if you like it or not, or you have no opinon
* don't reply to this poll :-)

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] IPv6 issues on *.python.org

[Jason R. Coombs]

It’s working for me. https://gist.github.com/51689c789a21edc1f9f9cf32fa17431f


On 16 Nov, 2017, at 09:07, Antoine Pitrou 
> wrote:


Hello,

I'm having IPv6 issues on *.python.org.  Is anyone having 
the same
issues or is it just me?  Who should I report this to?

$ curl -6 -v -I https://www.python.org/
*   Trying 2a04:4e42:9::223...
* Connected to www.python.org (2a04:4e42:9::223) port 
443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: Error in the pull function.
* Closing connection 0
curl: (35) gnutls_handshake() failed: Error in the pull function.


Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] MSDN Subscriptions — First timers, renewals

[Jason R. Coombs]

Brian,

Jason R. Coombs
jar...@jaraco.com
2301 Champlain St NW
Apt 305
Washington, DC 20009-8703

It seems my subscription did lapse in August.

Thanks for the help on this.

> On 27 Sep, 2017, at 14:52, Brian Curtin <br...@python.org> wrote:
> 
> Hey everyone,
> 
> If you've been waiting on a recent subscription renewal, my apologies—I 
> dropped the ball on following up on some of them, but I'm getting things back 
> in order with another request for renewals now that a few more are flowing in.
> 
> If you are currently expired or within a month or so of a renewal, please 
> send me the email address you use, your full name, and your mailing address. 
> We haven't always needed mailing address for renewals, but they have been 
> asking for it lately. If your expiration is a few months away, they seem to 
> prefer we don't get too far ahead so email me directly when that time comes, 
> or perhaps another one of these batches will match up.
> 
> If you've never had a subscription but would like one, please send me the 
> email address you use, your full name, and your mailing address. This will 
> give you access to Microsoft's Developer Network, which includes access to 
> things like Visual Studio and Windows licenses that we can use for working on 
> Python.
> 
> Thanks for everyone's work on Python!
> 
> Brian
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Carol Willing to become a core developer

[Jason R. Coombs]

I was impressed with Carol’s leadership at HackIllinois

+1


> On 23 May, 2017, at 14:15, Brett Cannon  wrote:
> 
> As usual, if you support/object to this idea, please say so. :)
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we delete https://hg.python.org/coding/cpython/?

[Jason R. Coombs]

Seems that way. It doesn’t have any change sets not in the canonical repo.

$ hg incoming https://hg.python.org/coding/cpython
comparing with https://hg.python.org/coding/cpython
searching for changes
no changes found

> On 19 Dec, 2016, at 17:23, Brett Cannon  wrote:
> 
> It's erroneously labeled as the "official python repo" and created by some 
> stranger.
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Gratuitous? incompatibilities in the fix only releases

[Jason R. Coombs]

For reference, a similar bug fix also introduced incompatibilities with the 
Chishop service: http://bugs.python.org/issue23899


On Jul 29, 2015, at 12:06, Jesus Cea j...@jcea.esmailto:j...@jcea.es wrote:

Yesterday I upgraded one of my computer to 2.7.10 and a program working
for years failed.

The problem is this:


http=httplib.HTTPConnection(127.0.0.1,8081)
http.request(GET,/X/%f %last_t, , \
 {Authorization:Basic %s %base64.encodestring(%s:%s %(a,b))})


base64.encodestring() creates base64 encoding with a final '\n'. This
used to work until 2.7.9 but 2.7.10 if failing now with an exception
about an illegal character in a header.

I know that that code is faulty and I should drop the final '\n' or just
use base64.b64encode() (my current fix). The point, thought, it that
this code used to work in previous 2.7 releases but it is failing under
2.7.10.

This incompatible change will be released in 3.4.4 too.

I agree that new code is better, no argument here. My program was
incorrect, sure. But I was under the impression that backwards
incompatible code was forbidden in minor releases, except for very
critical reasons (like the HTTPS security default backported to 2.7). I
think that breaking working code during minor updates is risky and
breaks user/programmer expectations.

The change was done in https://bugs.python.org/issue22928.

I think the change is the way to go, I don't ask for a revert (since
2.7.10 is already in the wild I want to keep it too in future 3.4.4) but
I am interested in knowing the official statement of committers about
backwards incompatible changes in minor releases for my own future
reference.

Sorry if this email seems confrontational. Not my intention, but my
English is getting worse by the day :-). This is an inquiry about
policy, not an attack.

Thanks!

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.esmailto:j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/  
  _/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz

___
python-committers mailing list
python-committers@python.orgmailto:python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Do people prefer pushing feature repos or one massive patch?

[Jason R. Coombs]

I'm in the other camp.

The way I see it, a squash of history or massive patch file loses history. It 
loses details about the thought process of the implementer. It masks mistakes 
and obscures motivations. It also masks decisions made in the merge operation, 
further hiding potential problems.

On the other hand, a feature repo (or any separate series of commits), while 
retaining the history as it happened and thus the fidelity of the development, 
can always be mechanically reduced to a squashed patch (for review or other 
considerations, and in fact, the Python bug tracker will produce these squashed 
patches from feature repos automatically even if they're hosted in another 
system). Rollback is trivially easy; reverting a merge is as easy as reverting 
a squashed commit. It has the added benefit that any individual commit can be 
backed out automatically (in a squashed patch, that's not possible).

In other words, it's straightforward and easy to go from the latter model to 
the former, and generally impossible to reverse the operation.

In my opinion, it boils down to whether the group wants to restrict the options 
available for review. I would recommend that a contributor provide (or 
maintain) a feature repo if convenient.

-Original Message-
From: python-committers 
[mailto:python-committers-bounces+jaraco=jaraco@python.org] On Behalf Of 
Nick Coghlan
Sent: Thursday, 02 April, 2015 01:35
To: python-committers
Subject: Re: [python-committers] Do people prefer pushing feature repos or one 
massive patch?

On 2 April 2015 at 04:09, Ethan Furman et...@stoneleaf.us wrote:
 I like one massive patch, myself.  :)

Aye, I'm also in the squash for the clean history approach. 
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposing Paul Moore for commit privileges

[Jason R. Coombs]

+1
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers