I am pleased to announce the release of SfePy 2021.1.
SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by finite element methods. It is
distributed under the new BSD license.
Home page: https://sfepy.org
Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/
Git (source) repository, issue tracker: https://github.com/sfepy/sfepy
Highlights of this release
- non-square homogenized coefficient matrices
- new implementation of multi-linear terms
- improved handling of Dirichlet and periodic boundary conditions in common
- terms in the term table document linked to examples
For full release notes see .
Contributors to this release in alphabetical order:
imphook is a simple, small single-file module and a tool which allows
to easily and selectively override Python import machinery for
particular file types (including Python source files).
As an example of usage, recently on the python-ideas mailing list,
there was a discussion about "arrow functions" for Python (as a
syntactic alternative to lambda). A prototype implementation using
"imphook" was posted:
The project is available from:
PyPI: https://pypi.org/project/imphook/ (package includes only the
Github: https://github.com/pfalcon/python-imphook (assorted usage
examples are included in the git repository)
Below is a documentation snapshot:
imphook - Simple and clear import hooks for Python
The ``imphook`` module allows to easily define per file type import
hooks, i.e. overload or extend import processing for particular file
types, without affecting processing of other file types, and at the
same time, while ensuring that new processing integrates as seamlessly
as possible with normal Python import rules.
Besides the Python-level API to install import hooks, the module also
provides command-line interface to run an existing Python script or
module with one or more import hooks preloaded (i.e. without modifying
existing script source code).
Some but not all things you can easily do using ``imphook`` (most
of these require additional modules to do the heavy lifting,
``imphook`` just allows to plug it seamlessly into the Python import
* Override importing of (all or some) .py files, to support new
syntax or semantics in them.
* Import files written using a DSL (domain-specific language)
as if they were Python modules. E.g., config or data files.
* Import modules written in other language(s), assuming you have
an interpreter(s) for them.
* Import binary files, e.g. Java or LLVM bytecode.
``imphook`` works both with new, lightweight legacy-free Python
API, as promoted by the `Pycopy <https://github.com/pfalcon/pycopy>`_
Python dialect (the original source of the "easy import hooks" idea),
and CPython (the older, reference Python implementation), and with
other Python implementations which are CPython-compatible.
Make sure that you already installed ``imphook`` using::
pip3 install -U imphook
Below is a complete example of an import hook module to load
``key = value`` style config files::
def hook(modname, filename):
with open(filename) as f:
# Create a module object which will be the result of import.
mod = type(imphook)(modname)
for l in f:
k, v = [x.strip() for x in l.split("=", 1)]
setattr(mod, k, v)
Save this as the ``mod_conf.py`` file, and add the two following
files to test it:
var1 = 123
var2 = hello
import example_settings as settings
python3 -m imphook -i mod_conf example_conf.py
As you can see, the ``example_conf.py`` is able to import
``example_settings.conf`` as if it were a normal Python module.
Besides copy-pasting the above and other examples, you can also
clone the Git repository of ``imphook``, which contains various
git clone https://github.com/pfalcon/python-imphook
API to install hooks and hook structure
The API of the module consists of one function:
`imphook.add_import_hook(hook, ext_tuple)`. *hook* is a name of
hook function. *ext_tuple* is a tuple of file extensions
the hook function should handle (the leading dot should be included).
More often than not, you will want to handle just one extension,
so don't forget to use the usual Python syntax with a trailing
comma for 1-element tuple, e.g.: ``(".ext",)``. Python modules may
not contain a dot (``"."``) in their names (they are used to separate
subpackages), so the extension you register may contain multiple
dots, e.g. ``".foo.bar"``, with filename ``my_module.foo.bar``
It is possible to call `imphook.add_import_hook(hook, ext_tuple)`
multiple times to install multiple hooks. The hooks are installed
in the stack-like fashion, the last installed will be called
first. It is possible to install multiple hooks for the same file
extension, and earlier installed hooks may still be called in this
case, because a hook function may skip processing a particular
file, and let other hooks to take a chance, with default processing
happening if no hook handled the import.
The signature and template of the actual hook function is::
def my_hook(modname, filename):
# Return None if you don't want to handle `filename`.
# Otherwise, load `filename`, create a Python module object,
# with name `modname`, populate it based on the loaded file
# contents, and return it.
The *modname* parameter is a full module name of the module to
import, in the usual dot-separated notation, e.g. ``my_module``
or ``pkg.subp.mod``. For relative imports originated from within
a package, this name is already resolved to full absolute name.
The *modname* should be used to create a module object with the
The *filename* parameter is a full pathname (with extension) of the
file which hook should import. This filename is known to exist, so
you may proceed to open it directly. You may skip processing this
file by returning ``None`` from the hook, then other hooks may be
tried, and default processing happens otherwise (e.g. ``.py`` files
are loaded as usual, or ImportError raised for non-standard
extensions). For package imports, the value of *filename* ends with
``/__init__.py``, and that is the way to distinguish module vs
If the hook proceeds with the file, it should load it by whatever
means suitable for the file type. File types which are not natively
supported by Python would require installing and using other extension
modules (beyond ``imphook``). After loading the file, the hook should
create an empty Python module object which will be the result of the
import. There are a few ways to do that:
* The baseline is to call a module type as a constructor. To get
a module type, just apply the usual ``type()`` function to an
existing (imported) module. You'll definitely have ``imphook``
itself imported, which leads us to::
mod = type(imphook)(modname)
The parameter to constructor is the name of module to create,
as passed to the hook.
* If the above looks too magic for you, you can import symbolic
name for module type from the ``types`` module::
from types import ModuleType
mod = ModuleType(modname)
* Finally, you may use the ``imp`` module, which may be as well
the clearest (to the newbie) way of doing it::
mod = imp.new_module(modname)
But mind that the ``imp`` module is considered deprecated.
Of the choices above, the first is the most efficient - no need
to import additional modules, and it's just one line. And once
you saw and were explained what it does, it shouldn't be a problem
to remember and recognize it later.
Once the module object is created as discussed above, you should
populate it. A way to do that is by using ``setattr()`` builtin
to set a particular attribute of a module to a particular value.
Attributes usually represent variables with data values, but
may be also functions and classes.
Finally, you just return the populated module object.
In case you want to perform custom transformation on the Python
source, the process is usually somewhat different, where you
transform a representation of the source, and then execute it
in the context of a new module, which causes it to be populated.
Using import hooks in your applications
There are 2 ways to use import hook(s) in you Python programs:
either preloading them before starting your program using ``imphook``
command-line runner (next section) or load them explicitly at the
startup of your application. Crucial thing to remember that import
hooks apply: a) for imports only; b) for imports appearing after
the hook was installed.
The main file of our application is normally *not imported*, but
executed directly. This leads to the following pattern in structuring
your application source files:
* Have a "startup file", which is the one which user will actually
run, so name it appropriately. In that file, you load import hooks
and perform other baseline system-level initialization.
* The main functionality of your application is contained in seperate
module(s). The startup script imports such a main module and
executes it (e.g., by calling a function from it).
You already grasped how that works - as the "main" module is
*imported*, whatever hooks the "startup" script installed, will
apply to it.
This pattern is actually officially encoded in the structure of
Python *packages*. And any non-trivial Python application will
likely be a package with a few sub-modules in it, so you can as
well structure your applications this way (as a package), even
if they start simple (only one submodule initially). So, if you
try to "run" a package, what actually gets run is ``__main__``
submodule in that package. That's exactly the "startup" file
we discussed above. It installs the import hooks, and imports
a submodule with actual application's functionality.
Credits and licensing
``imphook`` is (c) `Paul Sokolovsky <https://github.com/pfalcon>`_ and
is released under the MIT license.
Charles R Harris <charlesr.harris(a)gmail.com>
Sun, Feb 7, 2:23 PM
to numpy-discussion, SciPy, SciPy-User, bcc: python-announce-list
On behalf of the NumPy team I am pleased to announce the release of NumPy
1.20.2. NumPy 1,20.2 is a bugfix release containing several fixes merged to
the main branch after the NumPy 1.20.1 release. The Python versions
supported for this release are 3.7-3.9. Wheels can be downloaded from PyPI
<https://pypi.org/project/numpy/1.20.2/>; source archives, release notes,
and wheel hashes are available on Github
<https://github.com/numpy/numpy/releases/tag/v1.20.2>. Linux users will
need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014
A total of 7 people contributed to this release. People with a "+" by their
names contributed a patch for the first time.
- Allan Haldane
- Bas van Beek
- Charles Harris
- Christoph Gohlke
- Mateusz Sokół +
- Michael Lamparski
- Sebastian Berg
*Pull requests merged*
A total of 20 pull requests were merged for this release.
- #18382: MAINT: Update f2py from master.
- #18459: BUG: ``diagflat`` could overflow on windows or 32-bit platforms
- #18460: BUG: Fix refcount leak in f2py ``complex_double_from_pyobj``.
- #18461: BUG: Fix tiny memory leaks when ``like=`` overrides are used
- #18462: BUG: Remove temporary change of descr/flags in VOID functions
- #18469: BUG: Segfault in nditer buffer dealloc for Object arrays
- #18485: BUG: Remove suspicious type casting
- #18486: BUG: remove nonsensical comparison of pointer < 0
- #18487: BUG: verify pointer against NULL before using it
- #18488: BUG: check if PyArray_malloc succeeded
- #18546: BUG: incorrect error fallthrough in nditer
- #18559: CI: Backport CI fixes from main.
- #18599: MAINT: Add annotations for `dtype.__getitem__`, `__mul__`
- #18611: BUG: NameError in numpy.distutils.fcompiler.compaq
- #18612: BUG: Fixed ``where`` keyword for ``np.mean`` & ``np.var``
- #18617: CI: Update apt package list before Python install
- #18636: MAINT: Ensure that re-exported sub-modules are properly
- #18638: BUG: Fix ma coercion list-of-ma-arrays if they do not cast
- #18661: BUG: Fix small valgrind-found issues
- #18671: BUG: Fix small issues found with pytest-leaks
PyCA cryptography 3.4.7 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.
* Updated Windows, macOS, and manylinux wheels to be compiled with
-Paul Kehrer (reaperhulk)
This year's conference will mark the 20th edition of the EuroPython
* EuroPython 2021 *
Since we started touring Europe in 2002 in Charleroi, Belgium, we have
come a long way. The conference has grown from the initial 240 to around
1200-1400 attendees every year. The organization had started with a
small group of people in a somewhat ad-hoc way and has now grown into a
well structured team backed by the non-profit EuroPython Society (EPS),
while still keeping the fun spirit of the early days.
EuroPython 2002 was the first major all volunteer run event for Python.
A lot of other conferences have since emerged in Europe and we're
actively trying to help them wherever we can, with our grants program,
growing conference knowledge base and our Organizers' Lunch, for which
we regularly invite representatives of all European Python conferences
to get together to network, exchange experience in organizing events
community building and understand how we can most effectively help each
To celebrate the anniversary, we took a deep look into our archives and
have put together live website copies of the last few years, going back
all the way to EP2009, which was held in Birmingham, UK. For previous
years, archive.org stored some pages of the websites, so let's do a
quick tour of 20 years of EuroPython ...
Help spread the word
Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !
Link to the blog post:
EuroPython 2021 Team
On behalf of the SciPy development team I'm pleased to announce
the release of SciPy 1.6.2, which is a bug fix release.
Sources and binary wheels can be found at:
and at: https://github.com/scipy/scipy/releases/tag/v1.6.2
One of a few ways to install this release with pip:
pip install scipy==1.6.2
SciPy 1.6.2 Release Notes
SciPy 1.6.2 is a bug-fix release with no new features
compared to 1.6.1. This is also the first SciPy release
to place upper bounds on some dependencies to improve
the long-term repeatability of source builds.
* Pradipta Ghosh +
* Tyler Reddy
* Ralf Gommers
* Martin K. Scherer +
* Robert Uhl
* Warren Weckesser
A total of 6 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
Issues closed for 1.6.2
* `#13512 <https://github.com/scipy/scipy/issues/13512>`__:
\`stats.gaussian_kde.evaluate\` broken on S390X
* `#13584 <https://github.com/scipy/scipy/issues/13584>`__:
rotation._compute_euler_from_matrix() creates an array with negative...
* `#13585 <https://github.com/scipy/scipy/issues/13585>`__: Behavior change
in coo_matrix when dtype=None
* `#13686 <https://github.com/scipy/scipy/issues/13686>`__: delta0 argument
of scipy.odr.ODR() ignored
Pull requests for 1.6.2
* `#12862 <https://github.com/scipy/scipy/pull/12862>`__: REL: put upper
bounds on versions of dependencies
* `#13575 <https://github.com/scipy/scipy/pull/13575>`__: BUG: fix
\`gaussian_kernel_estimate\` on S390X
* `#13586 <https://github.com/scipy/scipy/pull/13586>`__: BUG: sparse:
Create a utility function \`getdata\`
* `#13598 <https://github.com/scipy/scipy/pull/13598>`__: MAINT, BUG:
enforce contiguous layout for output array in Rotation.as_euler
* `#13687 <https://github.com/scipy/scipy/pull/13687>`__: BUG: fix
scipy.odr to consider given delta0 argument
PyWeek is a twice-a-year game jam that has been running for the past 15 years. Starting on the first day of the jam (Sunday, March 28), you start coding, designing, and developing your game. This can be done as an individual or with a team. By Sunday, April 3rd you must submit your entry on the PyWeek website (pyweek.org) for it to be counted as a valid submission.
You can register on PyWeek.org. Head over to that webpage, click on the "Latest Challenge", and you should see an option to "Register an Entry". If you register now you can vote for what the theme of the game jam will be. Last's PyWeek had the theme of "Castaway."
If you have any questions, want to chat with other people participating, or find people to join a team, come hang out on Python Discord (https://discord.gg/python)! Feel free to tag me, Janine (kutiekatj9), if you have any questions in the server or feel free to just send me an email.
竜 TatSu is a tool that takes grammars in a variation of EBNF as input, and
outputs memoizing (Packrat) PEG parsers in Python.
竜 TatSu inspired the PEG parser in Python 3.9.
New in 竜 TatSu 5.6.0
* Several important refactorings in ``contexts.ParseContext``
* Make ``ignorecase`` settings apply to defined ``@@keywords``
* Move checking of keywords used as names into ``ParseContext``
* Output of generated parsers again matches that of model parsers
* Improve *"expecting one of:"* messages so elements are in declaration
* Stop code generation if there are closures over possibly empty
* Preserve name declaration order in returned ``AST``
* Update the bootstrap parser (``tatsu/bootstrap.py``) to the generated
* Now generated parser's ``main()`` only outputs the JSON for the parse
* Minor version bumped in case the many fixes break
* Minor documentation issues fixed
* All tests run with Python 3.8, 3.9, 3.10
I’m happy to announce the v2.6.0 release of django-minio-backend!
django-minio-backend provides a wrapper around the official MinIO Python SDK enabling easy integration with MinIO for Django developers.
You can learn more about MinIO the S3-compatible object storage here: https://min.io
• New manage.py command: is_minio_available
• Updated minIO SDK from 7.0.0 to 7.0.2
• updated imports
• updated self.client.list_objects_v2 to self.client.list_objects
• Added get_available_name function override for django.core.files.storage.Storage to respect file override requests
• Improved overall documentation
• Added Django unit tests with Docker
• Improved the reference implementations in the DjangoExampleApplication folder
• Added GitHub Actions configuration
See django-minio-backend at GitHub: https://github.com/theriverman/django-minio-backend
See MinIO Python SDK here at GitHub: https://github.com/minio/minio-py
You can install this version by executing the following command:
python -m pip install django-minio-backend==2.6.0