Hi there,
I've been poking around the thread state API and error/exception
handling, and there's something missing I'd like to see happening.
The only way to retrieve the current exception is via sys.excinfo or
PyErr_GetExcInfo in C. However, the issue is that they don't take a
PyThreadState as argument, but use _PyThreadState_GET() to retrieve the
thread state.
That makes it impossible to retrieve the exception information for a
different thread than the one calling the function.
In order to retrieve the exception from *any* PyThreadState, the caller
has to use _PyErr_GetTopmostException which takes a PyThreadState as
argument — though that function is private and therefore not documented
or usable in an external module (in theory at least).
Should we make _PyErr_GetTopmostException public, or implement something
different to retrieve the top most exception from a PyThreadState?
Cheers,
--
Julien Danjou
# Free Software hacker
# https://julien.danjou.info
from locale import seasons_greetings
seasons_greetings()
On behalf of the entire Python development community, and the currently serving Python release team in particular, I'm pleased to announce the unprecedented combined release of no less than four versions of Python. Let's dig in!
Python 3.8.1
Python 3.8.1 is the first maintenance release of Python 3.8.
The Python 3.8 series is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.8.1 here:
https://www.python.org/downloads/release/python-381/ <https://www.python.org/downloads/release/python-381/>
See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series. Detailed information about all changes made in 3.8.1 can be found in its change log <https://docs.python.org/release/3.8.1/whatsnew/changelog.html#changelog>.
Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.2 planned for February 2020.
Python 3.7.6
Python 3.7.6, the next bugfix release of Python 3.7, is also available. You can find the release files, a link to the change log, and more information here:
https://www.python.org/downloads/release/python-376/ <https://www.python.org/downloads/release/python-376/>
Python 3.9.0a2
An early developer preview of Python 3.9 is also ready: https://www.python.org/downloads/release/python-390a2/ <https://www.python.org/downloads/release/python-390a2/>
Python 3.9 is still in development. This releasee, 3.9.0a2 is the second 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.
Python 3.6.10
And, one more thing: Python 3.6.10, the next security fix release of Python 3.6, is also available:
https://www.python.org/downloads/release/python-3610/ <https://www.python.org/downloads/release/python-3610/>
We hope you enjoy all those!
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/>
Your friendly release team,
Ned Deily
Steve Dower
Łukasz Langa
We ran into an issue where having the SQLite library built with -DSQLITE_THREADSAFE=0,
but then the sqlite3 module (really, the _sqlite3.so0 crashing in threading code. So I have
to ask if it is intended that the sqlite3 Python module always be built with a thread safe
SQLite library.
Thanks,
Tom
Currently str() takes up to 3 arguments. All are optional and
positional-or-keyword. All combinations are valid:
str()
str(object=object)
str(object=buffer, encoding=encoding)
str(object=buffer, errors=errors)
str(object=buffer, encoding=encoding, errors=errors)
str(encoding=encoding)
str(errors=errors)
str(encoding=encoding, errors=errors)
The last three are especially surprising. If you do not specify an
object, str() ignores values of encoding and errors and returns an empty
string.
bytes() and bytearray() are more limited. Valid combinations are:
bytes()
bytes(source=object)
bytes(source=string, encoding=encoding)
bytes(source=string, encoding=encoding, errors=errors)
I propose several changes:
1. Forbids calling str() without object if encoding or errors are
specified. It is very unlikely that this can break a real code, so I
propose to make it an error without a deprecation period.
2. Make the first parameter of str(), bytes() and bytearray()
positional-only. Originally this feature was an implementation artifact:
before 3.6 parameters of a C implemented function should be either all
positional-only (if used PyArg_ParseTuple), or all keyword (if used
PyArg_ParseTupleAndKeywords). So str(), bytes() and bytearray() accepted
the first parameter by keyword. We already made similar changes for
int(), float(), etc: int(x=42) no longer works.
Unlikely str(object=object) is used in a real code, so we can skip a
deprecation period for this change too.
3. Make encoding required if errors is specified in str(). This will
reduce the number of possible combinations, makes str() more similar to
bytes() and bytearray() and simplify the mental model: if encoding is
specified, then we decode, and the first argument must be a bytes-like
object, otherwise we convert an object to a string using __str__.
Hi,
I'd like to discuss the idea to add a module to parse TOML [toml-lang]
to Python's standard library.
PEP-0518 -- Specifying Minimum Build System Requirements for Python
Projects [pep] suggests to store build system dependencies in
`pyproject.toml`, yet Python itself does not support this format.
Various packaging related projects like pip and pipenv already support
PEP-0518 and vendored one of the existing TOML libraries in order to
read `pyproject.toml` files.
Besides that, TOML seems a better alternative to .cfg/.ini, .json --
both of which are already supported by Python's standard lib and
parsing/dumping TOML properly is tricky enough to solve it properly
[requirements].
There are a couple of TOML implementations out there [toml, pytoml,
tomlkit] and one would have to find out which one to prefer and migrate
into the stdlib.
If the result of this discussion is leaning towards adding TOML, I'd
volunteer to do it. This includes: coordinating with the maintainer of
the chosen library, writing the PEP (hopefully with some help) and
maintain the module for at least two years.
Cheers,
Bastian
[toml-lang]: https://github.com/toml-lang/toml
[pep]: https://www.python.org/dev/peps/pep-0518
[pip]: https://github.com/pypa/pip
[pipenv]: https://github.com/pypa/pipenv
[toml]: https://github.com/uiri/toml
[pytoml]: https://github.com/avakar/pytoml
[tomlkit]: https://github.com/sdispater/tomlkit
[requirements]: https://devguide.python.org/stdlibchanges/#requirements
--
Dr. Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
Hi folks,
While reviewing https://github.com/python/cpython/pull/17303/files, I
noticed that the configure script update removed the options for
`--runstatedir`. Those options appear to come from a Debian patch that
other distros don't yet have:
https://sources.debian.org/patches/autoconf/2.69-11/add-runstatedir.patch/
Since I use Fedora, running autoreconf locally on the review branch
didn't add those options back, but did add in various macros related
to Fedora's modular build system (we don't use those macros explicitly
ourselves, but presumably some of the m4 macros we do use include them
in their expansions when run on Fedora systems, so aclocal picked them
up).
Does anyone have any recommendations for dealing with this? My current
plan is to revert back to the configure script from master, run
autoreconf, and then use `git add -p` to only add in the desired
changes, leaving everything else as it was on master.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'm not sure if this is the right place to bring this up, python-ideas seemed like language issues and python-dev seemed like CPython issues.
There are several unhashable builtin types present in CPython, as of today the ones I've noticed are: lists, dicts, sets, and bytearrays.
Two of these are containers that require (at least partially) their members to be hashable: dicts and sets
By this logic you cannot have a set of lists or a dict of sets to ints.
CPython however does not stop or warn you if you attempt to do such a thing until it hits `BUILD_MAP` or `BUILD_SET` during runtime.
This is reasonable behavior when it's not possible to infer the member type of the container i.e. ``{f(x) for x in iterable}`` or ``{f(x): y for zip(xs, ys)}``
However, given the situation where literals are nested i.e. ``{[*gen] for gen in gens}`` or ``{{green: eggs}, {and_: ham}}`` this presents an unavoidable exception at runtime.
I suggest emitting a SyntaxWarning when encountering these cases of literals that produce unhashable types that are used in literals that produce types where the members must be hashable.
I don't think it should be a SyntaxError because it's not a language issue, its an implementation issue.
I don't think it should be a linters responsibility because for the most part linters should consider language issues/idioms not side-effects from the running implementation.
I do understand that such cases this issue addresses may be uncommon and once you do get that TypeError raised its a relatively quick and easy fix, but consider this being present in code paths that don't get taken as frequently, large codebases where it becomes difficult to keep track of small one liner literals like this or even for the newer programmers toying with Python through CPython and naively using unhashables in places they shouldn't be.
Either way I'm interested in hearing what the core team thinks of this suggestion, thanks in advance! :D
