Hey all,
Since I've gotten a couple of requests now for MSDN renewals, I may as
well try to do them in a big batch. If you have an MSDN subscription
that is expired or soon expiring, I can get you a renewal if you send
me the email address you use to login and your Subscriber ID. This is
found at https://msdn.microsoft.com/subscriptions/manage/
If you don't have a subscription but would like one - it gives you
access to Windows ISOs, Visual Studio, and other Microsoft software -
please send me your preferred email address, mailing address, and
telephone number, and I'll get you setup.
Brian Curtin
Sending this to python-committers as well for anyone who doesn't keep up with
python-dev. If you've gotten this message twice now I'm sorry!
Just a heads up that people might see a "REMOTE HOST IDENTIFICATION HAS
CHANGED!" error when connecting to hg.python.org's SSH (or any other PSF
machine). The reason for this is that previously we allowed RSA, ECDSA, and
ED25519 host keys. However ECDSA relies on having an unbiased random number
generator on every connection and any bias in the random numbers can leak the
private key. Since these are running on VMs where we don't know for sure what
the quality is of the random numbers I've disabled the ECDSA host key.
The impact of this is if you had previously connected to a PSF machine, and
your client had the ECDSA key in your ~/.ssh/known_hosts file, that you'll
see an error like:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The remediation is to remove the ECDSA for the PSF servers from your known
hosts and connect again and accept either the RSA or the ED25519 key when it
presents it.
The fingerprints for hg.python.org for both of those keys are:
$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 a0:12:52:50:4a:4b:db:43:ac:65:26:b6:6f:0a:f7:b8 /etc/ssh/ssh_host_rsa_key.pub (RSA)
$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 1d:02:d1:d2:7b:a1:cb:e0:51:65:25:d7:19:dd:4e:74 /etc/ssh/ssh_host_ed25519_key.pub (ED25519)
Sorry for any inconvience this causes!
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
[Apologies for any duplicates you might have gotten - B]
Hello everyone - it's that time of year again where we plan the Pycon 2015
Language Summit.
Unfortunately, this year Michael will not be able to attend, so Larry Hastings
and I will be organizing the Summit. If you're on this email, consider
yourself invited!
*Please* let us know if you plan to attend so we can size the room and other
amenities accordingly.
The Summit will be held on Wednesday, April 8th, from approximately 10am to
4pm. Location within the convention center is TBD. The Summit is free,
although of course you are responsible for travel and hotel costs. If you are
planning on attending Pycon, you must still register and pay for that
separately, but Pycon attendance is *not* required if you're only interested
in the Language Summit.
The topics of conversation will be largely "floor led". Python 3.5 will be in
alpha release at the time, so I expect it to be a topic of conversation. I
have a few ideas for some other topics, and I hope to brainstorm with Larry on
how to make the Summit relevant for more people this year. Perhaps we have
some plenary sessions in the morning, with breakouts into smaller "working
groups" in the afternoon, with a final plenary catch up at the end of the day.
Your thoughts, suggestions, and interests are especially important, so please
do respond with your feedback.
There is a page on the Pycon 2015 site for the Summit, although it's currently
unresponsive for me:
https://us.pycon.org/2015/events/langsummit/
We'll post additional details, topics, schedules, etc. as they become
available.
I hope you can join us!
Cheers,
-Barry
Barry Warsaw wrote:
> *Please* let us know if you plan to attend so we can size the room and other amenities accordingly.
I'll be there. (Hopefully on time this year...)
Cheers,
Steve
Python 3.5.0a1 is currently scheduled to be released February 1. Since
I'll be on the road that day, the 3.5 team has agreed to push the
release back a week. 3.5.0a1 will be tagged Saturday February 7 and
released Sunday February 8. This doesn't change any of the other
release dates for 3.5..
Since it's about time for a 3.4.3 anyway, we're going to push that out
at the same time. 3.4.3rc1 will be tagged Saturday February 7 and
released Sunday February 8. 3.4.3 final will follow two weeks later,
tagged Saturday February 21 and released Sunday February 22.
Get your bug fixes (3.4) and crazy new functionality (3.5) in now!
//arry/
Hello all,
I would like to propose Davin Potts as core developer to take on the responsibility for maintaining the multiprocessing package.
I've been working with him on and off for over a year and found him to be highly skilled, thoughtful, and responsible. He is willing to devote time to a much neglected part of the standard library (186 open issues). He would be a valued member of the team.
I would be happy to serve as his mentor for his early contributions.
Raymond
> Begin forwarded message:
>
> Date: December 25, 2014 at 6:46:33 AM PST
> Subject: contributing to multiprocessing
> From: Davin Potts <davin(a)appliomics.com>
> To: Raymond Hettinger <raymond.hettinger(a)gmail.com>
>
> Hi Raymond --
>
> You asked if I'd be interested in becoming a maintainer for the multiprocessing package -- I've continued thinking about what I can do or trust myself to do and I think it'd be cool to make some serious ongoing contributions around multiprocessing.
>
> A rambling set of thoughts from my looking into multiprocessing....
>
>
> I've now read many (most?) of Jesse Noller's blog posts relating to multiprocessing, where it stands and where it should go, his calls for help. I've noted Richard Oudkerk's disappearance from the issue comments and mailing lists for a half year or so now -- people are still referencing him, asking for his take, in new issues from as recent as this past week. I'm still a bit unclear on how multiprocessing should ultimately relate to concurrent.futures though that discussion seems to be an ongoing one. Reading through those discussions makes me realize I must come from a different background (massive distributed computing, scientific computing, HPC) -- it's neat to read and try to understand what's going through other peoples' heads here.
>
>
> I've spent a decent chunk of time now going through the outstanding issues against multiprocessing. As best as I can tell, I'd break the current set of 186 issues mentioning multiprocessing down like this:
> * 50% are either junk or otherwise simply outdated-needing-proper-cleanup items,
> * 30% are advocating changes to docs to cover edge cases they've encountered,
> * 15% are Windows-specific problems needing investigation,
> * the remaining 5% are more interesting or nasty topics.
>
> Many of the edge cases people get surprised by in that 30% are complications related to Windows -- I think a goodly chunk of these problems could be prevented if the documentation were re-oriented a bit more (though documentation is not the answer to them all). The thought of documenting every little gotchya or niche these folks encounter is silly and won't help in practical terms. That said, there's enough of these problems to signal that something is definitely sub-optimal.
>
> The overall volume of Windows-related issues reminds me very much of Trent Nelson telling me at the one point that he figured the real reason he was invited to become a committer was because he didn't at all mind working on Windows issues. In a twisted way, I kind of like sorting out Windows issues too.
>
> I'd guess it'd take me 30-60 minutes to carefully go through each item in that big 50% chunk, bringing a healthy number to some closure in an iteration or two. That'll take a bit of time to chew through but seems important.
>
>
>
> If I'm up for helping work through the backlog of issues, including debugging Windows issues, how should I start?
>
>
>
> Davin
>
