> I'd love to have an easy way to keep them in the loop.
I'm one of the maintainers on https://github.com/docker-library/python
(which is what results in https://hub.docker.com/_/python), and I'd
love to have an easy way to keep myself in the loop too! O:)
Is there a lower-frequency mailing list where things like this are
normally posted that I could follow?
(I don't want to be a burden, although we'd certainly really love to
have more upstream collaboration on that repo -- we do our best to
represent upstream as correctly/accurately as possible, but we're not
experts!)
> would it make sense to add a packaging section to our documentation or
> to write an informational PEP?
FWIW, I love the idea of an explicit "packaging" section in the docs
(or a PEP), but I've maintained that for other projects before and
know it's not always easy or obvious. :)
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
PS. thanks doko for giving me a link to this thread! :D
Python 3.9.1rc1 is the release candidate of the first maintenance release of Python 3.9. Go get it here:
https://www.python.org/downloads/release/python-391rc1/ <https://www.python.org/downloads/release/python-391rc1/>
Assuming no critical problems are found prior to 2020-12-11, the currently scheduled release date for 3.9.1, 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.9.1 and as such its main purpose is testing.
Maintenance releases for the 3.9 series will continue at regular bi-monthly intervals, with 3.9.2 planned for end of January 2021.
Installer news
3.9.1rc1 is the first version of Python to support macOS 11 Big Sur. With Xcode 11 and later it is now possible to build “Universal 2” binaries which work on Apple Silicon. We are providing such an installer as the macosx11.0 variant. This installer can be deployed back to older versions, tested down to OS X 10.9. As we are waiting for an updated version of pip, please consider the macosx11.0 installer experimental.
This work would not have been possible without the effort of Ronald Oussoren, Ned Deily, and Lawrence D’Anna from Apple. Thank you!
In other news, this is the first version of Python to default to the 64-bit installer on Windows. The installer now also actively disallows installation on Windows 7. Python 3.9 is incompatible with this unsupported version of Windows.
What’s new in Python 3.9.1rc1?
We’ve made 240 changes since v3.9.0 which is a significant amount. To compare, 3.8.1rc1 only saw 168 commits since 3.8.0. See the full change log at
https://docs.python.org/release/3.9.1rc1/whatsnew/changelog.html <https://docs.python.org/release/3.9.1rc1/whatsnew/changelog.html>.
For more information about features included in the 3.9 series, see the “What’s New in Python 3.9 <https://docs.python.org/release/3.9.0/whatsnew/3.9.html>” document.
What about Python 3.8.7rc1?
There’s additional work needed to make this release support macOS 11 Big Sur. This should be ready next week, stay tuned.
We hope you enjoy the new releases!
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/ <https://www.python.org/psf/>
More resources
Online Documentation <https://docs.python.org/3.9/>
PEP 596 <https://www.python.org/dev/peps/pep-0596/>, 3.9 Release Schedule
PEP 619 <https://www.python.org/dev/peps/pep-0619/>, 3.10 Release Schedule
Report bugs at https://bugs.python.org <https://bugs.python.org/>.
Help fund Python and its community <https://www.python.org/psf/donations/>.
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>
Hi everyone,
I just wanted to express some appreciation for the excellent Dev Guide.
I don't use git or github much, but the dev guide got me from not knowing
where to start, to having a PR out for review in a couple hours. It walked
me through...pretty much perfectly.
Getting a CLA signed was also simple and nice. When the bot brought that
up, I thought it'd be a headache big enough to keep the PR from
ever getting back to the top of my todo list. But the help text and links
from the bot, the integration of BPO with Google sign in, linking BPO to a
github name, digitally signing the CLA, the little heroku thing -- all just
self serve, and easy, and obvious, and really just didn't get in the way.
I don't know which person(s) are the best to thank for all that, but thanks
for making it easy for a newbie to get started and contribute.
Hi Tobias,
A couple of questions about the DLS 2020 paper.
1. Why do you use the term "validate" rather than "test" for the process
of selecting a match?
It seems to me, that this is a test, not a validation, as no exception
is raised if a case doesn't match.
2. Is the error in the ast matching example, an intentional
"simplification" or just an oversight?
The example:
```
def simplify(node):
match node:
case BinOp(Num(left), '+', Num(right)):
return Num(left + right)
case BinOp(left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', item)):
return simplify(item)
case _:
return node
```
is wrong.
The correct version is
```
def simplify(node):
match node:
case BinOp(Num(left), Add(), Num(right)):
return Num(left + right)
case BinOp(left, Add() | Sub(), Num(0)):
return simplify(left)
case UnaryOp(USub(), UnaryOp(USub(), item)):
return simplify(item)
case _:
return node
```
Cheers,
Mark.
Hello,
We are using doctest to give our developers easy access to write very
fast unit tests and encourage "tests as documentation".
Recently we hit an issue where doctest crashes on certain objects that
fail to "unwrap".
Looking at the code and reasoning behind the crash it seems like we can
simply ignore a failed call to unwraps.
There is now a PR open against against trunk and 3.8 branch (happy to
make a 3.9 branch PR as well) here:
trunk: https://github.com/python/cpython/pull/22981
3.8: https://github.com/python/cpython/pull/22834
Does anyone have time to review and/or comment on this?
Thank you,
-Alfred
Excuse me, I have a question about pattern matching: is it used often
in math language as Mathematica? May it help to translate code from
such languages to Python?
A few days ago, Terry J. Reedy created the issue about the formatter module.
(https://bugs.python.org/issue42299)
The issue is mainly about testing code but also discussing the removal of
the module.
I noticed that the formatter module was deprecated in 3.4 and it was
originally scheduled to be removed in 3.6. But the removal was delayed
until 2.7 EOL.
Now 2.7 is EOL and there is no usage in stdlib.
So IMHO, it is good to remove the formatter module in 3.10
So before removing it, I would like to hear the concern.
Regards,
Dong-hee
I have read a great deal of discussion on the pattern matching PEPs and
less formal discussions. It is possible I have overlooked some post in all
of that, of course.
... OK, just saw Guido's "wait for new SC" comment, which I suppose applies
to this too :-).
One idea that I cannot recall seeing, but that seems to make sense to me
and fit with Python's feel is using a WORD to distinguish between a
variable value and a binding target. That is, instead of a special symbol
prefixing or suffixing a name, either to indicate it is or is not a binding
target. Of course, whether the extra word would be used for binding or for
NOT binding is a question still.
NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case value NOT_FOUND: # use the variable value
print("Document not found")
case OTHER_CODE: # bind this name
print("Other HTTP code", OTHER_CODE)
Of course, this would require a soft keyword, which is a disadvantage.
Going the other direction:
NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case NOT_FOUND: # use the variable value
print("Document not found")
case bind OTHER_CODE: # bind this name
print("Other HTTP code")
To me these read better than the punctuation characters. But I guess some
folks have suggested enlisting 'as', which is a word, of course.
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
Hi everyone,
There has been much discussion on the syntax of pattern matching for
Python (in case you hadn't noticed ;)
Unfortunately the semantics seem to have been somewhat overlooked.
What pattern matching actually does seems at least as important as the
syntax.
I believe that a pattern matching implementation must have the following
properties:
* The semantics must be precisely defined.
* It must be implemented efficiently.
* Failed matches must not pollute the enclosing namespace.
* Objects should be able determine which patterns they match.
* It should be able to handle erroneous patterns, beyond just syntax errors.
PEP 634 and PEP 642 don't have *any* of these properties.
I've written up a document to specify a possible semantics of pattern
matching for Python that has the above properties, and includes reasons
why they are necessary.
https://github.com/markshannon/pattern-matching/blob/master/precise_semanti…
It's in the format of a PEP, but it isn't a complete PEP as it lacks
surface syntax.
Please, let me know what you think.
Cheers,
Mark.
