Wing 8.3.3 improves display of bytes values in the Stack Data tool,
fixes several remote development issues, correctly reports exceptions
while loading Django test files, runs Python with the correct command
line when using -m with wingdb, prevents unwanted timeout of the debug
connection, avoids adding unwanted spaces around =, !, : in f-string
expressions, correctly pastes form feed characters and avoids stripping
them as trailing white space, prevents corrupting projects when opening
a project using the .wpu file (rather than the .wpr file), and makes a
number of other usability improvements.
Details: https://wingware.com/news/2022-07-28
Downloads: https://wingware.com/downloads
== About Wing ==
Wing is a full-featured but light-weight Python IDE designed
specifically for Python, with powerful editing, code inspection,
testing, and debugging capabilities. Wing's deep code analysis provides
auto-completion, auto-editing, code navigation, early error detection,
and refactoring that speed up development. Its top notch debugger works
with any Python code, locally or on a remote host, container, or
cluster. Wing also supports test-driven development, version control,
Python package management, UI color and layout customization, and
includes extensive documentation and support.
Wing is available in three product levels: Wing Pro is the
full-featured Python IDE for professional developers, Wing Personal is a
free Python IDE for students and hobbyists (omits some features), and
Wing 101 is a very simplified free Python IDE for beginners (omits many
features).
Learn more at https://wingware.com/
A new SCons release, 4.4.0, is now available
on the SCons download page:
https://scons.org/pages/download.html
Here is a summary of the changes since 4.3.0:
NOTE: If you build with Python 3.10.0 and then rebuild with 3.10.1 (or
higher), you may
see unexpected rebuilds. This is due to Python internals changing
which changed
the signature of a Python Action Function.
NEW FUNCTIONALITY
-----------------
- Added MSVC_USE_SCRIPT_ARGS Environment variable which specifies command
line arguments
to pass to the script specified by MSVC_USE_SCRIPT.
- Added Configure.CheckMember() checker to check if struct/class has the
specified member.
- Added SHELL_ENV_GENERATORS construction variable. This variable should be
set to a list
(or an iterable) which contains functions to be called in order
when constructing the execution environment (Generally this is the shell
environment
variables). This allows the user to customize how (for example) PATH is
constructed.
Note that these are called for every build command run by SCons. It could
have considerable
performance impact if not used carefully.
- Added MSVC_USE_SETTINGS construction variable to pass a dictionary to
configure the msvc compiler
system environment as an alternative to bypassing Visual Studio
autodetection entirely.
- Added MSVC_SDK_VERSION construction variable which allows building with a
specific Microsoft
SDK version. This variable is used with the msvc batch file determined
via autodetection. Refer
to the documentation for additional requirements and validation details.
- Added MSVC_TOOLSET_VERSION construction variable which allows building
with a specific toolset
version. This variable is used with the msvc batch file determined via
autodetection. This
variable does not affect the autodetection and selection of msvc
instances. The toolset version
is applied after an msvc instance is selected. This could be the default
version of msvc. Refer
to the documentation for additional requirements and validation details.
Addresses issue #3265,
issue #3664, and pull request #4149.
- Added MSVC_SPECTRE_LIBS construction variable which allows building with
spectre-mitigated
Visual C++ libraries. This variable is used with the msvc batch file
determined via autodetection.
Refer to the documentation for additional requirements and validation
details.
- Added MSVC_SCRIPT_ARGS construction variable which specifies command line
arguments that are
passed to the msvc batch file determined via autodetection. Refer to the
documentation for
additional requirements and validation details. Addresses enhancement
issue #4106.
- Ninja: Added new alias "shutdown-ninja-scons-daemon" to allow ninja to
shutdown the daemon.
Also added cleanup to test framework to kill ninja scons daemons and
clean ip daemon logs.
NOTE: Test for this requires python psutil module. It will be skipped if
not present.
- Ninja: Added command line variable NINJA_CMD_ARGS that allows to pass
through ninja command line args.
This can also be set in your Environment().
- Added a global policy setting and an environment construction variable
for specifying the
action to be taken when an msvc request cannot be satisfied. The
available options are "error",
"exception", "warning", "warn", "ignore", and "suppress". The global
policy variable may be
set and retrieved via the functions msvc_set_notfound_policy and
msvc_get_notfound_policy,
respectively. These two methods may be imported from
SCons.Tool.MSCommon. The environment
construction variable is MSVC_NOTFOUND_POLICY. When defined, the
environment construction
variable overrides the global policy setting for a given environment.
When the active policy
is "error" or "exception", an MSVCVersionNotFound exception is raised.
When the active policy
is "warning" or "warn", a VisualCMissingWarning warning is issued and the
constructed
environment is likely incomplete. When the active policy is "ignore" or
"suppress", no action
is taken and the constructed environment is likely incomplete. As
implemented, the default
global policy is "warning". The ability to set the global policy via an
SCons command-line
option may be added in a future enhancement.
- Added a global policy setting and an environment construction variable
for specifying the
action to be taken when msvc script errors are detected. The available
options are "error",
"exception", "warning", "warn", "ignore", and "suppress". The global
policy variable may be
set and retrieved via the functions msvc_set_scripterror_policy and
msvc_get_scripterror_policy,
respectively. These two methods may be imported from
SCons.Tool.MSCommon. The environment
construction variable is MSVC_SCRIPTERROR_POLICY. When defined, the
environment construction
variable overrides the global policy setting for a given environment.
When the active policy
is "error" or "exception", an MSVCScriptExecutionError exception is
raised when msvc batch file
errors are detected. When the active policy is "warning" or "warn", an
MSVCScriptExecutionWarning
warning is issued when msvc batch file errors are detected. When the
active policy is "ignore" or
"suppress", msvc batch error messages are suppressed. As implemented,
the default global policy
is "ignore". The ability to set the global policy via an SCons
command-line option may be added
in a future enhancement.
- Added experimental function msvc_query_version_toolset to
SCons.Tool.MSCommon. Given a version
specification, this function will return an msvc version and an msvc
toolset version. The msvc
toolset version may be None. The msvc version and msvc toolset version
can be used in the
environment construction variables MSVC_VERSION and MSVC_TOOLSET_VERSION,
respectively. The
version specification may be an msvc version or an msvc toolset version.
This is a proxy for
using an msvc toolset version to select an msvc instance. This function
may be removed when an
msvc toolset version is used during msvc instance selection.
- Fortran: a new construction variable FORTRANCOMMONFLAGS is added which is
applied to all Fortran dialects, to enable global (all-dialect) settings.
- lex: two new construction variables are introduced (LEX_HEADER_ILE
and LEX_TABLES_FILE) as the preferred way of specifying extra files that
the tool can generate.
- yacc: two new construction variables are introduced (YACC_HEADER_FILE
and YACC_GRAPH_FILE) as the preferred way of specifying extra files that
the tool can generate (applies only when using GNU flex and GNU bison).
CHANGED/ENHANCED EXISTING FUNCTIONALITY
---------------------------------------
- On Windows, %AllUsersProfile%\scons\site_scons is now the default "system"
location for a site_scons directory.
%AllUsersProfile%\Application Data\scons\site_scons will continue to work.
There does not seem to be any existing convention to use an
"Application Data" subdirectory here.
- Action._subproc() can now be used as a python context manager to ensure
that the
POpen object is properly closed.
- SCons help (-H) no longer prints the "ignored for compatibility" options,
which are still listed in the manpage.
- Help is now sensitive to the size of the terminal window: the width of the
help text will scale to wider (or narrower) terminals than 80 characters.
- Ninja: Changed generated build.ninja file to run SCons only build Actions
via
a SCons Deamon. Added logic for starting and connecting to SCons daemon
(currently
only used for ninja)
- The change to "content" and "content-timestamp" Decider names is reflected
in the User Guide as well, since the hash function may be other than md5
(tidying up from earlier change)
- If the (experimental) SCONS_CACHE_MSVC_CONFIG feature is used, it will now
attempt a sanity check for the cached compiler information, and regenerate
it if needed. Previously, this cache would fail if a compiler upgrade
caused
a change to internal paths (e.g. upgrading from 17.1 to 17.2 causes
a necessary path component in some of the cached vars to need to
14.32.31326
instead of 14.31.31103), and the cache file needed to be manually removed.
The default cachefile name is now "scons_msvc_cache.json" rather than
".scons_msvc_cache" so there should be no transition problem if using the
default; if using a custom cache file name, the cache should still be
manually removed if there are problems to transition to the new style.
- Ninja: Update ninja file generation to only create response files for
build commands
which exceed MAXLINELENGTH
- Update the debug output written to stdout for MSVC initialization which
is enabled
by setting SCONS_MSCOMMON_DEBUG=- to use the logging module. Also changed
the debug
output format written to stdout to include more information about the
source for each
message of MSVC initialization debugging output. A single space was
added before the
message for all debugging output records written to stdout and to files.
- Ninja: Made ninja tool force the ninja file as the only target. Also
improved the default
targets setup and made sure there is always a default target for
the ninja file, which excludes targets that start and stop the daemon.
- Ninja: Update ninja tool so targets passed to SCons are propgated to
ninja when scons
automatically executes ninja.
- Add JavaScanner to include JAVACLASSPATH as a dependency when using the
Java tool.
- The build argument (i.e., x86) is no longer passed to the MSVC 6.0 to 7.1
batch
files. This may improve the effectiveness of the internal msvc cache
when using
MSVC detection and when bypassing MSVC detection as the MSVC 6.0 to 7.1
batch files
do not expect any arguments.
- Propagate the OS and windir environment variables from the system
environment to the msvc
environment. The OS and windir environment variables are used in the
MSVC 6.0 batch file
and the SDK 6.0-7.1 SetEnv.cmd batch files. Inclusion of the OS and
windir environment
variables eliminates some partial paths and warnings generated by the
MSVC 6.0 and SDK
6.0-7.1 batch files when the variables are not defined.
Note: Attempting to run the SDK 6.0-7.1 batch files directly via
MSVC_USE_SCRIPT can lead to
build failures and/or incomplete build environments. The SDK
6.0-7.1 batch files
require delayed expansion to be enabled which is currently not
supported and is
typically not enabled by default on the host system. The batch
files may also require
environment variables that are not included by default in the msvc
environment.
- An exception is raised when MSVC_UWP_APP is enabled for Visual Studio
2013 and earlier.
Previous behavior was to silently ignore MSVC_UWP_APP when enabled for
Visual Studio 2013
and earlier. Refer to the documentation for additional requirements and
validation details.
MSVC_UWP_APP was extended to accept True, False, and None in addition to
'1' and '0'.
- Ninja: added option "--skip-ninja-regen" to enable skipping regeneration
of the ninja file
if scons can determine the ninja file doesnot need to be regenerated,
which will also
skip restarting the scons daemon. Note this option is could result in
incorrect rebuilds
if scons Glob or scons generated files are used in ninja build target's
command lines.
- Tool loading used to have a special case for Jython, it no longer does.
This effectively
means SCons doesn't work with Jython, which has in reality been the case
ever since
SCons dropped Python 2 support - there is still no timeline for Jython
switching to
Python 3 compatibility.
FIXES
-----
- Fix a number of Python ResourceWarnings which are issued when running
SCons and/or it's tests
with python 3.9 (or higher)
- Ninja: Fix issue where Configure files weren't being properly processed
when build run
via ninja.
- Fixed crash in C scanner's dictify_CPPDEFINES() function which happens if
AppendUnique is called on CPPPATH. (Issue #4108).
- Added default values for source and target arguments to _defines()
function. This
is used to expand CPPDEFINES (and others). Previous change added those
arguments
with no defaults, so old usage where _defines() was called without source
and target
arguments would yield an exception. This issue was found via qt4 and qt5
tools in
scons-contrib https://github.com/SCons/scons-contrib/issues/45
- Fix issue where if you only had mingw installed on a Windows system and
no MSVC compiler, and
did not explicitly request the mingw tool, mingw tool initialization
would fail and set the
default compiler to MSVC which wasn't installed, yielding broken build.
Updated mingw tool so that the generate and exists methods use the same
mingw search paths
(issue #4134).
- Ninja: Added NINJA_GENERATED_SOURCE_ALIAS_NAME which allows user to
specify an
Alias() which the ninja tool can use to determine which files are
generated sources.
If this is not set by the user then the ninja tool will still dynamically
determine
which files are generated sources based on
NINJA_GENERATED_SOURCE_SUFFIXES, and create
a phony target _ninja_generated_sources. Generated sources will be built
first by
ninja. This is needed because ninja cannot determine which generated
sources are
required by other build targets. Code contributed by MongoDB.
- Added special case for ninja scons daemon to work in win32 python3.6
environments.
This particular environment does a bad job managing popen standard file
handles, so
some special workarounds are needed.
- Added user configurable setting of ninja depfile format via
NINJA_DEPFILE_PARSE_FORMAT.
Now setting NINJA_DEPFILE_PARSE_FORMAT to [msvc,gcc,clang] can force the
ninja expected
format. Compiler tools will also configure the variable automatically.
- Fix issue where Express versions of the MSVC compiler were not detected
due to differences
in initial msvc detection and msvc batch file determination when
configuring the build
environment. This could lead to build failures when only an MSVC Express
instance is installed
and the MSVC version is not explicitly specified (issue #2668 and issue
#2697).
- Restore the ability of the content-timestamp decider to see that a
a source which is a symlink has changed if the file-system target of
that link has been modified (issue #3880)
- Fix typo in ninja scons daemon startup which causes
ConnectionRefusedError to not retry
to connect to the server during start up.
- Fix incorrect Java classpath generation when a NodeList is used as part
of any JAVA*PATH variables.
- The system environment variable names imported for MSVC 7.0 and 6.0 were
updated to be
consistent with the variables names defined by their respective
installers. This fixes an
error caused when bypassing MSVC detection by specifying the MSVC 7.0
batch file directly.
- lex: Fixed an issue with the lex tool where file arguments specified to
either "--header-file="
or "--tables-file=" which included a space in the path to the file would
be processed incorrectly
- Modify the MSCommon logger configuration to be independent of the root
logger. This fixes an issue
when multiple loggers are created and the MSCommon logger added computed
fields to the root logger
that are not present in other logging instances.
- Modify the MSVC_USE_SCRIPT_ARGS test fixture to disable the msvc cache.
This fixes an issue where
the MSVC_USE_SCRIPT_ARGS test for success relied on a debug log message
that was not produced when
the msvc cache file exists and the test keys are already in the cache as
the msvc script invocation
was bypassed.
- Suppress issuing a warning when there are no installed Visual Studio
instances for the default
tools configuration (issue #2813). When msvc is the default compiler
because there are no
compilers installed, a build may fail due to the cl.exe command not being
recognized. At
present, there is no easy way to detect during msvc initialization if the
default environment
will be used later to build a program and/or library. There is no
error/warning issued for the
default tools as there are legitimate SCons uses that do not require a c
compiler.
IMPROVEMENTS
------------
- Verify that a user specified msvc script (via MSVC_USE_SCRIPT) exists and
raise an
exception immediately when the user specified msvc script does not exist.
- Add cache-debug messages for push failures.
- Ninja: Added ninja mingw support and improved ninja
CommandGeneratorAction support.
- Command-line help is now sensitive to the size of the terminal window: the
width of the help text will scale for terminals other than 80 chars wide.
- Refactor the msvc code so that the same data structures are used during
initial msvc detection
and msvc batch file determination when configuring the build
environment. Simplify the msvc
code by eliminating special case handling primarily due to the
differences between the full
versions and express versions of visual studio.
- Small refactor of scons daemons using a shared StateInfo class for
communication
between the scons interactive thread and the http server thread. Added
error handling
for scons interactive failing to startup.
- Ninja: Updated ninja scons daemon scripts to output errors to stderr as
well as the daemon log.
- Ninja: Ensure that all targets set as default via Default() in
SConstruct/SConscripts are
default targets in the generated ninja.build file.
PACKAGING
---------
- Added project_url for mailing lists and Discord
- Updated setup.cfg to remove Python 3.5 and add Python 3.10
Thanks to the following contributors listed below for their contributions
to this release.
==========================================================================================
.. code-block:: text
git shortlog --no-merges -ns 4.3.0..HEAD
git shortlog --no-merges -ns 4.3.0..HEAD
174 Joseph Brill
126 Mats Wichmann
93 William Deegan
64 Daniel Moody
4 SergBobrovsky
2 dependabot[bot]
1 djh
1 Ivan Kravets
1 Vishwajith-K
1 Zhichang Yu
I’m happy to announce a new release of attrs!
attrs is the direct ancestor of – and the inspiration for – dataclasses in the standard library and remains the more powerful toolkit for creating regular classes without getting bogged down with writing repetitive boilerplate code: <https://www.attrs.org/>
My heartfelt thanks go to:
- My generous GitHub sponsors <https://github.com/sponsors/hynek>,
- companies subscribing to attrs on Tidelift <https://tidelift.com/subscription/pkg/pypi-attrs>,
- and people who buy me coffees on <https://ko-fi.com/the_hynek>!
❤️ That's the support that made me maintain attrs since 2015 with no end in sight! ❤️
------------------------------------------------------------------------
(alternatively, see <https://github.com/python-attrs/attrs/releases> for a richer-formatted version of the following)
Highlights
The main features of this release are:
- The departure of Python 2.7 (enjoy your retirement!),
- and the arrival of Python 3.11.
We had loftier goals feature-wise, but didn't want to block others embracing Python 3.11.
Full Changelog
Backwards-incompatible Changes
- Python 2.7 is not supported anymore.
Dealing with Python 2.7 tooling has become too difficult for a volunteer-run project.
We have supported Python 2 more than 2 years after it was officially discontinued and feel that we have paid our dues. All version up to 21.4.0 from December 2021 remain fully functional, of course. #936
- The deprecated cmp attribute of attrs.Attribute has been removed. This does not affect the cmp argument to attr.s that can be used as a shortcut to set eq and order at the same time. #939
Changes
- Instantiation of frozen slotted classes is now faster. #898
- If an eq key is defined, it is also used before hashing the attribute. #909
- Added attrs.validators.min_len(). #916
- attrs.validators.deep_iterable()'s member_validator argument now also accepts a list of validators and wraps them in an attrs.validators.and_(). #925
- Added missing type stub re-imports for attrs.converters and attrs.filters. #931
- Added missing stub for attr(s).cmp_using(). #949
- attrs.validators._in()'s ValueError is not missing the attribute, expected options, and the value it got anymore. #951
- Python 3.11 is now officially supported. #969
Here we are. The universe. The vastness of spacetime. At the edge. The last
frontier. The last beta*(conditions apply) for Python 3.11.
We have defied the powerful gods of release blockers and we have won by
using the required amount of ruse and subterfuge.
https://www.python.org/downloads/release/python-3110b5/
## :warning: PLEASE HELP US TO TEST THIS RELEASE :warning:
Due to the modified release schedule and the stability concerns regarding
the past beta releases, please, please, please, please, help us to test
Python 3.11 by testing this beta releases.
* if you maintain a library or a third-party package. Test the beta
releases!
* If you have code that you maintain at work/research
centre/classroom/whatever. Test the beta releases!
* If you are a multi-million corporation that uses Python. Test the beta
releases!
* If you are a single-person company that uses Python. Test the beta
releases!
* If you have a bunch of Python scripts. Test the beta releases!
* If you use Python for work, research, teaching or literally for anything.
Test the beta releases!
* If you ...
In summary: no matter who you are of what you do. Test the beta releases!
Is **very** important for us that we identify all possible things that may
break your code **before** the final release is done and we can only do
this if you help us by testing the beta releases and then report anything
that doesn't work!
## This is a beta preview of Python 3.11
Python 3.11 is still in development. 3.11.0b5 is the last of five planned
beta release previews. 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.11** 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,
2021-08-02). Our goal is have no ABI changes after beta 5 and as few code
changes as possible after 3.11.0rc1, the first release candidate. To
achieve that, it will be **extremely important** to get as much exposure
for 3.11 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.11 series, compared to 3.10
Some of the new major new features and changes in Python 3.11 are:
## General changes
* [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include
Fine-Grained Error Locations in Tracebacks
* [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups
and except*
* [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support
for Parsing TOML in the Standard Library
* [PEP 681](https://www.python.org/dev/peps/pep-0681/)-- Data Class
Transforms
* [bpo-46752](https://github.com/python/cpython/issues/90908)-- Introduce
task groups to asyncio
* [bpo-433030](https://github.com/python/cpython/issues/34627/) -- Atomic
grouping ((?>...)) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are
now supported in regular expressions.
* The [Faster Cpython Project](https://github.com/faster-cpython/) is
already yielding some exciting results. Python 3.11 is up to 10-60% faster
than Python 3.10. On average, we measured a 1.22x speedup on the standard
benchmark suite. See [Faster CPython](
https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details.
## Typing and typing language changes
* [PEP 673](https://www.python.org/dev/peps/pep-0673/) -- Self Type
* [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics
* [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal
String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual
TypedDict items as required or potentially-missing
<small>(Hey, **fellow core developer,** if a feature you find important is
missing from this list, [let Pablo know](mailto:pablogsal@python.org
).)</small>
The next pre-release of Python 3.11 will be 3.11.0rc1, currently scheduled
for Monday, 2022-08-01.
# More resources
* [Online Documentation](https://docs.python.org/3.11/)
* [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release
Schedule
* Report bugs at [
https://github.com/python/cpython/issues](https://github.com/python/cpython…
.
* [Help fund Python and its community](/psf/donations/).
# And now for something completely different
Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after
Albert Einstein and Nathan Rosen), are connections between areas of space
that can be modelled as vacuum solutions to the Einstein field equations,
and that are now understood to be intrinsic parts of the maximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
the spacetime).
The Einstein–Rosen bridge was discovered by Ludwig Flamm in 1916, a few
months after Schwarzschild published his solution, and was rediscovered by
Albert Einstein and his colleague Nathan Rosen, who published their result
in 1935. However, in 1962, John Archibald Wheeler and Robert W. Fuller
published a paper showing that this type of wormhole is unstable if it
connects two parts of the same universe and that it will pinch off too
quickly for light (or any particle moving slower than light) that falls in
from one exterior region to make it to the other exterior region.
Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).
# Release hashes
The BSD-style checksum hashes for the release artefacts are:
SHA256 (python-3.11.0b5-amd64.exe) =
0cf9d582da862f2fe207fd54b81dfca110e8f04f4b05ab8c3228ce1ea060c7af
SHA256 (python-3.11.0b5-arm64.exe) =
a71efd9d3835d493d8207a30916ce3417af17295c02a9b0783dc740754f6e40b
SHA256 (python-3.11.0b5-embed-amd64.zip) =
5584ddbd21f45ce74ce0512eeb1d817d15374b1b7a461d79f973f6dd48ab5d9e
SHA256 (python-3.11.0b5-embed-arm64.zip) =
819924f10eb08ea6322b6040a2fb953137866bb1034cd4e8fe6e93c7c0b37e31
SHA256 (python-3.11.0b5-embed-win32.zip) =
18927604bcbe3c226be7864cde0c1f25ad35c6333d9d3125dfff8ca4fc872255
SHA256 (python-3.11.0b5.exe) =
382eb4c6dc1606bd3cf6f4bdeec8e1e7dab444c5aa23b86142d608a480d7c195
SHA256 (python-3.11.0b5-macos11.pkg) =
cd8e6d98e79a4adcd376c486405a535b004cf9a58a71487a11bc424acd815012
SHA256 (Python-3.11.0b5.tar.xz) =
3810bd22f7dc34a99c2a2eb4b85264a4df4f05ef59c4e0ccc2ea82ee9c491698
SHA256 (Python-3.11.0b5.tgz) =
3f7d1a4ab0e64425f4ffd92d49de192ad2ee1c62bc52e3877e9f7b254c702e60
The hashes are also attached to this email.
# 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/
If you have any questions, please reach out to me or another member of the
release team :)
Your friendly release team,
Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
I have just released a new module, called pil_printer:
With the pil_printer module it is possible to print a PIL image or several
PIL images to a printer under Windows.
The most common use case is to print JPG or PNG file(s) at an exact point
with an exact scaling.
Most graphics programs don’t support exact placement and the user has
nearly always to manually control this placement/scaling for each image.
The package can be downloaded here:
github.com/salabim/pil_printerIt is not (yet) available on PyPI.
Hi all,
CodraFT is an open-source generic signal and image processing software, based on Python, Qt, NumPy, SciPy and others:
https://codra-ingenierie-informatique.github.io/CodraFT/
I am pleased to announce that CodraFT v2.1.1 has been released.
This is the second public release of version 2, compatible with Python 3.7+.
CodraFT provides signal/image processing and visualisation features, and is available either as a stand-alone application or may be embedded in your own Python-Qt application thanks to advanced automation capabilities. CodraFT also has many I/O features, supporting a lot of images format as well as HDF5 (for saving/loading CodraFT workspace or importing any other data file).
Enjoy!
--
Always a pleasure to share with Python community, since 2008.
Pierre Raybaut
I’m happy to announce a new release of structlog!
With more than 4 million downloads per month, structlog is the most popular solution for structured logging in Python. It doesn’t just allow you to log key-value pairs in a structured manner, it also makes it EASIER and FASTER. Check out <https://www.structlog.org/en/stable/why.html> if you’re intrigued but not convinced!
My heartfelt thanks go to:
- My generous GitHub sponsors <https://github.com/sponsors/hynek>,
- companies subscribing to structlog on Tidelift <https://tidelift.com/subscription/pkg/pypi-structlog>,
- and people who buy me coffees on <https://ko-fi.com/the_hynek>!
That's the support that made me maintain structlog for almost a decade with no end in sight! <3
------------------------------------------------------------------------
(alternatively, see <https://github.com/hynek/structlog/releases/tag/22.1.0> for a richer-formatted version of the following)
Highlights
This is a (too) big release, so it has many highlights!
Firstly, rendering exceptions in machine-readable logs (usually JSON) got a big upgrade: thanks to structlog.processors.dict_tracebacks you can now have fully structured exceptions in your logs!
To ease getting started with structlog, we're now shipping structlog.stdlib.recreate_defaults() that recreates structlog's default behavior, but on top of standard library's logging. The output looks the same, but it runs through logging's machinery and integrates itself easier. The default configuration now also merges your contextvars-based context, so enjoy structlog.contextvars.bind_contextvars() without configuring anything!
Another request wish that kept coming up is naming the message key differently than event. We're aware that nowadays keys like msg are more common, but structlog pre-dates the software that introduced and popularized it. To allow for more consistency across your platforms, structlog now ships structlog.processors.EventRenamer that allows you to rename the default event key to something else and additionally also allows you to rename another key to event.
Full Changelog
Removed
- Python 3.6 is not supported anymore.
- Pickling is now only possible with protocol version 3 and newer.
Deprecated
- The entire structlog.threadlocal module is deprecated. Please use the primitives from structlog.contextvars instead.
If you're using the modern APIs (bind_threadlocal() / merge_threadlocal()) it's enough to replace them 1:1 with their contextvars counterparts. The old approach around wrap_dict() has been discouraged for a while.
Currently there are no concrete plans to remove the module, but no patches against it will be accepted from now on. #409
Added
- structlog.processors.StackInfoRenderer now has an additional_ignores parameter that allows you to filter out your own logging layer. #396
- Added structlog.WriteLogger, a faster – but more low-level – alternative to structlog.PrintLogger. It works the way PrintLogger used to work in previous versions. #403 #404
- structlog.make_filtering_bound_logger()-returned loggers now also have a log() method to match the structlog.stdlib.BoundLogger signature closer. #413
- Added structured logging of tracebacks via the structlog.tracebacks module, and most notably the structlog.tracebacks.ExceptionDictTransformer which can be used with the new structlog.processors.ExceptionRenderer to render JSON tracebacks. #407
- structlog.stdlib.recreate_defaults(log_level=logging.NOTSET) that recreates structlog's defaults on top of standard library's logging. It optionally also configures logging to log to standard out at the passed log level. #428
- structlog.processors.EventRenamer allows you to rename the hitherto hard-coded event dict key event to something else. Optionally, you can rename another key to event at the same time, too. So adding EventRenamer(to="msg", replace_by="_event") to your processor pipeline will rename the standard event key to msg and then rename the _event key to event. This allows you to use the event key in your own log files and to have consistent log message keys across languages.
- structlog.dev.ConsoleRenderer(event_key="event") now allows to customize the name of the key that is used for the log message.
Changed
- structlog.make_filtering_bound_logger() now returns a method with the same signature for all log levels, whether they are active or not. This ensures that invalid calls to inactive log levels are caught immediately and don't explode once the log level changes. #401
- structlog.PrintLogger – that is used by default – now uses print() for printing, making it a better citizen for interactive terminal applications. #399
- structlog.testing.capture_logs now works for already initialized bound loggers. #408
- structlog.processors.format_exc_info() is no longer a function, but an instance of structlog.processors.ExceptionRenderer. Its behavior has not changed. #407
- The default configuration now includes the structlog.contextvars.merge_contextvars processor. That means you can use structlog.contextvars features without configuring structlog.
Fixed
- Overloaded the bind, unbind, try_unbind and new methods in the FilteringBoundLogger Protocol. This makes it easier to use objects of type FilteringBoundLogger in a typed context. #392
- Monkeypatched sys.stdouts are now handled more gracefully by ConsoleRenderer (that's used by default). #404
- structlog.stdlib.render_to_log_kwargs() now correctly handles the presence of exc_info, stack_info, and stackLevel in the event dictionary. They are transformed into proper keyword arguments instead of putting them into the extra dictionary. #424, #427