Hi,
I'm generally in favour of PEP 554, but I don't think it is ready to be
accepted in its current form.
My main objection is that without per-subinterpeter GILs (SILs?) PEP 554
provides no value over threading or multi-processing.
Multi-processing provides true parallelism and threads provide shared
memory concurrency.
If per-subinterpeter GILs are possible then, and only then,
sub-interpreters will provide true parallelism and (limited) shared
memory concurrency.
The problem is that we don't know whether we can implement
per-subinterpeter GILs without too large a negative performance impact.
I think we can, but we can't say so for certain.
So, IMO, we should not accept PEP 554 until we know for sure that
per-subinterpeter GILs can be implemented efficiently.
Detailed critique
-----------------
I don't see how `list_all()` can be both safe and accurate. The Java
equivalent makes no guarantees of accuracy.
Attempting to lock the list is likely to lead to deadlock and not
locking it will lead to races; potentially dangerous ones.
I think it would be best to drop this.
`list_all_channels()`. See `list_all()` above.
`.destroy()` is either misleading or unsafe.
What does this do?
>>> is.destroy()
>>> is.run()
If `run()` raises an exception then the interpreter must exist. Rename
to `close()` perhaps?
`Channel.interpreters` see `list_all()` and `list_all_channels()` above.
How does `is_shareable()` work? Are you proposing some mechanism to
transfer an object from one sub-interpreter to another? How would that
work? If objects are not shared but serialized, why not use marshal or
pickle instead of inventing a third serialization protocol?
It would be clearer if channels only dealt with simple, contiguous
binary data. As it stands the PEP doesn't state what form the received
object will take.
Once channels supporting the transfer of bytes objects work, then it is
simple to pass more complex objects using pickle or marshal.
Channels need a more detailed description of their lifespan. Ideally a
state machine.
For example:
How does an interpreter detach from the receiving end of a channel that
is never empty?
What happens if an interpreter deletes the last reference to a non-empty
channel? On the receiving end, or on the sending end?
Isn't the lack of buffering in channels a recipe for deadlocks?
What is the mechanism for reliably copying exceptions from one
sub-interpreter to another in the `run()` method? If `run()` can raise
an exception, why not let it return values?
Cheers,
Mark.
On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of Python 3.9.0a6. Get it here:
https://www.python.org/downloads/release/python-390a6/ <https://www.python.org/downloads/release/python-390a6/>
This is an early developer preview of Python 3.9
Python 3.9 is still in development. This release, 3.9.0a6, is the last out of six planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2020-05-18) and, if necessary, may be modified or deleted up until the release candidate phase (2020-08-10). Please keep in mind that this is a preview release and its use is not recommended for production environments.
Major new features of the 3.9 series, compared to 3.8
Many new features for Python 3.9 are still being planned and written. Among the new major new features and changes so far:
PEP 584 <https://www.python.org/dev/peps/pep-0584/>, Union Operators in dict
PEP 585 <https://www.python.org/dev/peps/pep-0585/>, Type Hinting Generics In Standard Collections
PEP 593 <https://www.python.org/dev/peps/pep-0593/>, Flexible function and variable annotations
PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence
PEP 616 <https://www.python.org/dev/peps/pep-0616/>, String methods to remove prefixes and suffixes
PEP 617 <https://www.python.org/dev/peps/pep-0617/>, New PEG parser for CPython
BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects;
BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals;
BPO 39926 <https://bugs.python.org/issue39926>, Unicode support updated to version 13.0.0
BPO 1635741 <https://bugs.python.org/issue1635741>, when Python is initialized multiple times in the same process, it does not leak memory anymore
A number of Python builtins (range, tuple, set, frozenset, list) are now sped up using PEP 590 <https://www.python.org/dev/peps/pep-0590> vectorcall
A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>.
(Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:lukasz@python.org>.)
The next pre-release, the first beta release of Python 3.9, will be 3.9.0b1. It is currently scheduled for 2020-05-18.
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>
Why do sub-interpreters require (separate and) heap-allocated types?
It seems types that are statically allocated are a pretty good use for immortal objects, where you never change the refcount ... and then I don't see why you need more than one copy.
On behalf of the PyPA, I am pleased to announce that a beta release of pip, pip 20.1b1, has been released. I hope you will help us by testing this and checking for new bugs in how pip deals with complicated projects and dependencies.
The highlights for this release are:
* Significant speedups when building local directories, by changing behavior to perform in-place builds, instead of copying to temporary directories.
* Significant speedups in `pip list --outdated`, by parallelizing network access. This is the first instance of parallel code within pip's codebase.
* A new `pip cache` command, which makes it possible to introspect and manage pip's cache directory.
* Better `pip freeze` for packages installed from direct URLs, enabled by the implementation of PEP 610.
We would be grateful for all the testing that users could do to ensure that, when pip 20.1 is released, it's as solid as we can make it. You can upgrade to this beta with `python -m pip install -U --pre pip`.
This release also contains an alpha version of pip's next generation resolver. It is **off by default** because it is **unstable and not ready for everyday use**. If you're curious about this, please visit this GitHub issue about the resolver, what doesn't work yet, and what kind of testing would help us out https://github.com/pypa/pip/issues/8099 .
The full changelog is available. https://pip.pypa.io/en/latest/news/
As with all pip releases, a significant amount of the work was contributed by pip's user community. Huge thanks to all who have contributed, whether through code, documentation, issue reports and/or discussion. Your help keeps pip improving, and is hugely appreciated.
Specific thanks go to Mozilla (through its Mozilla Open Source Support Awards) and to the Chan Zuckerberg Initiative DAF, an advised fund of Silicon Valley Community Foundation, for their support that enabled the work on the new resolver.
--
Sumana Harihareswara
pip project manager under contract with Python Software Foundation
Changeset Consulting
https://changeset.nyc
SimpleNamespace() is really good at giving attribute style-access. I would like to make that functionality available to the JSON module (or just about anything else that accepts a custom dict) by adding the magic methods for mappings so that this works:
catalog = json.load(f, object_hook=SimpleNamespace)
print(catalog['clothing']['mens']['shoes']['extra_wide']['quantity']) # currently possible with dict()
print(catalog.clothing.mens.shoes.extra_wide.quantity]) # proposed with SimpleNamespace()
print(catalog.clothing.boys['3t'].tops.quantity # would also be supported
I've already seen something like this in production; however, people are having to write custom subclasses to do it. This is kind of bummer because the custom subclasses are a pain to write, are non-standard, and are generally somewhat slow. I would like to see a high-quality version this made more broadly available.
The core idea is keep the simple attribute access but make it easier to load data programmatically:
>>> ns = SimpleNamespace(roses='red', violets='blue')
>>> thing = input()
sugar
>>> quality = input()
sweet
>>> setattr(ns, thing, quality) # current
>>> ns['sugar'] = 'sweet' # proposed
If the PEP 584 __ior__ method were supported, updating a SimpleNamespace would be much cleaner:
ns |= some_dict
I posted an issue on the tracker: https://bugs.python.org/issue40284 . There was a suggestion to create a different type for this, but I don't see the point in substantially duplicating everything SimpleNamespace already does just so we can add some supporting dunder methods. Please add more commentary so we can figure-out the best way to offer this powerful functionality.
Raymond
Copy of Brett Cannon's message:
https://discuss.python.org/t/collecting-questions-for-a-steering-council-q-…
---
As part of PyCon US 2020 (*), we are planning to record a Q&A with the
Steering Council. We are using this topic to solicit questions from
the community. We plan to leave this open for about a week.
Thanks for all of those who leave a question (which adhere to the PSF
Code of Conduct )!
P.S. Do make sure to check out the various talks that have been posted
for the conference so far! And thanks in advance to Ewa, Emily, and
the whole PyCon US 2020 staff for making this Q&A possible.
(*) https://www.youtube.com/channel/UCMjMBMGt0WJQLeluw6qNJuA
---
Please ask your question at:
https://discuss.python.org/t/collecting-questions-for-a-steering-council-q-…
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
The Python Steering Council accepts PEP 615 - Support for the IANA Time Zone Database in the Standard Library:
https://www.python.org/dev/peps/pep-0615/
Congratulations Paul Ganssle!
This is a fantastic, well written PEP, and we appreciate Paul’s engagement with the SC to clear up our last questions and concerns. We look forward to its availability in Python 3.9. Thank you Paul, and everyone who helped contribute to this important new module.
Cheers,
-Barry (on behalf of the Python Steering Council)
I'm eudaemonic to announce the immediate availability of Python 2.7.18.
Python 2.7.18 is a special release. I refer, of course, to the fact that "2.7.18" is the closest any Python version number will ever approximate e, Euler's number. Simply exquisite!
A less transcendent property of Python 2.7.18 is that it is the last Python 2.7 release and therefore the last Python 2 release. It's time for the CPython community to say a fond but firm farewell to Python 2. Users still on Python 2 can use e to compute the instantaneously compounding interest on their technical debt.
Download this unique, commemorative Python release on python.org:
https://www.python.org/downloads/release/python-2718/
Python 2.7 has been under active development since the release of Python 2.6, more than 11 years ago. Over all those years, CPython's core developers and contributors sedulously applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3 branches diverged. There were large changes midway through Python 2.7's life such as PEP 466's feature backports to the ssl module and hash randomization. Traditionally, these features would never have been added to a branch in maintenance mode, but exceptions were made to keep Python 2 users secure. Thank you to CPython's community for such dedication.
Python 2.7 was lucky to have the services of two generations of binary builders and operating system experts, Martin von Löwis and Steve Dower for Windows, and Ronald Oussoren and Ned Deily for macOS. The reason we provided binary Python 2.7 releases for macOS 10.9, an operating system obsoleted by Apple 4 years ago, or why the "Microsoft Visual C++ Compiler for Python 2.7" exists is the dedication of these individuals.
I thank the past and present Python release managers, Barry Warsaw, Ned Deily, Georg Brandl, Larry Hastings, and Łukasz Langa for their advice and support over the years. I've learned a lot from them—like don't be the sucker who volunteers to manage the release right before a big compatibility break!
Python 3 would be nowhere without the critical work of the wider community. Library maintainers followed CPython by maintaining Python 2 support for many years but also threw their weight behind the Python 3 statement (https://python3statement.org). Linux distributors chased Python 2 out of their archives. Users migrated hundreds of millions of lines of code, developed porting guides, and kept Python 2 in their brain while Python 3 gained 10 years of improvements.
Finally, thank you to GvR for creating Python 0.9, 1, 2, and 3.
Long live Python 3+!
Signing off,
Benjamin
2.7 release manager
