Hi folks,
My available time for the fundamentals of stdlib module maintenance is
unfortunately pretty limited these days, which means even reviewed
patches for modules where I'm the sole maintainer aren't necessarily
getting applied in a timely fashion (Serhiy quite rightly nudged me
about this recently in relation to a languishing contextlib patch).
Would anyone be interesting in taking up co-maintainership of one or
more of the affected modules? Timely reviews I can generally manage
(especially for other core developers), it's timely patch application
and new module level development work that I struggle to find the time
for :(
The affected modules:
* contextlib
* dis
* runpy
Regards,
Nick.
P.S. In the specific case of contextlib, I'm also interested in
finding someone willing to take up maintenance of the contextlib2
backport: https://pypi.python.org/pypi/contextlib2
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Someone ran an experiment looking at the SSH keys used on GitHub
(public keys are accessible through the API):
https://blog.benjojo.co.uk/post/auditing-github-users-keys
Excerpt:
I remembered back to the May 2008 Debian OpenSSH bug, where
the randomness source was compromised to the point where the
system could only generate one of 32k keys in a set.
I used g0tmi1k’s set of keys to compare against what I had in
my database, and found a very large amount of users who are
still using vulnerable keys, and even worse, have commit
access to some really large and wide projects including:
...
Crypto libraries to Python
Django
Python’s core
...
CPython is not officially on github, so committing evil stuff to the
github mirror may not matter very much, but these users may have the
same key configured for hg.python.org. Should we check everyone's SSH
keys?
--amk
On behalf of the Python development community and the Python 3.5 release
team, I'm relieved to announce the availability of Python 3.5.0b2.
Python 3.5.0b1 had a major regression (see
http://bugs.python.org/issue24285 for more information) and as such was
not suitable for testing Python 3.5. Therefore we've made this extra
beta release, only a week later. Anyone trying Python 3.5.0b1 should
switch immediately to testing with Python 3.5.0b2.
Python 3.5 has now entered "feature freeze". By default new features
may no longer be added to Python 3.5. (However, there are a handful of
features that weren't quite ready for Python 3.5.0 beta 2; these were
granted exceptions to the freeze, and are scheduled to be added before
beta 3.)
This is a preview release, and its use is not recommended for production
settings.
Three important notes for Windows users about Python 3.5.0b2:
* If installing Python 3.5.0b2 as a non-privileged user, you may need
to escalate to administrator privileges to install an update to your
C runtime libraries.
* There is now a third type of Windows build for Python 3.5. In
addition to the conventional installer and the web-based installer,
Python 3.5 now has an embeddable release designed to be deployed as
part of a larger application's installer for apps using or extending
Python. During the 3.5 alpha releases, this was an executable
installer; as of 3.5.0 beta 1 the embeddable build of Python is now
shipped in a zip file.
You can find Python 3.5.0b2 here:
https://www.python.org/downloads/release/python-350b2/
Happy hacking,
//arry/
