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
If per-subinterpeter GILs are possible then, and only then,
sub-interpreters will provide true parallelism and (limited) shared
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.
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?
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
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?
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.
pip project manager under contract with Python Software Foundation
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()
>>> quality = input()
>>> 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.
The Python Steering Council accepts PEP 615 - Support for the IANA Time Zone Database in the Standard Library:
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.
-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:
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+!
2.7 release manager