Currently, Python doesn't allow non-default arguments after default
arguments:
>>> def foo(x=None, y): pass
File "<stdin>", line 1
def foo(x=None, y): pass
^
SyntaxError: non-default argument follows default argument
I believe that at the time this was introduced, no use cases for this
were known and this is is supposed to prevent a source of bugs. I have
two use cases for this, one fringe, but valid, the other more important:
The fringe use case: Suppose you have a function that takes a 2D
coordinate value as separate "x" and "y" arguments. The "x" argument is
optional, the "y" argument isn't. Currently there are two ways to do
this, none of them particularly great:
def foo(y, x): # reverse x and y arguments, confusing
...
def foo(x, y=None): # Treat the x argument as y if only one argument is
provided
if y is None:
x, y = y, x
...
To me, the "natural" solution looks like this:
def foo(x=None, y): ...
# Called like this:
foo(1, 2)
foo(y=2)
This could also be useful when evolving APIs. For example there is a
function "bar" that takes two required arguments. In a later version,
the first argument gains a useful default, the second doesn't. There is
no sensible way to evolve the API at the moment.
The more important use case involves @overloads. A condensed example of
a function where the return type depends on an "encoding" parameter,
followed by further parameters that could be called like this:
foo(123, "utf-8") # would return bytes
foo(encoding="utf-8")
foo(123, None) # would return str
foo(encoding=None)
foo(x=123) # would return str
foo()
This could ideally be written as:
@overload
def foo(x: int = ..., encoding: None = ...) -> str: ...
@overload
def foo(x: int = ..., encoding: str) -> bytes: ...
# plus the actual implementation
But due to the syntax constraint, this needs to be hacked around with a
third overload:
@overload
def foo(x: int = ... encoding: None = ...) -> str: ...
@overload
def foo(x: int, encoding: str) -> bytes: ... # for foo(123, "utf-8")
@overload
def foo(*, encoding: str) -> bytes: ... # for foo(encoding="utf-8")
Not only is this hard to read, real examples in typeshed are usually
more complex, with many arguments before or after the affected argument
or even multiple affected arguments. This often becomes too complex to
write or maintain. Here is one example from the wild:
https://github.com/python/typeshed/blob/b95b729b9e07ab21d252701af0f5b740467…
Allowing non-default arguments after default arguments would solve both
use cases above and eliminates a special case. I'm also not sure what
exactly the current SyntaxError really protects us from. Adding a
non-default after a default argument can't really lead bugs.
- Sebastian
Hi,
I've been working on changes to CPython to allow it to run without the
global interpreter lock. I'd like to share a working proof-of-concept that
can run without the GIL. The proof-of-concept involves substantial changes
to CPython internals, but relatively few changes to the C-API. It is
compatible with many C extensions: extensions must be rebuilt, but usually
require small or no modifications to source code. I've built compatible
versions of packages from the scientific Python ecosystem, and they are
installable through the bundled "pip".
Source code:
https://github.com/colesbury/nogil
Design overview:
https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlej…
My goal with the proof-of-concept is to demonstrate that removing the GIL
is feasible and worthwhile, and that the technical ideas of the project
could serve as a basis of such an effort.
I'd like to start a discussion about these ideas and gauge the community's
interest in this approach to removing the GIL.
Regards,
Sam Gross
colesbury(a)gmail.com / sgross(a)fb.com
Not much time left! I’ve released 3.12.0 beta 4. We’re now in the run-up to
rc1, so keep that in mind when you backport to the 3.12 branch.
https://www.python.org/downloads/release/python-3120b4/
*This is a beta preview of Python 3.12*
Python 3.12 is still in development. This release, 3.12.0b4, is the final
of four beta release previews of 3.12.
Beta release previews are intended to give the wider community the
opportunity to test new features and bug fixes and to prepare their
projects to support the new feature release.
We *strongly encourage* maintainers of third-party Python projects to *test
with 3.12* during the beta phase and report issues found to the Python bug
tracker <https://github.com/python/cpython/issues> as soon as possible.
While the release is planned to be feature complete entering the beta
phase, it is possible that features may be modified or, in rare cases,
deleted up until the start of the release candidate phase (Monday,
2023-07-31). Our goal is to have no ABI changes after this release, and as
few code changes as possible after 3.12.0rc1, the first release candidate.
To achieve that, it will be *extremely important* to get as much exposure
for 3.12 as possible during the beta phase.
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.12 series, compared to 3.11*
Some of the new major new features and changes in Python 3.12 are:
- New type annotation syntax for generic classes (PEP 695
<https://peps.python.org/pep-0695/>).
- More flexible f-string parsing, allowing many things previously
disallowed (PEP 701 <https://peps.python.org/pep-0701/>).
- Support for the buffer protocol in Python code (PEP 688
<https://peps.python.org/pep-0688/>).
- Even more improved error messages. More exceptions potentially caused
by typos now make suggestions to the user.
- Many large and small performance improvements (like PEP 709
<https://peps.python.org/pep-0709/>).
- Support for the Linux perf profiler to report Python function names in
traces.
- The deprecated wstr and wstr_length members of the C implementation of
unicode objects were removed, per PEP 623
<https://peps.python.org/pep-0623/>.
- In the unittest module, a number of long deprecated methods and
classes were removed. (They had been deprecated since Python 3.1 or 3.2).
- The deprecated smtpd and distutils modules have been removed (see PEP
594 <https://peps.python.org/pep-0594/> and PEP 632
<https://peps.python.org/pep-0632/>. The setuptools package continues to
provide the distutils module.
- A number of other old, broken and deprecated functions, classes and
methods have been removed.
- Invalid backslash escape sequences in strings now warn with SyntaxWarning
instead of DeprecationWarning, making them more visible. (They will
become syntax errors in the future.)
- The internal representation of integers has changed in preparation for
performance enhancements. (This should not affect most users as it is an
internal detail, but it may cause problems for Cython-generated code.)
- (Hey, fellow core developer, if a feature you find important is
missing from this list, let Thomas know <thomas(a)python.org>.)
For more details on the changes to Python 3.12, see What’s new in Python
3.12 <https://docs.python.org/3.12/whatsnew/3.12.html>. The next
pre-release of Python 3.12 will be 3.12.0rc1, the *first release candidate*,
currently scheduled for 2023-07-31.
*More resources*
Online Documentation <https://docs.python.org/3.12/>.
PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the Python 3.12
Release Schedule.
Report bugs via GitHub Issues <https://github.com/python/cpython/issues>.
Help fund Python and its community <https://www.python.org/psf/donations/>.
*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-landing/>.
Regards from the alternating thunderstorms and heat waves in Amsterdam,
Thomas Wouters.
Your release team,
Ned Deily
Steve Dower
Łukasz Langa
--
Thomas Wouters <thomas(a)python.org>
