Hi!
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
before.
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.
*General:*
- 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
*Widgets:*
- all: separate class related properties into Class / Base Classes /
Instance Class
- 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
*Generated Code:*
- no separation into __set_properties/__do_layout any more
- support for instantiation classes
*Internal:*
- internal structures refactored
- add shell window and Tree Printer
wxGlade is released under the MIT license.
Happy New Year,
Dietmar Schwertberger
dietmar(a)schwertberger.de
<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)
Hi All
On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.2. NumPy 2.0.2 is a maintenance release that fixes bugs and regressions
discovered after the 2.0.1 release. This release supports Python 3.9-3.12.
Wheels can be downloaded from PyPI
<https://pypi.org/project/numpy/2.0.2>; source
archives, release notes, and wheel hashes are available on Github
<https://github.com/numpy/numpy/releases/tag/v2.0.2>.
*Contributors*
A total of 13 people contributed to this release. People with a "+" by
their
names contributed a patch for the first time.
- Bruno Oliveira +
- Charles Harris
- Chris Sidebottom
- Christian Heimes +
- Christopher Sidebottom
- Mateusz Sokół
- Matti Picus
- Nathan Goldbaum
- Pieter Eendebak
- Raghuveer Devulapalli
- Ralf Gommers
- Sebastian Berg
- Yair Chuchem +
*Pull requests merged*
A total of 19 pull requests were merged for this release.
- #27000: REL: Prepare for the NumPy 2.0.1 release [wheel build]
- #27001: MAINT: prepare 2.0.x for further development
- #27021: BUG: cfuncs.py: fix crash when sys.stderr is not available
- #27022: DOC: Fix migration note for ``alltrue`` and ``sometrue``
- #27061: BUG: use proper input and output descriptor in
array_assign_subscript...
- #27073: BUG: Mirror VQSORT_ENABLED logic in Quicksort
- #27074: BUG: Bump Highway to latest master
- #27077: BUG: Off by one in memory overlap check
- #27122: BUG: Use the new ``npyv_loadable_stride_`` functions for ldexp
and...
- #27126: BUG: Bump Highway to latest
- #27128: BUG: add missing error handling in public_dtype_api.c
- #27129: BUG: fix another cast setup in array_assign_subscript
- #27130: BUG: Fix building NumPy in FIPS mode
- #27131: BLD: update vendored Meson for cross-compilation patches
- #27146: MAINT: Scipy openblas 0.3.27.44.4
- #27151: BUG: Do not accidentally store dtype metadata in ``np.save``
- #27195: REV: Revert undef I and document it
- #27213: BUG: Fix NPY_RAVEL_AXIS on backwards compatible NumPy 2 builds
- #27279: BUG: Fix array_equal for numeric and non-numeric scalar types
Cheers,
Charles Harris
iPOPO v3.0.0 has been released!
What is iPOPO ?
=============
iPOPO is a Python-based Service-Oriented Component Model (SOCM) based on
Pelix, a dynamic service platform. They are inspired by two popular Java
technologies for the development of long-lived applications: the iPOJO
component model and the OSGi Service Platform.
iPOPO enables the development of long-running and modular IT services.
It is based on OSGi concepts:
- Bundle: a Python module imported using Pelix and associated to a
context. A bundle has a life-cycle (install, start, updated, stop,
uninstall)
- Service: a Python object registered in a service registry, associated
to a specification and to properties.
- Component: the instance of a class described/manipulated by iPOPO
decorators
Components are bound together by the specification(s) of the service(s)
they provide. The required services are injected into components by iPOPO.
For more information, see https://ipopo.readthedocs.io/
iPOPO is released under the terms of Apache Software License 2.0
What's new in 3.0.0
================
* Dropped support for Python 2.7 and versions earlier than 3.10, it's time
to move on
* Kept compatibility with iPOPO 1.0 on API level: it is possible to link
iPOPO v1 and v3 via Remote Services
* Added type hints where possible
* Pelix and iPOPO now support types in specifications
* Documentation updates
* Moved from Travis-CI to GitHub actions to test project against Python
3.10, 3.11 and 3.12
You can take a look at the documentation at https://ipopo.readthedocs.io/
iPOPO is available on PyPI: https://pypi.org/project/iPOPO/
Source is available on GitHub: https://github.com/tcalmant/ipopo
Feel free to send feedback on your experience of Pelix/iPOPO, via the
mailing lists:
* Users list: https://groups.google.com/g/ipopo-users
* Developers list: https://groups.google.com/g/ipopo-dev
* GitHub discussions: https://github.com/tcalmant/ipopo/discussions
Have fun!
What is python-oracledb?
python-oracledb is a Python extension module that enables access to Oracle
Database for Python and conforms to the Python database API 2.0 specifications
with a number of enhancements. This module replaces cx_Oracle.
Where do I get it?
https://pypi.org/project/oracledb/2.4.0/
The easiest method to install/upgrade python-oracledb is via pip as in
python -m pip install oracledb --upgrade
What's new?
This release adds support for Oracle Database 23ai pipelining and corrects
a number of reported bugs.
See the full release notes for all of the details:
https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracled…
Please provide any feedback via GitHub issues: https://github.com/oracle/
python-oracledb/issues or discussions: https://github.com/oracle/python-
oracledb/discussions
ReplyReply allForward
Add reaction
Hi All
On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.1.0. NumPy 2.1.0 provides support for the upcoming Python 3.13 release
and drops support for Python 3.9. In addition to the usual bug fixes and
updated Python support, this release helps get NumPy back into its usual
release cycle after the extended development of 2.0. Some 469 pull
requests were merged for this release, highlights are:
- Support for the array-api 2023.12 standard.
- Support for Python 3.13.
- Preliminary support for free threaded Python 3.13
This release supports Python 3.10-3.13. Wheels can be downloaded from PyPI
<https://pypi.org/project/numpy/2.1.0>; source archives, release notes, and
wheel hashes are available on Github
<https://github.com/numpy/numpy/releases/tag/v2.1.0>.
*Contributors*
A total of 110 people contributed to this release. People with a "+" by
their names contributed a patch for the first time.
- !ogidig5 +
- !partev
- !vahidmech +
- !h-vetinari
- Aaron Meurer
- Adrin Jalali +
- Agriya Khetarpal
- Ajay Kumar Janapareddi +
- Alex Herbert +
- Andras Deak
- Andrej Zhilenkov +
- Andrew Nelson
- Anne Gunn +
- Antony Lee
- Arnaud Ma +
- Arun Kannawadi +
- Arun Pa +
- Bas van Beek
- Ben Woodruff +
- Bruno Oliveira +
- Carlos Henrique Hermanny Moreira da Silva +
- Charles Harris
- Chris Sidebottom
- Christian Heimes +
- Christian Lorentzen
- Christopher Sidebottom
- Christopher Titchen +
- Clément Robert
- Cobalt Yang +
- Devyani Chavan +
- Dimitri Papadopoulos Orfanos
- Ebigide Jude +
- Eric Xie +
- Evgeni Burovski
- Fabian Vogt +
- Francisco Sousa +
- GUAN MING +
- Gabriel Fougeron +
- Gagandeep Singh
- Giovanni Del Monte +
- Gonzalo Tornaría +
- Gonçalo Bárias +
- Hugo van Kemenade
- Jakob Stevens Haas +
- Jakob Unfried +
- James Joseph Thomas +
- Jean Lecordier +
- Joren Hammudoglu +
- Joris Van den Bossche
- Julia Poo +
- Justus Magin
- Jyn Spring 琴春
- KIU Shueng Chuan
- Karthik Gangula +
- Karthik Kaiplody +
- Kevin Sheppard
- Kristoffer Pedersen +
- Leo Singer
- Liang Yan
- Liangyu Zhang +
- Lucas Colley
- Luiz Eduardo Amaral +
- Lysandros Nikolaou
- Marcel Loose +
- Marten van Kerkwijk
- Mateusz Sokół
- Matt Haberland
- Matt Thompson +
- Matthew Roeschke +
- Matthew Thompson +
- Matthias Bussonnier
- Matti Picus
- Melissa Weber Mendonça
- Milica Dančuk +
- Moritz Schreiber +
- Nathan Goldbaum
- Olivier Grisel
- Patrick J. Roddy +
- Paul Juma Otieno +
- Pieter Eendebak
- Raghuveer Devulapalli
- Ralf Gommers
- Raquel Braunschweig +
- Robert Kern
- Rohit Goswami
- Romain Geissler +
- Ross Barnowski
- Rostan Tabet +
- Sam Morley +
- Sayed Adel
- Sean Cheah
- Sebastian Berg
- Serge Guelton
- Slobodan +
- Stefan van der Walt
- Thomas A Caswell
- Thomas Li
- Timo Röhling +
- Tsvika Shapira +
- Tuhin Sharma +
- Tyler Reddy
- Victor Eijkhout +
- Warren Weckesser
- Warrick Ball
- Xiangyi Wang +
- Yair Chuchem +
- Yang Liu +
- Yannik Wicke +
- Yevhen Amelin +
- Yuki K
Cheers,
Charles Harris
Hi All
On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.1.0rc1. NumPy 2.1.0rc1 provides support for the upcoming Python 3.13
release and drops support for Python 3.9. In addition to the usual bug
fixes and updated Python support, it helps get us back into our usual
release cycle after the extended development of 2.0. Some 455 pull
requests were merged for this release, highlights are:
- Support for the array-api 2023.12 standard.
- Support for Python 3.13.
- Preliminary support for free threaded Python 3.13
This release supports Python 3.10-3.13. Wheels can be downloaded from PyPI
<https://pypi.org/project/numpy/2.1.0rc1>; source archives, release notes,
and wheel hashes are available on Github
<https://github.com/numpy/numpy/releases/tag/v2.1.0rc1>.
*Contributors*
A total of 110 people contributed to this release. People with a "+" by
their names contributed a patch for the first time.
- !ogidig5 +
- !partev
- !vahidmech +
- Aaron Meurer
- Adrin Jalali +
- Agriya Khetarpal
- Ajay Kumar Janapareddi +
- Alex Herbert +
- Andras Deak
- Andrej Zhilenkov +
- Andrew Nelson
- Anne Gunn +
- Antony Lee
- Arnaud Ma +
- Arun Kannawadi +
- Arun Pa +
- Bas van Beek
- Ben Woodruff +
- Bruno Oliveira +
- Carlos Henrique Hermanny Moreira da Silva +
- Charles Harris
- Chris Sidebottom
- Christian Heimes +
- Christian Lorentzen
- Christopher Sidebottom
- Christopher Titchen +
- Clément Robert
- Cobalt Yang +
- Devyani Chavan +
- Dimitri Papadopoulos Orfanos
- Ebigide Jude +
- Eric Xie +
- Evgeni Burovski
- Fabian Vogt +
- Francisco Sousa +
- GUAN MING +
- Gabriel Fougeron +
- Gagandeep Singh
- Giovanni Del Monte +
- Gonzalo Tornaría +
- Gonçalo Bárias +
- Hugo van Kemenade
- Jakob Stevens Haas +
- Jakob Unfried +
- James Joseph Thomas +
- Jean Lecordier +
- Joren Hammudoglu +
- Joris Van den Bossche
- Julia Poo +
- Justus Magin
- Jyn Spring 琴春
- KIU Shueng Chuan
- Karthik Gangula +
- Karthik Kaiplody +
- Kevin Sheppard
- Kristoffer Pedersen +
- Leo Singer
- Liang Yan
- Liangyu Zhang +
- Lucas Colley
- Luiz Eduardo Amaral +
- Lysandros Nikolaou
- Marcel Loose +
- Marten van Kerkwijk
- Mateusz Sokół
- Matt Haberland
- Matt Thompson +
- Matthew Roeschke +
- Matthew Thompson +
- Matthias Bussonnier
- Matti Picus
- Melissa Weber Mendonça
- Milica Dančuk +
- Moritz Schreiber +
- Nathan Goldbaum
- Olivier Grisel
- Patrick J. Roddy +
- Paul Juma Otieno +
- Pieter Eendebak
- Raghuveer Devulapalli
- Ralf Gommers
- Raquel Braunschweig +
- Robert Kern
- Rohit Goswami
- Romain Geissler +
- Ross Barnowski
- Rostan Tabet +
- Sam Morley +
- Sayed Adel
- Sean Cheah
- Sebastian Berg
- Serge Guelton
- Slobodan +
- Stefan van der Walt
- Thomas A Caswell
- Thomas Li
- Timo Röhling +
- Tsvika Shapira +
- Tuhin Sharma +
- Tyler Reddy
- Victor Eijkhout +
- Warren Weckesser
- Warrick Ball
- Xiangyi Wang +
- Yair Chuchem +
- Yang Liu +
- Yannik Wicke +
- Yevhen Amelin +
- Yuki K
Cheers,
Charles Harris
Hello everybody,
this is my first time writing in this section and I hope I’m not out of place.
I wanted to propose a new PEP that describes the APIs that a NOSQL database library should have, as I am going to describe below.
These types of databases are spreading very quickly and I believe it is necessary to have common interfaces between libraries. In fact, all four types of NOSQL databases have similarities on the most common operations (CRUD operation) and on database level operations.
This approach has already been defined for SQL databases in this PEP 249 . The python libraries that follow this PEP are many and have the same interfaces for objects, methods and functions.
Many python SQL libraries follow PEP 249, using functions, methods and properties with the nomenclature mentioned therein.
This leads to a much easier development and use consistency of these libraries.
I wanted to create a similar thing for NOSQL databases although there are many differences between the four types of databases, grouping them into four categories:
Column database, such as Apache Cassandra
Key/Value database, such as Redis
Document database, such as MongoDB
Graph database, such as Neo4j
These four types of databases have different characteristics on how data are requested and how they are inserted but they also have some common peculiarities.
On this assumption I have created a library of interfaces which should represent these common characteristics. I have also written a series of tests to simulate the behavior of existing libraries by encapsulating their methods in interfaces.
nosqlapi is an interface/ORM/utility library that is used to write, in turn, python libraries for NOSQL databases, so that they reflect the characteristics of the interfaces and therefore, of the API.
In this documentation you will find in detail what I will briefly explain below.
Abstract
The PEP introduces the API which describes the interfaces and the names of classes, methods, properties and functions that a NOSQL python library should have.
The API covers all four types of NOSQL databases. The PEP will also provide extended APIs for the unique peculiarities of each database type.
The goal of the API is simplicity and ease of use.
Motivation
The libraries that exist today concerning NOSQL databases are inconsistent in names. For example, it is easy to find objects dealing with database connections called Database, DatabaseConn and again DBClient. These objects produce the same result: an object that allows you to work directly with the database and its data.
These objects are instantiated with the same arguments, but different in names. Some use host for the server name, others use hostname other servers. Same thing for the other arguments.
Furthermore, there is no clear distinction between the database layer and the data layer, as is the case for SQL databases.
It is therefore necessary for consistency and ease of development and use, to have APIs that allow you to unify all this.
Furthermore, instantiating an object that deals at the database level and one at the data level allows for a very clear separation of duties.
For this the API will provide a Connection object which will take care of the database level operations, and a Session which will take care of the data instead.
Rationale
Separating tasks into two different objects has the advantage of isolating programming and execution errors.
Another advantage is that a user connecting to a database may not have permissions to work directly on the data. With this separation it is possible to isolate some information to authorized users.
The Connection object, will directly deal with working with databases. It will never go into the merits of the data in the database you are working on.
The Session object, on the other hand, will work directly with the data that a user can request, insert, modify or delete (CRUD operation). This object will also offer additional methods such as create / modify / delete users, execute Selector and Batch objects.
Each response to each operation can be encapsulated in a further object Response, which can contain the result of the operation and even more information.
In other languages like Java, a library for nosql database types has been implemented: JNoSQL .
Specification
The connection to the database will be done through a Connection object. Once this object is instantiated, you will not have an immediate connection to the data, but only to the outermost layer of the server hosting the database, dealing exclusively with the various databases.
To get the ability to work on data (CRUD operations) you need to create a new object that will be similar to the Cursor object as far as relational databases are concerned: the Session object.
Calling the connect() method of the Connection object will return a Session object .
Each operation performed by a Connection object or a Session object should return an object of type Response.
This type of object can be instantiated with extra information in addition to the return data, such as the call header or an exit code and relative exception object.
Data read operations (_SELECT_s in relational databases) can be implemented directly through a special object (Selector object) that will have a build() method, which will build its query string based on the database dialect. The object can be passed directly to the find() method of the Session object.
In addition, there are operations that are found only in one type of database vendor. These operations can be implemented as extensions of the core API classes or, it will be possible to implement a Batch object to pass a series of instructions together with an instance of the Session class.
Backwards Compatibility
Existing libraries do not have this type of structure and nomenclature to comply with these APIs. In the nosqlapi library there is a decorator that allows you to map the names of existing methods with API compliant names.
Potential Problems and their Solutions
This section outlines some pitfalls that can arise from using the API.
Reference Implementation
Nosqlapi documentation site: https://nosqlapi.rtfd.io/
Nosqlapi GitHub: https://github.com/MatteoGuadrini/nosqlapi
Nosqlapi production usage: https://github.com/MatteoGuadrini/nosqlapi/blob/main/tests/test_real_produc…
