The following test fails because because `seq1 == seq2` returns a (boolean) NumPy array
whenever either seq is a NumPy array.
import numpy as np
I expected `unittest` to rely only on features of a `collections.abc.Sequence`,
which based on https://docs.python.org/3/glossary.html#term-sequence,
I believe are satisfied by a NumPy array. Specifically, I see no requirement
that a sequence implement __eq__ at all much less in any particular way.
In short: a test named `assertSequenceEqual` should, I would think,
work for any sequence and therefore (based on the available documentation)
should not depend on the class-specific implementation of __eq__.
Is that wrong?
Thank you, Alan Isaac
I would easily bet 10 bucks that vars() is the least known, and least
used, of the Python builtin functions.
My mental model of it was: it was introduced (perhaps in Python3) to
"harmonize" all the existing .__dict__ stuff, and provide more
abstract interface for it, with .__dict__ patiently waiting its
deprecation in CPython 10 or something.
Was I wrong with thinking like that, and finding that vars() was
already in the docs of CPython 1.4, the earliest doc version hosted at
So it seems it was around "always", but then the question is why both
vars() and .__dict__ are round for so long, and there was no
(successful) attempt to stop breaking object encapsulation e.g. on
transitioning to Python3000? Anybody has any references to the story of
them? I can't find anything relevant so far. I in particular made sure
to google for "vars site:python-history.blogspot.com" with 0 hits.
Expected clarification on ".__dict__ breaking object encapsulation":
Usually, object attributes are used to access "some small piece of data"
"stored inside" an object. .__dict__ is not like that. Depending on how
you look at it, its either-or:
1. A *metadata* about an object (object's representation as a dict),
and then it makes sense to use a dedicated access means for that
metadata, exactly what vars() provides.
2. Leak of an implementation detail, because a particular Python
implementation uses a dict as internal storage for modules, classes,
instances, and then .__dict__ just gives blatant access to this
internal storage, bypassing normal object semantics.
I'm trying to find a reviewer for this trivial PR: https://github.com/python/cpython/pull/20530
(The PR fixes CheckTraceCallbackContent (in the sqlite3 test suite) for SQLite pre 3.7.15.)
I've given up hunting for alternative reviewers (a process I find very uncomfortable, since I feel I'm just bugging people who have too much to do with things they're not interested in), so as a last resort, I'm trying the mailing list:
Who can help me review code that touches the sqlite3 module code base?
I've received a lot of constructive reviews from Victor Stinner, Dong-he Na and Pablo Galindo on my past sqlite3 PR's; thank you so much! I still feel uncomfortable requesting their review, as none of them are sqlite3 module maintainers.
I was directed to post this request to the general Python development community so hopefully this is on topic.
One of the weaknesses of the PyUnicode implementation is that the type is concrete and there is no option for an abstract proxy string to a foreign source. This is an issue for an API like JPype in which java.lang.Strings are passed back from Java. Ideally these would be a type derived from the Unicode type str, but that requires transferring the memory immediately from Java to Python even when that handle is large and will never be accessed from within Python. For certain operations like XML parsing this can be prohibitable, so instead of returning a str we return a JString. (There is a separate issue that Java method names and Python method names conflict so direct inheritance creates some problems.)
The JString type can of course be transferred to Python space at any time as both Python Unicode and Java string objects are immutable. However the CPython API which takes strings only accepts the Unicode type objects which have a concrete implementation. It is possible to extend strings, but those extensions do not allow for proxing as far as I can tell. Thus there is no option currently to proxy to a string representation in another language. The concept of the using the duck type ``__str__`` method is insufficient as this indices that an object can become a string, rather than "this object is effectively a string" for the purposes of the CPython API.
One way to address this is to use currently outdated copy of READY to extend Unicode objects to other languages. A class like JString would be an unready Unicode object which when READY is called transfers the memory from Java, sets up the flags and sets up a pointer to the code point representation. Unfortunately the READY concept is scheduled for removal and thus the chance to address the needs for proxying a Unicode to another languages representation may be limited. There may be other methods to accomplish this without using the concept of READY. So long as access to the code points go through the Unicode API and the Unicode object can be extended such that the actual code points may be located outside of the Unicode object then a proxy can still be achieved if there are hooks in it to decided when a transfer should be performed. Generally the transfer request only needs to happen once but the key issue being that the number of code points (nor the kind of points) will not be known until the memory is transferred.
Java has much the same problem. Although they defined an interface class "java.lang.CharacterArray" the actually "java.lang.String" class is concrete and almost all API methods take a String rather than the base interface even when the base interface would have been adequate. Thus just like Python has difficulty treating a foreign string class as it would a native one, Java cannot treat a Python string as native one as well. So Python strings get represented as CharacterArray type which effectively limits it use greatly.
* A String proxy would need the address of the memory in the "wstr" slot though the code points may be char, wchar or int depending the representation in the proxy.
* API calls to interpret the data would need to check to see if the data is transferred first, if not it would call the proxy dependent transfer method which is responsible for creating a block of code points and set up flags (kind, ascii, ready, and compact).
* The memory block allocated would need to call the proxy dependent destructor to clean up with the string is done.
* It is not clear if this would have impact on performance. Python already has the concept of a string which needs actions before it can be accessed, but this is scheduled for removal.
Are there any plans currently to address the concept of a proxy string in PyUnicode API?
I know this is a high-volume list so sorry for being yet another voice
screaming into your mailbox, but I do not know how else to handle this.
A few months ago, I opened a pull request fixing packed bitfields in
ctypes struct/union, which right now are being incorrectly created. The
offsets and size are all wrong in some cases, fields which should be
packed end up with padding between them.
Since ctypes has no maintainer it has been very hard tracking down
someone who is up to review this. So, if this issue sparks some
interest to you, or you just want to help me out, please have a look :)
Should this be considered a bug in the Enum implementation?
>>> class Foo(enum.Enum):
... A = True
... B = 1
... C = 0
... D = False
Seems to me like it should store and compare both type and value.
PEP 634/5/6 presents a possible implementation of pattern matching for
Much of the discussion around PEP 634, and PEP 622 before it, seems to
imply that PEP 634 is synonymous with pattern matching; that if you
reject PEP 634 then you are rejecting pattern matching.
That simply isn't true.
Can we discuss whether we want pattern matching in Python and
the broader semantics first, before dealing with low level details?
Do we want pattern matching in Python at all?
Pattern matching works really well in statically typed, functional
The lack of mutability, constrained scope and the ability of the
compiler to distinguish let variables from constants means that pattern
matching code has fewer errors, and can be compiled efficiently.
Pattern matching works less well in dynamically-typed, functional
languages and statically-typed, procedural languages.
Nevertheless, it works well enough for it to be a popular feature in
both erlang and rust.
In dynamically-typed, procedural languages, however, it is not clear (at
least not to me) that it works well enough to be worthwhile.
That is not say that pattern matching could never be of value in Python,
but PEP 635 fails to demonstrate that it can (although it does a better
job than PEP 622).
Should match be an expression, or a statement?
Do we want a fancy switch statement, or a powerful expression?
Expressions have the advantage of not leaking (like comprehensions in
Python 3), but statements are easier to work with.
Can pattern matching make it clear what is assigned?
Embedding the variables to be assigned into a pattern, makes the pattern
concise, but requires discarding normal Python syntax and inventing a
new sub-language. Could we make patterns fit Python better?
Is it possible to make assignment to variables clear, and unambiguous,
and allow the use of symbolic constants at the same time?
I think it is, but PEP 634 fails to do this.
How should pattern matching be integrated with the object model?
What special method(s) should be added? How and when should they be called?
PEP 634 largely disregards the object model, meaning it has many special
cases, and is inefficient.
The semantics must be well defined.
Language extensions PEPs should define the semantics of those
extensions. For example, PEP 343 and PEP 380 both did.
PEP 634 just waves its hands and talks about undefined behavior, which
I would ask anyone who wants pattern matching adding to Python, to not
support PEP 634.
PEP 634 just isn't a good fit for Python, and we deserve something better.
Many open-source developers are committing to several projects, developing package (for Python). A fraction of developers might need funds for the continuing development of several projects and to pursue contributing. Sadly, there is no direct short way for donors to fund python package developers. There is no particular function in the python package installer(pip) and the site.
A command-line argument(pip3 fund) for listing the funding pages of package developer for packages installed by them (global or pyenv), will help donors to reach such developers easily. The funding page can be the GitHub sponsor page, or PayPal redirect (control of the developer)
Similar implementations include the "npm fund" command. This command retrieves information on how to fund the dependencies of a given project, released 4-5 months ago which has gained momentum.
On Tue, Dec 22, 2020 at 11:44 PM Alan G. Isaac <alan.isaac(a)gmail.com> wrote:
> My question is not about work arounds.
> It is about whether the current definition of a sequence
> (in collections.abc) should govern `assertSequenceEqual`.
Why do you think a NumPy array is a sequence?
>>> len(a) = len(b)
Ok, I suppose if you then loop through indices, you indeed get different
things. But N-dimensional arrays aren't "indexed by an integer" except in
the sense of an edge case. I've always read the Glossary as more narrowly
"element access using ONLY integer indices."
Moreover, if you propose to ignore `==` comparison and always loop, will
you do so recursively? What about:
assertSequenceEqual(a, [[1,2], [3,4]])
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.