I'm pleased to announce the availability of wxGlade revision 1.0.1
Please download from https://sourceforge.net/projects/wxglade/files/wxglade/1.0.1/
wxGlade is a GUI builder for wxWidgets and wxPython.
The documentation includes a tutorial for people who have not used wxPython
Included are also examples for integration with matplotlib.
A snapshot of the documentation is available at http://wxglade.sourceforge.net/docs/index.html
For support, there's a mailing list at https://sourceforge.net/p/wxglade/mailman/wxglade-general/
git repository and bug tracker are at https://github.com/wxGlade/wxGlade
(These pages are also linked from the help menu.)
Changes in revision 1.0.x:
Besides many improvements in usability, code generation and widget support,
this is also a major internal refactoring of the main data structure and how
widgets in the Design window are created / updated / destroyed.
- sizers only required where wx requires them; not required e.g. for
Frame->Panel (used to be Frame->Sizer->Panel)
- better handling of display updates when properties are edited
- accessibility and usability improvements
- Dialog example
- documentation update
- all: separate class related properties into Class / Base Classes /
- Dialog: add StdDialogButtonSizer and standard buttons (stock items);
support SetAffirmativeId, SetEscapeId
- Button: support for image direction
- MenuBar: support lambda event handlers
- GridBagSizer: indicate overlapped slots in the Tree view
- no separation into __set_properties/__do_layout any more
- support for instantiation classes
- internal structures refactored
- add shell window and Tree Printer
wxGlade is released under the MIT license.
Happy New Year,
<P><A HREF="https://sourceforge.net/projects/wxglade/files/wxglade/1.0.1/">wxGlade 1.0.1</A> - GUI builder for wxPython (31-Dec-20)
unicode is a simple python command line utility that displays
properties for a given unicode character, or searches
unicode database for a given name.
It was written with Linux in mind, but should work almost everywhere
(including MS Windows and MacOSX), UTF-8 console is recommended.
˙pɹɐpuɐʇs əpoɔı̣uՈ əɥʇ ɟo əsn pəɔuɐʌpɐ
puɐ səldı̣ɔuı̣ɹd əɥʇ ɓuı̣ʇɐɹʇsuoɯəp looʇ ɔı̣ʇɔɐpı̣p ʇuəlləɔxə uɐ sı̣ ʇI
˙sʇuı̣odəpoɔ ʇuəɹəɟɟı̣p ʎləʇəldɯoɔ ɓuı̣sn əlı̣ɥʍ 'sɥdʎlɓ ɟo ɯɐəɹʇs ɹɐlı̣ɯı̣s
ʎllɐnsı̣ʌ oʇuı̣ ʇxəʇ əɥʇ ʇɹəʌuoɔ oʇ pɹɐpuɐʇs əpoɔı̣uՈ əɥʇ ɟo ɹəʍod llnɟ
əɥʇ sʇı̣oldxə ʇɐɥʇ 'ʎʇı̣lı̣ʇn ,əpoɔɐɹɐd, oslɐ suı̣ɐʇuoɔ əɓɐʞɔɐd əɥ⊥
Changes since previous versions:
* display ASCII table (either traditional with --ascii or the new
EU–UK Trade and Cooperation Agreement version with --brexit-ascii)
* minor bug fixes
License: GPL v3
Installation: pip install unicode
| Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__ garabik @ kassiopeia.juls.savba.sk |
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Announcing NumExpr 2.7.2
It's been awhile since the last update to NumExpr, mostly as the existing
Python tool chain for building wheels on PyPi became defunct and we have
redevelop a new one based on `cibuildwheel` and GitHub Actions. This
brings us support (and wheels for) Python 3.9.
There have been a number of changes to enhance how NumExpr works when NumPy
uses MKL as a backend.
Project documentation is available at:
Changes from 2.7.1 to 2.7.2
- Support for Python 2.7 and 3.5 is deprecated and will be discontinued
`cibuildwheels` and/or GitHub Actions no longer support these versions.
- Wheels are now provided for Python 3.7, 3.5, 3.6, 3.7, 3.8, and 3.9 via
- The block size is now exported into the namespace as
as a read-only value.
- If using MKL, the number of threads for VML is no longer forced to 1 on
the module. Testing has shown that VML never runs in multi-threaded mode
the default BLOCKSIZE1 of 1024 elements, and forcing to 1 can have
effects on NumPy functions when built with MKL. See issue #355 for
- Use of `ndarray.tostring()` in tests has been switch to
for future-proofing deprecation of `.tostring()`, if the version of NumPy
greater than 1.9.
- Added a utility method `get_num_threads` that returns the (maximum)
threads currently in use by the virtual machine. The functionality of
`set_num_threads` whereby it returns the previous value has been
and will be removed in 2.8.X.
Numexpr is a fast numerical expression evaluator for NumPy. With it,
expressions that operate on arrays (like "3*a+4*b") are accelerated
and use less memory than doing the same calculation in Python.
It has multi-threaded capabilities, as well as support for Intel's
MKL (Math Kernel Library), which allows an extremely fast evaluation
of transcendental functions (sin, cos, tan, exp, log...) while
squeezing the last drop of performance out of your multi-core
processors. Look here for a some benchmarks of numexpr using MKL:
Its only dependency is NumPy (MKL is optional), so it works well as an
easy-to-deploy, easy-to-use, computational engine for projects that
don't want to adopt other solutions requiring more heavy dependencies.
Where I can find Numexpr?
The project is hosted at GitHub in:
You can get the packages from PyPI as well (but not for RC releases):
Documentation is hosted at:
Share your experience
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
I am pleased to announce the release of SfePy 2020.4.
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
- Ogden hyperelastic term
- serendipity finite element basis of orders 1-3
For full release notes see .
Contributors to this release in alphabetical order:
On behalf of the NumPy team I am pleased to announce the release of NumPy
1.20.0rc2. This NumPy release is the largest to date, containing some 670
merged pull requests contributed by 184 people. See the list of highlights
below. The Python versions supported for this release are 3.7-3.9, support
for Python 3.6 has been dropped. Wheels can be downloaded from PyPI
<https://pypi.org/project/numpy/1.20.0rc2/>; source archives, release
notes, and wheel hashes are available on Github
<https://github.com/numpy/numpy/releases/tag/v1.20.0rc2>. Linux users will
need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014
- Annotations for NumPy functions. This work is ongoing and improvements
can be expected pending feedback from users.
- Wider use of SIMD to increase execution speed of ufuncs. Much work has
been done in introducing universal functions that will ease use of modern
features across different hardware platforms. This work is ongoing.
- Preliminary work in changing the dtype and casting implementations in
order to provide an easier path to extending dtypes. This work is ongoing
but enough has been done to allow experimentation and feedback.
- Extensive documentation improvements comprising some 185 PR merges.
This work is ongoing and part of the larger project to improve NumPy's
online presence and usefulness to new users.
- Further cleanups related to removing Python 2.7. This improves code
readability and removes technical debt.
- Preliminary support for the upcoming Cython 3.0.
A total of 184 people contributed to this release. People with a "+" by
names contributed a patch for the first time.
* Aaron Meurer +
* Abhilash Barigidad +
* Abhinav Reddy +
* Abhishek Singh +
* Al-Baraa El-Hag +
* Albert Villanova del Moral +
* Alex Leontiev +
* Alex Rockhill +
* Alex Rogozhnikov
* Alexander Belopolsky
* Alexander Kuhn-Regnier +
* Allen Downey +
* Andras Deak
* Andrea Olivo +
* Andrew Eckart +
* Anirudh Subramanian
* Anthony Byuraev +
* Antonio Larrosa +
* Ashutosh Singh +
* Bangcheng Yang +
* Bas van Beek +
* Ben Derrett +
* Ben Elliston +
* Ben Nathanson +
* Bernie Gray +
* Bharat Medasani +
* Bharat Raghunathan
* Bijesh Mohan +
* Bradley Dice +
* Brandon David +
* Brandt Bucher
* Brian Soto +
* Brigitta Sipocz
* Cameron Blocker +
* Carl Leake +
* Charles Harris
* Chris Brown +
* Chris Vavaliaris +
* Christoph Gohlke
* Chunlin Fang
* CloseChoice +
* Daniel G. A. Smith +
* Daniel Hrisca
* Daniel Vanzo +
* David Pitchford +
* Davide Dal Bosco +
* Derek Homeier
* Dima Kogan +
* Dmitry Kutlenkov +
* Douglas Fenstermacher +
* Dustin Spicuzza +
* E. Madison Bray +
* Elia Franzella +
* Enrique Matías Sánchez +
* Erfan Nariman | Veneficus +
* Eric Larson
* Eric Moore
* Eric Wieser
* Erik M. Bray
* EthanCJ-git +
* Etienne Guesnet +
* FX Coudert +
* Felix Divo
* Frankie Robertson +
* Ganesh Kathiresan
* Gengxin Xie
* Gerry Manoim +
* Guilherme Leobas
* Hassan Kibirige
* Hugo Mendes +
* Hugo van Kemenade
* Ian Thomas +
* InessaPawson +
* Isabela Presedo-Floyd +
* Isuru Fernando
* Jakob Jakobson +
* Jakub Wilk
* James Myatt +
* Jesse Li +
* John Hagen +
* John Zwinck
* Joseph Fox-Rabinovitz
* Josh Wilson
* Jovial Joe Jayarson +
* Julia Signell +
* Jun Kudo +
* Karan Dhir +
* Kaspar Thommen +
* Kerem Hallaç
* Kevin Moore +
* Kevin Sheppard
* Klaus Zimmermann +
* LSchroefl +
* Laurie +
* Laurie Stephey +
* Levi Stovall +
* Lisa Schwetlick +
* Lukas Geiger +
* Madhulika Jain Chambers +
* Matthias Bussonnier
* Matti Picus
* Melissa Weber Mendonça
* Michael Hirsch
* Nick R. Papior
* Nikola Forró
* Noman Arshad +
* Paul YS Lee +
* Pauli Virtanen
* Paweł Redzyński +
* Peter Andreas Entschev
* Peter Bell
* Philippe Ombredanne +
* Phoenix Meadowlark +
* Piotr Gaiński
* Raghav Khanna +
* Raghuveer Devulapalli
* Rajas Rade +
* Rakesh Vasudevan
* Ralf Gommers
* Raphael Kruse +
* Rashmi K A +
* Robert Kern
* Rohit Sanjay +
* Roman Yurchak
* Ross Barnowski
* Royston E Tauro +
* Ryan C Cooper +
* Ryan Soklaski
* Safouane Chergui +
* Sahil Siddiq +
* Sarthak Vineet Kumar +
* Sayed Adel
* Sebastian Berg
* Sergei Vorfolomeev +
* Seth Troisi
* Sidhant Bansal +
* Simon Gasse
* Simon Graham +
* Stefan Appelhoff +
* Stefan Behnel +
* Stefan van der Walt
* Steve Dower
* Steve Joachim +
* Steven Pitman +
* Stuart Archibald
* Sturla Molden
* Susan Chang +
* Takanori H +
* Tapajyoti Bose +
* Thomas A Caswell
* Tina Oberoi
* Tirth Patel
* Tobias Pitters +
* Tomoki, Karatsu +
* Tyler Reddy
* Veniamin Petrenko +
* Wansoo Kim +
* Warren Weckesser
* Wei Yang +
* Wojciech Rzadkowski
* Yang Hau +
* Yogesh Raisinghani +
* Yu Feng
* Yuya Unno +
* Zac Hatfield-Dodds
* Zuhair Ali-Khan +
* @abhilash42 +
* @danbeibei +
* @dpitch40 +
* @forfun +
* @iamsoto +
* @jbrockmendel +
* @leeyspaul +
* @mitch +
* @prateek arora +
* @serge-sans-paille +
* @skywalker +
* @stphnlyd +
* @谭九鼎 +
* @JMFT +
* @Jack +
* @Neal C +
pyastinterp is a tree-walking (aka meta-circular) interpreter for
Python. It was the most complete tree-walking interpreter as of a year
ago. As it was written as a personal "advent of code" project during
the winter holidays of 2019/2020.
I remembered about it this holiday season, and decided to post about
it, both as a holiday eyecandy, and as a challenge to other Python
hackers (such winter holidays challenges are known as "advent of
code" (of course, unless you believe there's only one of them)): can you
write a more complete implementation? Or maybe you did during this
year? Please post about it somewhere (perhaps, python-ideas mailing
README with more details follows:
This is an AST interpreter (also known as tree-walking interpreter) for
the Python programming language, written in Python itself. It is thus
a meta-circular interpreter. While Python implementations of a Python VM
(i.e. bytecode interpreters) are relatively well known (starting with
PyPy), AST interpreters are much less common beyond those which implement
a very limited subset of the syntax.
Pyastinterp strives to fulfil 2 goals:
1. Be as complete as possible (and see how much effort that takes and
if there're any limits).
2. Yet be as minimal as possible, avoiding useless boilerplate and
reimplementing what may be already available.
First goal is pretty obvious: ideally, we'd like Pyastinterp to be able
to interpret (run) any application a native Python interpreter can.
Second goal is rooted in many reasons. To start with, Pyastinterp is
a spiritual part of the [Pycopy](https://github.com/pfalcon/pycopy)
project, whose goal is the development of minimalist Python-compatible
ecosystem. Besides, "bloated" meta-circular interpreters are well out
there (the same PyPy) - there's lack on the opposite side of spectrum.
Pyastinterp is also intended to be a "teaching" and "for-research"
project. Surely, it's much easier to learn and reuse/repurpose a small,
rather than large, project. These last requirements however also put
bounds on "minimality": `pyastinterp` tries to have a clear focus
(AST interpretation) and avoid unneeded boilerplate, but not be
obfuscated, and actually tries to be clear and easily hackable (provide
some reusable infrastructure), even at the expense of somewhat less
To achieve the goals of minimality, `pyastinterp` does following:
1. Is concerned with syntax, not semantics (largely).
2. That means that it tries to interpret Python AST tree, but
relies on the underlying Python runtime to implement the actual
operations (semantics). In some cases `pyastinterp` actually
has to deal with runtime semantics, but the point is that it
should be done only when there's no other choice (i.e. rarely).
3. This in particular means that `pyastinterp` itself requires a
(pretty) full Python implementation to run, it's not the case
that it's written in "some subset of Python". (Contrast that
with e.g. PyPy's RPython, which is a Python subset language,
in which interpreters are written).
4. Another consequence is that there's no semantic separation
between "metalevel" (level of the interpreter) and target
application level. This is again unlike PyPy, where 2 are explicitly
separated. Lack of separation allows to save on "marshalling"
values between the 2 levels, but also make it possible to have
"leaks" between levels, e.g. unexpected and unhandled exception
in the interpreter to be delivered to the application, causing
havoc and confusion. Pyastinterp's response to this concern
is a pledge that there shouldn't be such unhandled interpreter-level
exceptions. Of course, catching all such cases may take quite
a lot of testing and debugging, and fixing them may affect code
minimality and clarity. We'll see how it goes.
5. However, due to choices described above, implementation of many
syntactic constructs is very clear, concise, and isomorphic
between the target and meta levels. See e.g. how "if" statement
is implemented: the implementation looks almost exactly how the
usage of the "if" statement is.
Supported Python subset
Pyastinterp should implement almost all Python3.5 features, stopping
at generators, which are not that easy to implement in a tree-walking
interpreter. It also does not include import hook, so the imported
modules are interpreted by the underlying Python VM, not by
Quick way to run something interesting:
python3 -m astinterp pystone.my 10000
You can pass any other script on the command line and see how it goes.
Credits and licensing
Pyastinterp is (c) [Paul Sokolovsky](https://github.com/pfalcon) and
is released under the MIT license.
I am pleased to announce the availability of a new backwards compatible
feature in the "baseline" package (releases 1.2.0). This release includes
support for Python 3.9 and removal of support for Python 3.4 and 3.5.
This tool facilitates streamlining the creation and maintenance of tests
which compare string
output against a baseline. It offers a mechanism to compare a string against
a baselined copy and update the baselined copy to match the new value when a
mismatch occurs. The update process includes a manual step to facilitate a
review of the change before acceptance. The tool uses multi-line string
for string baselines to improve readability for human review.
(dan.gass at gmail)
+ Add ``--force`` command line option to suppress acknowledgement
+ Add Python 3.9 support advertisement. (Regression testing
added to the release process.)
+ Remove Python 3.4 and 3.5 support advertisement. (Regression testing
removed from release process.) Nothing blocks installation, but no
promise exists that the package works with those interpreter versions.
Python 3.8.7 is the seventh maintenance release of Python 3.8. Go get it here:
Note: this is a bugfix release for the 3.8 series which was superseded by Python 3.9, currently the latest feature release series of Python 3. You can find the latest release of 3.9.x here <https://www.python.org/downloads/>.
Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.8 planned for February 2021.
macOS 11 Big Sur not fully supported
Python 3.8.7 is not yet fully supported on macOS 11 Big Sur. It will install on macOS 11 Big Sur and will run on Apple Silicon Macs using Rosetta 2 translation. However, a few features do not work correctly, most noticeably those involving searching for system libraries (vs user libraries) such as ctypes.util.find_library() and in Distutils. This limitation affects both Apple Silicon and Intel processors. We are looking into improving the situation for Python 3.8.8.
Python 3.9.1 <https://www.python.org/downloads/release/python-391/> provides full support for Big Sur and Apple Silicon Macs, including building natively on Apple Silicon Macs and support for universal2 binaries.
The Python 3.8 series contains many new features and optimizations over 3.7. 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 version 3.8.7 specifically can be found in its change log <https://docs.python.org/release/3.8.7/whatsnew/changelog.html#python-3-8-7>. Note that compared to 3.8.6 this release also contains all changes present in 3.8.7rc1.
We hope you enjoy Python 3.8!
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.
Your friendly release team,
Ned Deily @nad <https://discuss.python.org/u/nad>
Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>
Łukasz Langa @ambv <https://discuss.python.org/u/ambv>