Python 3.9.7
Get it here: https://www.python.org/downloads/release/python-397/ <https://www.python.org/downloads/release/python-397/>
Python 3.9.7 is the newest major stable release of the Python programming language, and it contains many new features and optimizations. There’s been 187 commits since 3.9.6 which is a similar amount compared to 3.8 at the same stage of the release cycle. See the change log <https://docs.python.org/release/3.9.7/whatsnew/changelog.html> for details.
On macOS, we encourage you to use the universal2 binary installer variant whenever possible. The legacy 10.9+ Intel-only variant will not be provided for Python 3.10 and the universal2 variant will become the default download for 3.9.8. You may need to upgrade third-party components, like pip, to later versions. You may experience differences in behavior in IDLE and other Tk-based applications due to using the newer version of Tk. As always, if you encounter problems when using this installer variant, please check https://bugs.python.org <https://bugs.python.org/> for existing reports and for opening new issues.
The next Python 3.9 maintenance release will be 3.9.8, currently scheduled for 2021-11-01.
<https://discuss.python.org/t/python-3-9-7-and-3-8-12-now-available/10401#th…>The Second Security-Only Release of Python 3.8
Get it here: https://www.python.org/downloads/release/python-3812/ <https://www.python.org/downloads/release/python-3812/>
Security content in this release contains four fixes. There are also four additional fixes for bugs that might have lead to denial-of-service attacks. Finally, while we’re not providing binary installers anymore, for those users who produce installers, we upgraded the OpenSSL version used to 1.1.1l. Take a look at the change log <https://docs.python.org/release/3.8.12/whatsnew/changelog.html> for details.
According to the release calendar specified in PEP 569 <https://www.python.org/dev/peps/pep-0569/>, Python 3.8 is now in “security fixes only” stage of its life cycle: 3.8 branch only accepts security fixes and releases of those are made irregularly in source-only form until October 2024. Python 3.8 isn’t receiving regular bug fixes anymore, and binary installers are no longer provided for it. Python 3.8.10 was the last full bugfix release of Python 3.8 with binary installers.
<https://discuss.python.org/t/python-3-9-7-and-3-8-12-now-available/10401#se…>Security releases of 3.7.12 and 3.6.15
Those aren’t ready just yet but are soon to follow.
Similarly to 3.8, Python 3.7 and 3.6 are now in “security fixes only” stage of their life cycle. Python 3.7 will be providing source archives until June 2023 while Python 3.6 ends its life in December 2021.
<https://discuss.python.org/t/python-3-9-7-and-3-8-12-now-available/10401#we…>We hope you enjoy the new releases
Your friendly release team,
Ned Deily @nad <https://discuss.python.org/u/nad>
Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>
Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
pytest 6.2.5 has just been released to PyPI.
This is a bug-fix release, being a drop-in replacement. To upgrade::
pip install --upgrade pytest
The full changelog is available at
https://docs.pytest.org/en/stable/changelog.html.
Thanks to all of the contributors to this release:
* Anthony Sottile
* Bruno Oliveira
* Brylie Christopher Oxley
* Daniel Asztalos
* Florian Bruhin
* Jason Haugen
* MapleCCC
* Michał Górny
* Miro Hrončok
* Ran Benita
* Ronny Pfannschmidt
* Sylvain Bellemare
* Thomas Güttler
Happy testing,
The pytest Development Team
Hi everyone,
I’m happy to announce the release of argon2-cffi 21.1.0!
With more than 13 million downloads per month, argon2-cffi is the most popular package for using the competition-winning Argon2 password hash in Python.
If you want more details on Argon2 and why it matters, check out my blog post "Storing Passwords in a Highly Parallelized World" <https://hynek.me/articles/storing-passwords/>.
Heartfelt thanks go to my generous GitHub sponsors <https://github.com/sponsors/hynek>, companies subscribing on Tidelift <https://tidelift.com/subscription/pkg/pypi-argon2-cffi> (currently nobody :( – tell your boss!), and people who bought me a coffee on <https://ko-fi.com/the_hynek>!
Support like that makes me work on FOSS on a Sunday afternoon, so please consider supporting me <https://hynek.me/say-thanks/> too! <3
The highlights of this release are:
- abi3-wheels for all platforms. This means that argon2-cffi is ready for Python 3.10!
- Good bye Python 2.
---
All Changes:
============
Vendoring Argon2 @ 62358ba (20190702)
Backward-incompatible changes:
Microsoft stopped providing the necessary SDKs to ship Python 2.7 wheels and currenly the downloads amount to 0.09%. Therefore we have decided that Python 2.7 is not supported anymore.
Deprecations:
none
Changes:
There are indeed no changes whatsoever to the code of argon2-cffi. The Argon2 project also hasn't tagged a new release since July 2019. There also don't seem to be any important pending fixes.
This release is mainly about improving the way binary wheels are built (abi3 on all platforms).
PyCA cryptography 3.4.8 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.
Changelog (https://cryptography.io/en/latest/changelog.html#v3-4-8):
* Updated Windows, macOS, and manylinux wheels to be compiled with
OpenSSL 1.1.1l.
-Paul Kehrer (reaperhulk)
Dear colleagues,
We are very happy to announce the v4.3 release of the Astropy package,
a core Python package for Astronomy:
http://www.astropy.org
Astropy is a community-driven Python package intended to contain much
of the core functionality and common tools needed for astronomy and
astrophysics. It is part of the Astropy Project, which aims to foster
an ecosystem of interoperable astronomy packages for Python.
New and improved major functionality in this release includes:
* Transformations to AltAz are now much more precise (and faster)
* Improvements in making Astropy thread-safe
* Performance improvements to sigma clipping
* Changes in the Time and IERS leap second handling
* Support for multidimensional and object columns in ECSV
* Support for reading and writing tables to QDP format
* Append table to existing FITS file
* General masked class for Quantity and other ndarray subclasses
* Configuration file improvements
* Support for different solvers and bracket option in z_at_value
In addition, hundreds of smaller improvements and fixes have been
made. An overview of the changes is provided at:
http://docs.astropy.org/en/stable/whatsnew/4.3.html
Instructions for installing Astropy are provided on our website, and
extensive documentation can be found at:
http://docs.astropy.org
If you usually use pip/vanilla Python, you can do:
pip install astropy --upgrade
Note that this will yield astropy v4.3.1 instead of 4.3, which is
expected - a significant bug reported between the 4.3 release and this
announcement means that the correct version is indeed 4.3.1.
If you make use of the Anaconda Python Distribution, soon you will be
able update to Astropy v4.3.1 with:
conda update astropy
Or if you cannot wait for Anaconda to update their default version,
you can use the conda-forge channel:
conda update -c conda-forge astropy
Please report any issues, or request new features via our GitHub repository:
https://github.com/astropy/astropy/issues
Over 400 people have contributed code to Astropy so far, and you can
find out more about the team behind Astropy here:
https://www.astropy.org/team.html
The LTS (Long Term Support) version of Astropy at the time of v4.3's
release is v4.0 - this version will be maintained until the next LTS
release (v5.0, scheduled for Fall 2021). v4.0.6 is the latest version,
also just released.
Additionally, note that the Astropy 4.x series only supports Python 3.
Python 2 users can continue to use the 2.x series but it is no longer
supported (as Python 2 itself is no longer supported). For assistance
converting Python 2 code to Python 3, see the Python 3 for scientists
conversion guide.
If you use Astropy directly for your work, or as a dependency to
another package, please remember to acknowledge it by citing the
appropriate Astropy paper. For the most up-to-date suggestions, see
the acknowledgement page, but as of this release the recommendation
is:
This research made use of Astropy, a community-developed core Python
package for Astronomy (Astropy Collaboration, 2013, 2018).
We hope that you enjoy using Astropy as much as we enjoyed developing it!
Erik Tollerud
v4.3 Release Coordinator
on behalf of The Astropy Project
https://www.astropy.org/announcements/release-4.3.html
Announcing the release of Blue version 0.7.0!
2021-08-16 (0.7.0)
------------------
- Bump dependency on Black to 21.7b0
- Prefer double quotes for non-docstring triple quoted strings (GH#10)
- Add support for "py39" as target-version (GH#44)
- Docstrings now always use triple-double-quoted strings (GH#5)
====
Blue
====
Some folks like `black <https://black.readthedocs.io/en/stable/>`_ but I
prefer `blue <https://blue.readthedocs.io/en/latest/>`_.
What is blue?
=============
``blue`` is a somewhat less uncompromising code formatter than ``black``, the
OG of Python formatters. We love the idea of automatically formatting Python
code, for the same reasons that inspired ``black``, however we take issue with
some of the decisions ``black`` makes. Kudos to ``black`` for pioneering code
formatting for Python, and for its excellent implementation.
Where the ``blue`` maintainers disagree with the stylistic (and
unconfigurable) choices made by ``black``, we monkeypatch to change these
decisions to our own liking. We intend for these differences to be minimal;
even in cases where we'd prefer something different, there's a lot we can live
with for the sake of consistency.
We'd prefer not to fork or monkeypatch. Instead, our hope is that eventually
we'll be able to work with the ``black`` maintainers to add just a little bit
of configuration and merge back into the ``black`` project. We'd be ecstatic
if ``blue`` eventually were retired. Until then, we'll maintain our small set
of hacks on top of ``black`` and carefully consider what other deviations are
needed to assuage our sensitive, but experienced, eye.
How do I use blue?
==================
Exactly the same as you would use ``black``. Invoke and configure ``blue`` as
you would ``black`` -- just replace the ``black`` command with ``blue``, sit
back, and enjoy even betterly formatted Python code! You can refer to
`black's <https://black.readthedocs.io/en/stable/>`_ documentation for
anything not listed here.
So what's different?
====================
Here is a brief list of differences between ``blue`` and ``black``:
* ``blue`` defaults to single-quoted strings. This is probably the most
painful ``black`` choice to our eyes, and the thing that inspired ``blue``.
We strongly prefer using single quoted strings over double quoted strings for
everything *except* docstrings and triple quoted strings (TQS). Don't ask us
why we prefer double-quotes for TQS; it just looks better to us! For all
other strings, ``blue`` defaults to single quoted strings. In the case of
docstrings, those always use TQS with double-quotes.
* ``blue`` defaults to line lengths of 79 characters. Nearly every project
creates a pyproject.toml just to change this one setting so making it
consistent with PEP 8 seems relatively harmless.
* ``blue`` preserves the whitespace before the hash mark for right hanging
comments.
* ``blue`` supports multiple config files: ``pyproject.toml``, ``setup.cfg``,
``tox.ini``, and ``.blue``.
We are `accumulating <https://github.com/grantjenks/blue/issues/2>`_ a list of
other deviations we are considering. As we decide to implement any particular
suggestion, we'll turn those into individual issues and tackle them
one-by-one. If you have suggestions for other deviations from ``black``'s
choices, please open a separate ticket on our tracker, and we'll see how it
goes!
Why "blue"?
===========
Several reasons! If your formatter is going to beat up your code, it'll leave
it black and blue, or maybe in this case, black *or* blue. Blue is better!
We also thought about "tan" because, yum! But that project name was already
taken. Frankly, "blue" was also taken, but largely unused. Our thanks to
Nick Ficano for donating the project namespace to us!
Blue is also the color of `LinkedIn <https://www.linkedin.com/>`_, the
authors' gracious employer, and we intend to socialize its use within our
company code base.
Contributors
============
``blue`` thanks this list of contributors for all its wonderful goodness.
* The `wonderful folks <https://github.com/psf/black#authors>`_ from the
``black`` project.
* Grant Jenks
* Barry Warsaw
* Corey from FutureSpaceDesigns for the unofficial logo and `blue project
merchandise <https://www.teepublic.com/t-shirt/6556561-tobias-blue>`_.
``blue`` is licensed under the terms of the Apache License Version 2.0.
``black`` is `licensed <https://github.com/psf/black#license>`_ under the
terms of the MIT license.
Project details
===============
.. image:: https://img.shields.io/badge/code%20style-blue-blue.svg
:target: https://blue.readthedocs.io/
.. image:: https://github.com/grantjenks/blue/workflows/integration/badge.svg
:target: https://github.com/grantjenks/blue/actions?query=workflow%3Aintegration
.. image:: https://github.com/grantjenks/blue/workflows/release/badge.svg
:target: https://github.com/grantjenks/blue/actions?query=workflow%3Arelease
* Project home: https://github.com/grantjenks/blue
* Report bugs and suggestions at: https://github.com/grantjenks/blue/issues
* Code hosting: https://github.com/grantjenks/blue.git
* Documentation: https://blue.readthedocs.io/en/latest
