From songofacandy at gmail.com  Sat Jul  1 02:20:18 2023
From: songofacandy at gmail.com (Inada Naoki)
Date: Sat, 1 Jul 2023 15:20:18 +0900
Subject: from __future__ import annotations bug?
In-Reply-To: <CAH=MJ4YZ+dvT8Hbfgh9701rxH-wsLE-0LG6=BB8B_Z1RhA+JeQ@mail.gmail.com>
References: <CAH=MJ4YZ+dvT8Hbfgh9701rxH-wsLE-0LG6=BB8B_Z1RhA+JeQ@mail.gmail.com>
Message-ID: <CAEfz+Tw9WfLpgviqStZteiysSSW8dQYnHFEZuNBJx9JCPKVLog@mail.gmail.com>

> but does this mean that even with PEP 649 that forward references will
> still be needed?

Yes. Both of PEP 563 and PEP 649 solves not all forward reference issues.

-- 
Inada Naoki  <songofacandy at gmail.com>

From peter.slizik at gmail.com  Mon Jul  3 13:38:08 2023
From: peter.slizik at gmail.com (=?UTF-8?B?UGV0ZXIgU2zDrcW+aWs=?=)
Date: Mon, 3 Jul 2023 19:38:08 +0200
Subject: Multiple inheritance and a broken super() chain
Message-ID: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>

Hello.

The legacy code I'm working with uses a classic diamond inheritance. Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example. The classes were written in the
pre-super() era, so all of them initialized their parents and Bottom
initialized both Left and Right in this order.

The result was expected: *Top* was initialized twice:

Top.__init__() Left.__init__() Top.__init__() Right.__init__()
Bottom.__init__()

Now I replaced all parent init calls with *super()*. After this, Top was
initialized only once.

Top.__init__() Right.__init__() Left.__init__() Bottom.__init__()

But at this point, I freaked out. The code is complex and I don't have the
time to examine its inner workings. And before, everything worked correctly
even though Top was initialized twice. So I decided to break the superclass
chain and use super() only in classes inheriting from a single parent. My
intent was to keep the original behavior but use super() where possible to
make the code more readable.

class Top:
def __init__(self):
print("Top.__init__()")

class Left(Top):
def __init__(self):
super().__init__()
print("Left.__init__()")

class Right(Top):
def __init__(self):
super().__init__()
print("Right.__init__()")

class Bottom(Left, Right):
def __init__(self):
Left.__init__(self) # Here I'm calling both parents manually
Right.__init__(self)
print("Bottom.__init__()")

b = Bottom()


The result has surprised me:

Top.__init__() Right.__init__() Left.__init__() Top.__init__()
Right.__init__() Bottom.__init__()

Now, as I see it, from the super()'s point of view, there are two
inheritance chains, one starting at Left and the other at Right. But
*Right.__init__()* is called twice. What's going on here?

Thanks,
Peter

From Richard at Damon-Family.org  Mon Jul  3 14:01:19 2023
From: Richard at Damon-Family.org (Richard Damon)
Date: Mon, 3 Jul 2023 14:01:19 -0400
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
Message-ID: <a4af0b35-a0bc-febd-fdc3-cafb316673c9@Damon-Family.org>

On 7/3/23 1:38 PM, Peter Sl??ik via Python-list wrote:
> Hello.
>
> The legacy code I'm working with uses a classic diamond inheritance. Let me
> call the classes *Top*, *Left*, *Right*, and *Bottom*.
> This is a trivial textbook example. The classes were written in the
> pre-super() era, so all of them initialized their parents and Bottom
> initialized both Left and Right in this order.
>
> The result was expected: *Top* was initialized twice:
>
> Top.__init__() Left.__init__() Top.__init__() Right.__init__()
> Bottom.__init__()
>
> Now I replaced all parent init calls with *super()*. After this, Top was
> initialized only once.
>
> Top.__init__() Right.__init__() Left.__init__() Bottom.__init__()
>
> But at this point, I freaked out. The code is complex and I don't have the
> time to examine its inner workings. And before, everything worked correctly
> even though Top was initialized twice. So I decided to break the superclass
> chain and use super() only in classes inheriting from a single parent. My
> intent was to keep the original behavior but use super() where possible to
> make the code more readable.
>
> class Top:
> def __init__(self):
> print("Top.__init__()")
>
> class Left(Top):
> def __init__(self):
> super().__init__()
> print("Left.__init__()")
>
> class Right(Top):
> def __init__(self):
> super().__init__()
> print("Right.__init__()")
>
> class Bottom(Left, Right):
> def __init__(self):
> Left.__init__(self) # Here I'm calling both parents manually
> Right.__init__(self)
> print("Bottom.__init__()")
>
> b = Bottom()
>
>
> The result has surprised me:
>
> Top.__init__() Right.__init__() Left.__init__() Top.__init__()
> Right.__init__() Bottom.__init__()
>
> Now, as I see it, from the super()'s point of view, there are two
> inheritance chains, one starting at Left and the other at Right. But
> *Right.__init__()* is called twice. What's going on here?
>
> Thanks,
> Peter

Because the MRO from Bottom is [Bottom, Left, Right, Top] so super() in 
Left is Right. It doesn't go to Top as the MRO knows that Right should 
go to Top, so Left needs to go to Right to init everything, and then 
Bottom messes things up by calling Right again.

-- 
Richard Damon


From mats at wichmann.us  Mon Jul  3 14:13:37 2023
From: mats at wichmann.us (Mats Wichmann)
Date: Mon, 3 Jul 2023 12:13:37 -0600
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <a4af0b35-a0bc-febd-fdc3-cafb316673c9@Damon-Family.org>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <a4af0b35-a0bc-febd-fdc3-cafb316673c9@Damon-Family.org>
Message-ID: <e2762c37-6bf5-91f3-1b84-0abb76ac8158@wichmann.us>

On 7/3/23 12:01, Richard Damon via Python-list wrote:
> On 7/3/23 1:38 PM, Peter Sl??ik via Python-list wrote:
>> Hello.
>>
>> The legacy code I'm working with uses a classic diamond inheritance. 
>> Let me
>> call the classes *Top*, *Left*, *Right*, and *Bottom*.
>> This is a trivial textbook example. The classes were written in the
>> pre-super() era, so all of them initialized their parents and Bottom
>> initialized both Left and Right in this order.
>>
>> The result was expected: *Top* was initialized twice:
>>
>> Top.__init__() Left.__init__() Top.__init__() Right.__init__()
>> Bottom.__init__()
>>
>> Now I replaced all parent init calls with *super()*. After this, Top was
>> initialized only once.
>>
>> Top.__init__() Right.__init__() Left.__init__() Bottom.__init__()
>>
>> But at this point, I freaked out. The code is complex and I don't have 
>> the
>> time to examine its inner workings. And before, everything worked 
>> correctly
>> even though Top was initialized twice. So I decided to break the 
>> superclass
>> chain and use super() only in classes inheriting from a single parent. My
>> intent was to keep the original behavior but use super() where 
>> possible to
>> make the code more readable.
>>
>> class Top:
>> def __init__(self):
>> print("Top.__init__()")
>>
>> class Left(Top):
>> def __init__(self):
>> super().__init__()
>> print("Left.__init__()")
>>
>> class Right(Top):
>> def __init__(self):
>> super().__init__()
>> print("Right.__init__()")
>>
>> class Bottom(Left, Right):
>> def __init__(self):
>> Left.__init__(self) # Here I'm calling both parents manually
>> Right.__init__(self)
>> print("Bottom.__init__()")
>>
>> b = Bottom()
>>
>>
>> The result has surprised me:
>>
>> Top.__init__() Right.__init__() Left.__init__() Top.__init__()
>> Right.__init__() Bottom.__init__()
>>
>> Now, as I see it, from the super()'s point of view, there are two
>> inheritance chains, one starting at Left and the other at Right. But
>> *Right.__init__()* is called twice. What's going on here?
>>
>> Thanks,
>> Peter
> 
> Because the MRO from Bottom is [Bottom, Left, Right, Top] so super() in 
> Left is Right. It doesn't go to Top as the MRO knows that Right should 
> go to Top, so Left needs to go to Right to init everything, and then
> Bottom messes things up by calling Right again.

And you can see this a little better in your toy example by using begin 
*and* end prints in your initializers.

Also, you might find that because of the MRO, super() in your Bottom 
class would actually give you what you want.

And if not sure, print out Bottom.__mro__




From rosuav at gmail.com  Mon Jul  3 14:39:57 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 4 Jul 2023 04:39:57 +1000
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
Message-ID: <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>

On Tue, 4 Jul 2023 at 03:39, Peter Sl??ik via Python-list
<python-list at python.org> wrote:
>
> Hello.
>
> The legacy code I'm working with uses a classic diamond inheritance. Let me
> call the classes *Top*, *Left*, *Right*, and *Bottom*.
> This is a trivial textbook example. The classes were written in the
> pre-super() era, so all of them initialized their parents and Bottom
> initialized both Left and Right in this order.
>
> The result was expected: *Top* was initialized twice:
>
> Top.__init__() Left.__init__() Top.__init__() Right.__init__()
> Bottom.__init__()

What happens when Top is initialized twice? This seems like a problem
waiting to happen, and when you moved to using super(), you more than
likely simplified things and fixed things.

There are not two instances of Top to be initialized, only one.

ChrisA

From mats at wichmann.us  Mon Jul  3 15:06:03 2023
From: mats at wichmann.us (Mats Wichmann)
Date: Mon, 3 Jul 2023 13:06:03 -0600
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <e2762c37-6bf5-91f3-1b84-0abb76ac8158@wichmann.us>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <a4af0b35-a0bc-febd-fdc3-cafb316673c9@Damon-Family.org>
 <e2762c37-6bf5-91f3-1b84-0abb76ac8158@wichmann.us>
Message-ID: <bb3f0e2b-7a7f-90c8-3447-daa9ef00598e@wichmann.us>

On 7/3/23 12:13, Mats Wichmann via Python-list wrote:

To natter on a bit, and possibly muddy the waters even further...

> Now, as I see it, from the super()'s point of view, there are two
> inheritance chains, one starting at Left and the other at Right. But
> *Right.__init__()* is called twice.
No: each class has just a single inheritance chain, built up when the 
class object is constructed, to avoid going insane. Yes, the chain for 
Left and for Right are different, but you're not instantiating *either* 
of those classes when you make a Bottom, so they don't matter here. 
You're just filling out a Bottom: it looks for init, finds it, and so 
would stop hunting - but then the super() call there sends it to the 
next class object in the chain to look for the method you told it to 
(also init), where it would stop since it found it, except you sent it 
on with another super(), and so on.  Python is a bit... different :) 
(compared to other languages with class definitions)


From peter.slizik at gmail.com  Tue Jul  4 08:04:22 2023
From: peter.slizik at gmail.com (=?UTF-8?B?UGV0ZXIgU2zDrcW+aWs=?=)
Date: Tue, 4 Jul 2023 14:04:22 +0200
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <e2762c37-6bf5-91f3-1b84-0abb76ac8158@wichmann.us>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <a4af0b35-a0bc-febd-fdc3-cafb316673c9@Damon-Family.org>
 <e2762c37-6bf5-91f3-1b84-0abb76ac8158@wichmann.us>
Message-ID: <CAC-uhUA++otXiOUFt7mteQYUX_Bsr16T79txRNDg-o0Q6qKK7Q@mail.gmail.com>

>
> Also, you might find that because of the MRO, super() in your Bottom
> class would actually give you what you want.
>

I knew this, but I wanted to save myself some refactoring, as the legacy
code used different signatures for Left.__init__() and Right.__init__().

I realized the formatting of my code examples was completely removed; sorry
for that.

Best regards,
Peter

From rosuav at gmail.com  Tue Jul  4 08:08:58 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 4 Jul 2023 22:08:58 +1000
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <CAC-uhUA++otXiOUFt7mteQYUX_Bsr16T79txRNDg-o0Q6qKK7Q@mail.gmail.com>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <a4af0b35-a0bc-febd-fdc3-cafb316673c9@Damon-Family.org>
 <e2762c37-6bf5-91f3-1b84-0abb76ac8158@wichmann.us>
 <CAC-uhUA++otXiOUFt7mteQYUX_Bsr16T79txRNDg-o0Q6qKK7Q@mail.gmail.com>
Message-ID: <CAPTjJmo8S=xD9Kxv3a2VSAzWHfS3fj46YE-HQ=VyNV5aSVRD-w@mail.gmail.com>

On Tue, 4 Jul 2023 at 22:06, Peter Sl??ik via Python-list
<python-list at python.org> wrote:
>
> >
> > Also, you might find that because of the MRO, super() in your Bottom
> > class would actually give you what you want.
> >
>
> I knew this, but I wanted to save myself some refactoring, as the legacy
> code used different signatures for Left.__init__() and Right.__init__().

This sounds like a mess that I would not touch. Unless something needs
to be fixed, I wouldn't switch these to use super() - I'd leave them
using explicit parent calls.

However, I would acknowledge somewhere that this will cause
Top.__init__() to be called twice on the same object.

ChrisA

From peter.slizik at gmail.com  Tue Jul  4 08:20:08 2023
From: peter.slizik at gmail.com (=?UTF-8?B?UGV0ZXIgU2zDrcW+aWs=?=)
Date: Tue, 4 Jul 2023 14:20:08 +0200
Subject: Best practices for using super()
Message-ID: <CAC-uhUDec2nz64AZnjR5KnKnVgVfeTRBUXFiGnjCJb7AC62+xQ@mail.gmail.com>

As a follow-up to my yesterday's question - are there any recommendations
on the usage of super()?

It's clear that super() can be used to invoke parent's:
 - instance methods
 - static methods
 - constants ("static" attributes in the parent class, e.g. super().NUMBER).

This all works, but are there situations in which calling them explicitly
using a parent class name is preferred?

Best regards,
Peter

From learn2program at gmail.com  Tue Jul  4 18:33:51 2023
From: learn2program at gmail.com (Alan Gauld)
Date: Tue, 4 Jul 2023 23:33:51 +0100
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>
Message-ID: <ebebe50d-fed7-0f67-99f0-92c6532b04a0@yahoo.co.uk>

On 03/07/2023 19:39, Chris Angelico via Python-list wrote:
> On Tue, 4 Jul 2023 at 03:39, Peter Sl??ik via Python-list
>> The legacy code I'm working with uses a classic diamond inheritance. 

> What happens when Top is initialized twice? This seems like a problem
> waiting to happen, and when you moved to using super(), you more than
> likely simplified things and fixed things.

Slightly off topic but I wonder how many real world problems
people have experienced having the top of a diamond initialized
twice? The reason I ask is that I ran a maintenance team for
about 5 years (early 1990s) working on various OOP projects using MI;
in Lisp Flavors, C++(*) and a homebrew variant of C that supported MI.
In that time I don't recall ever having problems with top objects
being initialized twice (apart from redundant execution of code
of course).

In most cases the top object was so abstract that its init()/constructor
was only doing generic type stuff or opening database sessions/networks
etc which got lost and tidied up by garbage collectors.

So I'm curious about how big this "big problem with MI" is in
practice. I'm sure there are scenarios where it has bitten folks
but it never (or very rarely) occurred in our projects. (Of
course, being maintenance programmers, the problems may have
been ironed out before the code ever reached us! But that
wasn't usually the case...)

(*) C++ is the odd one out because it doesn't have GC, but then
neither does it have an Object superclass so very often MI in C++
does not involve creating diamonds! And especially if the MI
style is mixin based.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos



From rosuav at gmail.com  Tue Jul  4 20:27:37 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 5 Jul 2023 10:27:37 +1000
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <ebebe50d-fed7-0f67-99f0-92c6532b04a0@yahoo.co.uk>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>
 <ebebe50d-fed7-0f67-99f0-92c6532b04a0@yahoo.co.uk>
Message-ID: <CAPTjJmqESiuT7GUXOQeQk0jYtujC0to81i_snML-KLFoKsty4A@mail.gmail.com>

On Wed, 5 Jul 2023 at 08:35, Alan Gauld via Python-list
<python-list at python.org> wrote:
>
> On 03/07/2023 19:39, Chris Angelico via Python-list wrote:
> > On Tue, 4 Jul 2023 at 03:39, Peter Sl??ik via Python-list
> >> The legacy code I'm working with uses a classic diamond inheritance.
>
> > What happens when Top is initialized twice? This seems like a problem
> > waiting to happen, and when you moved to using super(), you more than
> > likely simplified things and fixed things.
>
> Slightly off topic but I wonder how many real world problems
> people have experienced having the top of a diamond initialized
> twice? The reason I ask is that I ran a maintenance team for
> about 5 years (early 1990s) working on various OOP projects using MI;
> in Lisp Flavors, C++(*) and a homebrew variant of C that supported MI.
> In that time I don't recall ever having problems with top objects
> being initialized twice (apart from redundant execution of code
> of course).

It's important to distinguish between diamond inheritance and what the
OP seemed to expect, which was independent hierarchies. (In C++ terms,
that's virtual inheritance and .... the unnamed default type of MI.
Non-virtual inheritance??) With independent hierarchies, the object is
composed of two subobjects, each with its own regular
single-inheritance tree, and unless you need to call a method on the
duplicated grandparent from the second parent (in which case you have
to cast before calling), it's perfectly natural to treat them
separately. But with virtual inheritance - as is always the case in
Python - there is only one object.

Whether it's a problem depends entirely on what the initializer does.
If it's idempotent and doesn't depend on any arguments that it didn't
already get, we're fine! But if it does something like this:

class Example:
    def __init__(self):
        self.button = Some_GUI_Library.Button("Example")
        self.button.add_to_window()

then calling init twice will create a second button.

It's easy enough to design a specification that is safe against double
initialization; but then, it's also not that hard to design a
specification that's safe against super().__init__() and odd
hierarchies.

Since the OP didn't show us any of the code, I had to mention the
possibility here. Of course, it's entirely possible that it isn't
actually a problem.

> In most cases the top object was so abstract that its init()/constructor
> was only doing generic type stuff or opening database sessions/networks
> etc which got lost and tidied up by garbage collectors.

Remember though that diamond inheritance doesn't always happen at the
top-level object.

> So I'm curious about how big this "big problem with MI" is in
> practice. I'm sure there are scenarios where it has bitten folks
> but it never (or very rarely) occurred in our projects. (Of
> course, being maintenance programmers, the problems may have
> been ironed out before the code ever reached us! But that
> wasn't usually the case...)

Who said it's a big problem with MI? Diamond inheritance is in general
a problem to be solved, but calling __init__ twice is a separate
concern and usually only an issue when you try to treat MRO-based MI
as if it were composition-based MI.

ChrisA

From greg.ewing at canterbury.ac.nz  Tue Jul  4 20:26:35 2023
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 5 Jul 2023 12:26:35 +1200
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <mailman.163.1688510035.23016.python-list@python.org>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>
 <ebebe50d-fed7-0f67-99f0-92c6532b04a0@yahoo.co.uk>
 <mailman.163.1688510035.23016.python-list@python.org>
Message-ID: <kgjrltFntr1U1@mid.individual.net>

On 5/07/23 10:33 am, Alan Gauld wrote:
> (*) C++ is the odd one out because it doesn't have GC, but then
> neither does it have an Object superclass so very often MI in C++
> does not involve creating diamonds! And especially if the MI
> style is mixin based.

Even if all your mixins have empty constructors, in C++ there
is still a diamond problem if they have any data members, because
you end up with multiple copies of them.

But C++ has the concept of virtual base classes, which avoids the
diamond problem, albeit at the expense of making you explicitly
call all the base class constructors in your ancestry.

-- 
Greg






From rosuav at gmail.com  Tue Jul  4 20:51:46 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 5 Jul 2023 10:51:46 +1000
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <kgjrltFntr1U1@mid.individual.net>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>
 <ebebe50d-fed7-0f67-99f0-92c6532b04a0@yahoo.co.uk>
 <mailman.163.1688510035.23016.python-list@python.org>
 <kgjrltFntr1U1@mid.individual.net>
Message-ID: <CAPTjJmpi2WsT4KqJe=bhMTAZxENT+t9c6BSQFiirZKdxMrY52g@mail.gmail.com>

On Wed, 5 Jul 2023 at 10:31, Greg Ewing via Python-list
<python-list at python.org> wrote:
>
> On 5/07/23 10:33 am, Alan Gauld wrote:
> > (*) C++ is the odd one out because it doesn't have GC, but then
> > neither does it have an Object superclass so very often MI in C++
> > does not involve creating diamonds! And especially if the MI
> > style is mixin based.
>
> Even if all your mixins have empty constructors, in C++ there
> is still a diamond problem if they have any data members, because
> you end up with multiple copies of them.
>
> But C++ has the concept of virtual base classes, which avoids the
> diamond problem, albeit at the expense of making you explicitly
> call all the base class constructors in your ancestry.

Yeah, non-virtual MI in C++ is basically composition with a shorthand
for calling non-conflicting methods or accessing non-conflicting data
members. Point of random interest: Pike actually allows that sort of
"composition MI" but will give you back an array of all parents when
you seek a superclass's method, giving a very elegant syntax for MI.

inherit Thing1;
inherit Thing2;

void method() {
    ::method(); //this is actually calling an array of two methods
}

Python's way of doing it requires that every class choose to cooperate
in the MI and then be aware that they are all operating on the same
object. Pike's and C++'s can sometimes be used as composition in
disguise, but in general, MI does require proper cooperation.

ChrisA

From lal at solute.de  Wed Jul  5 04:34:45 2023
From: lal at solute.de (Lars Liedtke)
Date: Wed, 5 Jul 2023 10:34:45 +0200
Subject: Best practices for using super()
In-Reply-To: <CAC-uhUDec2nz64AZnjR5KnKnVgVfeTRBUXFiGnjCJb7AC62+xQ@mail.gmail.com>
References: <CAC-uhUDec2nz64AZnjR5KnKnVgVfeTRBUXFiGnjCJb7AC62+xQ@mail.gmail.com>
Message-ID: <6c77478f-0a17-1f6f-31ea-ca103f9078b2@solute.de>

Hey,

When you have multiple inheritance and you e.g. want to explicitely call __init__ of one of the classes inherited from, that is not the first in the list of classes to inherit from.

Cheers,

Lars


Lars Liedtke
Senior Software Developer

[Tel.]  +49 721 98993-
[Fax]   +49 721 98993-
[E-Mail]        lal at solute.de<mailto:lal at solute.de>


solute GmbH
Zeppelinstra?e 15
76185 Karlsruhe
Germany


[Logo Solute]


Marken der solute GmbH | brands of solute GmbH
[Marken]
[Advertising Partner]

Gesch?ftsf?hrer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de <http://www.solute.de/>
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798



Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php




Am 04.07.23 um 14:20 schrieb Peter Sl??ik via Python-list:

As a follow-up to my yesterday's question - are there any recommendations
on the usage of super()?

It's clear that super() can be used to invoke parent's:
 - instance methods
 - static methods
 - constants ("static" attributes in the parent class, e.g. super().NUMBER).

This all works, but are there situations in which calling them explicitly
using a parent class name is preferred?

Best regards,
Peter


From learn2program at gmail.com  Wed Jul  5 13:40:39 2023
From: learn2program at gmail.com (Alan Gauld)
Date: Wed, 5 Jul 2023 18:40:39 +0100
Subject: Multiple inheritance and a broken super() chain
In-Reply-To: <CAPTjJmqESiuT7GUXOQeQk0jYtujC0to81i_snML-KLFoKsty4A@mail.gmail.com>
References: <CAC-uhUARYKsk92r4BEDmDGx6wbyLZbrOeL1izwHurOUDjEbJJA@mail.gmail.com>
 <CAPTjJmrf-hnPanva0pSpd121oHVum5QMKF4qwZLABJ4kUX-wrg@mail.gmail.com>
 <ebebe50d-fed7-0f67-99f0-92c6532b04a0@yahoo.co.uk>
 <CAPTjJmqESiuT7GUXOQeQk0jYtujC0to81i_snML-KLFoKsty4A@mail.gmail.com>
Message-ID: <ad546a3b-9a98-da68-efe7-1133a23dd970@yahoo.co.uk>

On 05/07/2023 01:27, Chris Angelico via Python-list wrote:

>> So I'm curious about how big this "big problem with MI" is in
> 
> Who said it's a big problem with MI? 

I think it's a very common perception, particularly with
newer programmers who have never used it in anger. Any
time anyone discusses MI it seems somebody will jump in
and warn about diamonds etc. As a result many steer clear
of MI, which is a shame.

My personal experience of MI is that used appropriately
it is a powerful and useful tool. But it must be used
in a true is-a type relationship and not just as a kind
of cheap reuse mechanism - that's when problems start.

Also, mixin style MI is particularly powerful but the
protocol between mixin and "subclass" needs to be carefully
designed and documented. Like any powerful tool you need
to understand the costs of use as well as the potential
benefits.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos



From tn5421 at protonmail.com  Thu Jul  6 02:02:17 2023
From: tn5421 at protonmail.com (neopolitan)
Date: Thu, 6 Jul 2023 01:02:17 -0500
Subject: What is this TEST BANK stuff ?
In-Reply-To: <3dcfc5c1-bf00-44df-aea7-cc1a9e7b0e6fn@googlegroups.com>
References: <3dcfc5c1-bf00-44df-aea7-cc1a9e7b0e6fn@googlegroups.com>
Message-ID: <u85ld9$r5n4$1@dont-email.me>

On 6/21/23 08:37, Dan Kolis wrote:
> Why do we tolerate this spam ?
> 
> this seems most likely a way to inject viruses into people's workflow.
> 
> That wiped out usenet. Ahh without an explaination; ( and it woudl have to be a good one ); what is the purpsoe of this, why is it here ?
> 
> Can it be eliminated ?
> 
> Regards,
> Dan

tl;dr It would be difficult to without changing the group to be 
moderated. I am very new but am working to build up a list of known 
spammers so I can auto-delete their nonsense from my machine.

From manta103g at gmail.com  Thu Jul  6 08:23:35 2023
From: manta103g at gmail.com (a a)
Date: Thu, 6 Jul 2023 05:23:35 -0700 (PDT)
Subject: What is this TEST BANK stuff ?
In-Reply-To: <3dcfc5c1-bf00-44df-aea7-cc1a9e7b0e6fn@googlegroups.com>
References: <3dcfc5c1-bf00-44df-aea7-cc1a9e7b0e6fn@googlegroups.com>
Message-ID: <25ea942d-6f1b-4db0-9cf7-454def715a38n@googlegroups.com>

On Wednesday, 21 June 2023 at 15:38:00 UTC+2, Dan Kolis wrote:
> Why do we tolerate this spam ? 
> 
> this seems most likely a way to inject viruses into people's workflow. 
> 
> That wiped out usenet. Ahh without an explaination; ( and it woudl have to be a good one ); what is the purpsoe of this, why is it here ? 
> 
> Can it be eliminated ? 
> 
> Regards, 
> Dan


Just call Google guys and ask, why usenet groups turned DejaNews, aquired by Google in the past
are not protected against massive spam by a single easy script

From rosuav at gmail.com  Thu Jul  6 15:30:47 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 7 Jul 2023 05:30:47 +1000
Subject: What is this TEST BANK stuff ?
In-Reply-To: <u85ld9$r5n4$1@dont-email.me>
References: <3dcfc5c1-bf00-44df-aea7-cc1a9e7b0e6fn@googlegroups.com>
 <u85ld9$r5n4$1@dont-email.me>
Message-ID: <CAPTjJmrm8N-ZJPB4M+DkXUgF5PXXz_RQDB7B7fZed-=yy1CpxA@mail.gmail.com>

On Fri, 7 Jul 2023 at 03:33, neopolitan via Python-list
<python-list at python.org> wrote:
>
> On 6/21/23 08:37, Dan Kolis wrote:
> > Why do we tolerate this spam ?
> >
> > this seems most likely a way to inject viruses into people's workflow.
> >
> > That wiped out usenet. Ahh without an explaination; ( and it woudl have to be a good one ); what is the purpsoe of this, why is it here ?
> >
> > Can it be eliminated ?
> >
> > Regards,
> > Dan
>
> tl;dr It would be difficult to without changing the group to be
> moderated. I am very new but am working to build up a list of known
> spammers so I can auto-delete their nonsense from my machine.

Yeah, a few people worked on that. Turns out though, you can save
yourself a LOT of trouble by letting the python-list admins manage
that blocklist :)

ChrisA

From martin.schoon at gmail.com  Sat Jul  8 17:11:22 2023
From: martin.schoon at gmail.com (Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=)
Date: 8 Jul 2023 21:11:22 GMT
Subject: scipy.optimize.least_squares for more than one dimension?
References: <kg78faFpb6bU1@mid.individual.net>
Message-ID: <kgu1nqFcmpgU1@mid.individual.net>

Den 2023-06-30 skrev Martin Sch??n <martin.schoon at gmail.com>:
> Yesterday I wanted to move from optimize.leastsq to 
> least_squares. I have data depending on four variables
> and want to fit a function in four variables to this
> data. This works with leastsq but not with least_squares.
>
> Am I trying to do something least_squares is not capable
> of?
>
> Disclaimer: I was burning midnight oil...
>
Problem solved.

Yes, least_squares can, of course, handle multi-dimensional situations.

Me burning midnight oil was the problem. I have been tinkering a
bit with scipy.optimize.least_squares tonight. All simple examples
I tried worked regardless of number of dimensions. I went back to
my old code and found a couple of basic mistakes. Done.

/Martin

From thomas at python.org  Tue Jul 11 16:20:27 2023
From: thomas at python.org (Thomas Wouters)
Date: Tue, 11 Jul 2023 22:20:27 +0200
Subject: [RELEASE] Python 3.12.0 beta 4 released
Message-ID: <CAPdQG2qehcAWigmWtvmMz84Uzwud50Lk1WvODHhXPOCYq_+TAg@mail.gmail.com>

Not much time left! I?ve released 3.12.0 beta 4. We?re now in the run-up to
rc1, so keep that in mind when you backport to the 3.12 branch.

https://www.python.org/downloads/release/python-3120b4/


*This is a beta preview of Python 3.12*
Python 3.12 is still in development. This release, 3.12.0b4, is the final
of four beta release previews of 3.12.

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.12* 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,
2023-07-31). Our goal is to have no ABI changes after this release, and as
few code changes as possible after 3.12.0rc1, the first release candidate.
To achieve that, it will be *extremely important* to get as much exposure
for 3.12 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.12 series, compared to 3.11*
Some of the new major new features and changes in Python 3.12 are:


   - New type annotation syntax for generic classes (PEP 695
   <https://peps.python.org/pep-0695/>).
   - More flexible f-string parsing, allowing many things previously
   disallowed (PEP 701 <https://peps.python.org/pep-0701/>).
   - Support for the buffer protocol in Python code (PEP 688
   <https://peps.python.org/pep-0688/>).
   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Many large and small performance improvements (like PEP 709
   <https://peps.python.org/pep-0709/>).
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   <https://peps.python.org/pep-0623/>.
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594 <https://peps.python.org/pep-0594/> and PEP 632
   <https://peps.python.org/pep-0632/>. The setuptools package continues to
   provide the distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - Invalid backslash escape sequences in strings now warn with SyntaxWarning
   instead of DeprecationWarning, making them more visible. (They will
   become syntax errors in the future.)
   - The internal representation of integers has changed in preparation for
   performance enhancements. (This should not affect most users as it is an
   internal detail, but it may cause problems for Cython-generated code.)
   - (Hey, fellow core developer, if a feature you find important is
   missing from this list, let Thomas know <thomas at python.org>.)

For more details on the changes to Python 3.12, see What?s new in Python
3.12 <https://docs.python.org/3.12/whatsnew/3.12.html>. The next
pre-release of Python 3.12 will be 3.12.0rc1, the *first release candidate*,
currently scheduled for 2023-07-31.


*More resources*
Online Documentation <https://docs.python.org/3.12/>.
PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the Python 3.12
Release Schedule.
Report bugs via GitHub Issues <https://github.com/python/cpython/issues>.
Help fund Python and its community <https://www.python.org/psf/donations/>.


*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-landing/>.

Regards from the alternating thunderstorms and heat waves in Amsterdam,
Thomas Wouters.

Your release team,
Ned Deily
Steve Dower
?ukasz Langa

-- 
Thomas Wouters <thomas at python.org>

From PythonList at DancesWithMice.info  Tue Jul 11 18:30:15 2023
From: PythonList at DancesWithMice.info (dn)
Date: Wed, 12 Jul 2023 10:30:15 +1200
Subject: Hybrid meeting ANN: Using properties and descriptors
Message-ID: <854cc3c1-de29-2e60-6a67-e0f4e78fe180@DancesWithMice.info>

This month's meeting (Wed 19 July, 1800 for 1830 NZST = 0600/0630 UTC) 
will cover more-advanced OOP Python skills. You will be most-welcome to 
join us...


"Using properties and descriptors" will look at a series of 
code-examples exploring problems and how these constructs offer 
solutions. The presentations are in lecture-style. If there's time (or 
for later study), some coding workshops will be suggested.

Prerequisite knowledge or experience for "Properties":
Object-Oriented Programming (in Python), coding custom-classes, using 
available decorators, some experience in data organisation/design, 
PEP-008 and coding styles, and reading type-hints.

Prerequisite knowledge or experience for "Descriptors":
"Properties" topic in this series, coding custom-classes with 'magic 
methods', implementing inheritance and composition, design-experience in 
data organisation, Object-Oriented Design, decent understanding of OOP 
philosophy.

Hints: A lab-/log-book will be useful for taking notes. A headset will 
ease asking questions, answering questions, and discussion. Python IDE 
ready for coding.

Two choices for attendance: online or in-person (Parnell, Auckland). 
Please RSVP to book-in and receive access information:-

- Remote attendance RSVP: 
https://www.meetup.com/nzpug-auckland/events/njdjssyfckbzb/
- In-person RSVP to https://www.meetup.com/nzpug-auckland/events/294745326/

You are cordially invited to join us!
-- 
Regards,
=dn

From bkline at rksystems.com  Fri Jul 14 13:35:35 2023
From: bkline at rksystems.com (Bob Kline)
Date: Fri, 14 Jul 2023 13:35:35 -0400
Subject: Canonical list of Python security vulnerabilities
Message-ID: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>

Can someone point me to the official catalog of security vulnerabilities in
Python (by which I mean cpython and the standard libraries)? I found
https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html
but that isn't maintained by python.org. I also found
security-announce at python.org, but there hasn't been anything posted there
in over a year as far as I can tell, and even before that it's pretty thin.

If there's a better place to ask, please advise.

Thanks.

-- 
Bob Kline
https://www.rksystems.com
mailto:bkline at rksystems.com

From bkline at rksystems.com  Fri Jul 14 15:00:31 2023
From: bkline at rksystems.com (Bob Kline)
Date: Fri, 14 Jul 2023 15:00:31 -0400
Subject: Canonical list of Python security vulnerabilities
In-Reply-To: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
References: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
Message-ID: <CAGjKmVq635Er2ejX26zM+b_yRkB36UWGDzM9Y5QLk71xBRauJg@mail.gmail.com>

On Fri, Jul 14, 2023 at 1:35?PM Bob Kline <bkline at rksystems.com> wrote:

> Can someone point me to the official catalog of security vulnerabilities
> in Python ....

I did try entering "python security vulnerabilities" in the search box
of the python.org web site, but what I got back was "No results
found."

From barry at barrys-emacs.org  Fri Jul 14 15:01:59 2023
From: barry at barrys-emacs.org (Barry)
Date: Fri, 14 Jul 2023 20:01:59 +0100
Subject: Canonical list of Python security vulnerabilities
In-Reply-To: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
References: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
Message-ID: <9BE28453-06B9-463B-8D8E-C9397F233CA1@barrys-emacs.org>



> On 14 Jul 2023, at 19:14, Bob Kline via Python-list <python-list at python.org> wrote:
> 
> ?Can someone point me to the official catalog of security vulnerabilities in
> Python (by which I mean cpython and the standard libraries)? I found
> https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html
> but that isn't maintained by python.org. I also found
> security-announce at python.org, but there hasn't been anything posted there
> in over a year as far as I can tell, and even before that it's pretty thin.
> 
> If there's a better place to ask, please advise.

Where do you get your python from?

You may find that the organisation that packages python that you use has such a list.

Barry
> 
> Thanks.
> 
> -- 
> Bob Kline
> https://www.rksystems.com
> mailto:bkline at rksystems.com
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 


From bkline at rksystems.com  Fri Jul 14 15:16:29 2023
From: bkline at rksystems.com (Bob Kline)
Date: Fri, 14 Jul 2023 15:16:29 -0400
Subject: Canonical list of Python security vulnerabilities
In-Reply-To: <9BE28453-06B9-463B-8D8E-C9397F233CA1@barrys-emacs.org>
References: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
 <9BE28453-06B9-463B-8D8E-C9397F233CA1@barrys-emacs.org>
Message-ID: <CAGjKmVq+kQ2zkL0EOqMmyyWNe_=riaHN91_eyW0Na9zAW4dTCA@mail.gmail.com>

On Fri, Jul 14, 2023 at 3:02?PM Barry <barry at barrys-emacs.org> wrote:

> Where do you get your python from?

Directly from python.org.

> You may find that the organisation that packages python that you use has such a list.

That's my hope. Just haven't found it yet. :-}

From dieter at handshake.de  Sat Jul 15 13:02:16 2023
From: dieter at handshake.de (Dieter Maurer)
Date: Sat, 15 Jul 2023 19:02:16 +0200
Subject: Canonical list of Python security vulnerabilities
In-Reply-To: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
References: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
Message-ID: <25778.53528.516617.420727@ixdm.fritz.box>

Bob Kline wrote at 2023-7-14 13:35 -0400:
>Can someone point me to the official catalog of security vulnerabilities in
>Python (by which I mean cpython and the standard libraries)? I found
>https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html
>but that isn't maintained by python.org.

I am active in the `Zope` community (a web application server
based on Python). This community has a security mailing list
for security related reports
and issues public CVE (= "Commun Vulnerabilities and Exposures") reports
(via a "GitHUB" service) as soon as a security risk has been resolved.

I expect that security risks for Python itself are handled in
a similar way (as, Python too, maintains its code on "GitHUB").
This means that the CVE dictionary should contain **ALL**
publicly announced security risk reports whether found by
the Pyhton community or packagers.

For details about CVE, read
"https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures".

From yousefezzat06 at gmail.com  Sat Jul 15 02:12:51 2023
From: yousefezzat06 at gmail.com (YOUSEF EZZAT)
Date: Sat, 15 Jul 2023 09:12:51 +0300
Subject: Setup-tools
Message-ID: <CAMTo2dfhhuues3NMsbWTM7LwAKfNZagQV=Epar60d8mzp7ZCrA@mail.gmail.com>

Hey!..... i face a problem when i get setup packages by pip
when i code this : "pip install numpy" in my command line it gives me error
"ModuleNotFoundError: No module named 'distutils' "

please, i need help for solving this problem.........
i have python 3.12.0b4

From python at mrabarnett.plus.com  Sat Jul 15 14:56:20 2023
From: python at mrabarnett.plus.com (MRAB)
Date: Sat, 15 Jul 2023 19:56:20 +0100
Subject: Setup-tools
In-Reply-To: <CAMTo2dfhhuues3NMsbWTM7LwAKfNZagQV=Epar60d8mzp7ZCrA@mail.gmail.com>
References: <CAMTo2dfhhuues3NMsbWTM7LwAKfNZagQV=Epar60d8mzp7ZCrA@mail.gmail.com>
Message-ID: <fc398ff3-3bc9-4b28-5b43-ba81b76d3dac@mrabarnett.plus.com>

On 2023-07-15 07:12, YOUSEF EZZAT via Python-list wrote:
> Hey!..... i face a problem when i get setup packages by pip
> when i code this : "pip install numpy" in my command line it gives me error
> "ModuleNotFoundError: No module named 'distutils'"
> 
> please, i need help for solving this problem.........
> i have python 3.12.0b4

What do you normally do when it can't find a module? Install it via pip!

pip install distutils

By the way, do you really need Python 3.12? It's still in beta, so 
unless you're specifically checking whether it works, ready for its 
final release, you'd be better off with Python 3.11.


From bkline at rksystems.com  Sat Jul 15 15:23:01 2023
From: bkline at rksystems.com (Bob Kline)
Date: Sat, 15 Jul 2023 15:23:01 -0400
Subject: Canonical list of Python security vulnerabilities
In-Reply-To: <25778.53528.516617.420727@ixdm.fritz.box>
References: <CAGjKmVqN+nhH=3BR3VpmeW85hMqQdqQcv31kRFP_SsyFezuC=Q@mail.gmail.com>
 <25778.53528.516617.420727@ixdm.fritz.box>
Message-ID: <CAGjKmVraesJcCfer2NP=13+nUTzq3=DEBRJcGM-D3fAVxJ7b6A@mail.gmail.com>

On Sat, Jul 15, 2023 at 1:02?PM Dieter Maurer <dieter at handshake.de> wrote:
>
> I am active in the `Zope` community (a web application server
> based on Python). This community has a security mailing list
> for security related reports
> and issues public CVE (= "Commun Vulnerabilities and Exposures") reports
> (via a "GitHUB" service) as soon as a security risk has been resolved.
>
> I expect that security risks for Python itself are handled in
> a similar way (as, Python too, maintains its code on "GitHUB").

Yes the Python community does have a security mailing list, but as I
noted earlier, it appears to be moribund. And yes, the cpython GitHub
repository does have a security tab, but it reports "There aren?t any
published security advisories."

> ...
> For details about CVE, read
> "https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures".

Thanks for the link, Dieter. I found the NIST search interface to be
buggy, and there doesn't seem to be a way to search the Mitre site
effectively to get vulnerabilities just for the Python language and
standard libraries. I've downloaded the entire corpus of JSON CVEs and
I'm digging into what would be involved in querying it myself.

Cheers,
Bob

From peter.slizik at gmail.com  Sun Jul 16 09:58:07 2023
From: peter.slizik at gmail.com (=?UTF-8?B?UGV0ZXIgU2zDrcW+aWs=?=)
Date: Sun, 16 Jul 2023 15:58:07 +0200
Subject: Working with paths
Message-ID: <CAC-uhUAVK=_Zi1z+XauzZf=3B2EUhoDg13fohrnFfY-jgxAdUg@mail.gmail.com>

Hello,

I finally had a look at the pathlib module. (Should have done it long ago,
but anyway...). Having in mind the replies from my older thread (File
system path annotations), what is the best way to support all possible path
types?

def doit(path: str | bytes | os.PathLike):
match path:
case str() as path:
print("string")

case bytes() as path:
print("bytes")

case os.PathLike() as path:
print("os.PathLike")

Should I branch on the individual types or is there a more elegant way?

Peter

From mats at wichmann.us  Sun Jul 16 12:56:10 2023
From: mats at wichmann.us (Mats Wichmann)
Date: Sun, 16 Jul 2023 10:56:10 -0600
Subject: Setup-tools
In-Reply-To: <fc398ff3-3bc9-4b28-5b43-ba81b76d3dac@mrabarnett.plus.com>
References: <CAMTo2dfhhuues3NMsbWTM7LwAKfNZagQV=Epar60d8mzp7ZCrA@mail.gmail.com>
 <fc398ff3-3bc9-4b28-5b43-ba81b76d3dac@mrabarnett.plus.com>
Message-ID: <dbfe51d7-29ca-6b9c-b03b-2a2c4d44da54@wichmann.us>

On 7/15/23 12:56, MRAB via Python-list wrote:
> On 2023-07-15 07:12, YOUSEF EZZAT via Python-list wrote:
>> Hey!..... i face a problem when i get setup packages by pip
>> when i code this : "pip install numpy" in my command line it gives me 
>> error
>> "ModuleNotFoundError: No module named 'distutils'"
>>
>> please, i need help for solving this problem.........
>> i have python 3.12.0b4
> 
> What do you normally do when it can't find a module? Install it via pip!
> 
> pip install distutils
> 
> By the way, do you really need Python 3.12? It's still in beta, so 
> unless you're specifically checking whether it works, ready for its 
> final release, you'd be better off with Python 3.11.

To add to this:

For modules which have *binary* compiled wheels (of which numpy is one), 
they are quite likely to be version-specific, and for many projects, are 
not made available for pre-release Pythons. You can check numpy here:

https://pypi.org/project/numpy/#files

(note: pre-release versions targeting pre-release Pythons *may* be 
elsewhere too, you might check with the numpy project).

What pip does if it doesn't find an appropriate wheel version matching 
your Python version is try to build it from the source distribution - 
this is why it thinks it needs distutils.  If you're on Windows, this 
will almost certainly fail, although you can often find blogs written by 
people who have gone through the same adventure who describe how they 
got there in the end.

If numpy is the thing that's important to your work, the advice would be 
to stick to a released Python with a matching released numpy.  If you 
specifically need to test that something is going to work with 3.12, 
then by all means go ahead, but be prepared to do some legwork.




From kushal at locationd.net  Sun Jul 16 13:20:19 2023
From: kushal at locationd.net (Kushal Kumaran)
Date: Sun, 16 Jul 2023 10:20:19 -0700
Subject: Working with paths
In-Reply-To: <CAC-uhUAVK=_Zi1z+XauzZf=3B2EUhoDg13fohrnFfY-jgxAdUg@mail.gmail.com>
 ("Peter =?utf-8?B?U2zDrcW+aWsiJ3M=?= message of "Sun, 16 Jul 2023 15:58:07
 +0200")
References: <CAC-uhUAVK=_Zi1z+XauzZf=3B2EUhoDg13fohrnFfY-jgxAdUg@mail.gmail.com>
Message-ID: <87a5vvhiy4.fsf@copper>

On Sun, Jul 16 2023 at 03:58:07 PM, Peter Sl??ik <peter.slizik at gmail.com> wrote:
> Hello,
>
> I finally had a look at the pathlib module. (Should have done it long ago,
> but anyway...). Having in mind the replies from my older thread (File
> system path annotations), what is the best way to support all possible path
> types?
>
> def doit(path: str | bytes | os.PathLike):
> match path:
> case str() as path:
> print("string")
>
> case bytes() as path:
> print("bytes")
>
> case os.PathLike() as path:
> print("os.PathLike")
>
> Should I branch on the individual types or is there a more elegant way?
>

Depends on what you need to do with the path.  The best way, imo, is to
simply use pathlib.Path and ignore the existence of other path
representations.  If input is coming from elsewhere, convert it to
pathlib.Path as early as possible.  In the main body of your code, it
should be able to rely on all paths being Path objects.

-- 
regards,
kushal

From vinay_sajip at yahoo.co.uk  Mon Jul 17 11:34:32 2023
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Mon, 17 Jul 2023 15:34:32 +0000 (UTC)
Subject: Announcement: distlib 0.3.7 released on PyPI
References: <1191876042.1847970.1689608072812.ref@mail.yahoo.com>
Message-ID: <1191876042.1847970.1689608072812@mail.yahoo.com>

Version 0.3.7 of distlib has recently been released on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools.

The main changes in this release are as follows:

* Handle bare newlines when parsing metadata.

* Use version comparison logic for python_full_version.

* Fix shebang computation for source builds of Python.

* Extract tarfiles more safely by incorporating tarfile filters.

* Check for 'has_cert' attribute before using it.

* Fix #200: Improve conformance to PEP440.

* Fix #203: Handle parsing of export entries to allow script names such as "," or ",foo".

A more detailed change log is available at [2].

Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker at [3].

Regards,

Vinay Sajip

[1] https://pypi.org/project/distlib/0.3.7/
[2] https://distlib.readthedocs.io/en/0.3.7/overview.html#change-log-for-distlib
[3] https://github.com/pypa/distlib/issues/new/choose

From larry.martell at gmail.com  Fri Jul 21 14:08:32 2023
From: larry.martell at gmail.com (Larry Martell)
Date: Fri, 21 Jul 2023 11:08:32 -0700
Subject: pip-sync
Message-ID: <CACwCsY7YpAxCg-pYNAJr_Z1cGfhCCafidvVzW_bQ6R0GND2ihQ@mail.gmail.com>

I am trying to set up and maintain a venv with pip-sync. On my bare
metal I have the apparmor python package installed, but it is not
installed in my venv and it's not in my requirements file. When I run
pip-sync I get:

Found existing installation: apparmor 2.13.3
ERROR: Cannot uninstall 'apparmor'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.

Since it's not installed in the venv why does it want to uninstall it?

From vinay_sajip at yahoo.co.uk  Sat Jul 22 07:04:35 2023
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Sat, 22 Jul 2023 11:04:35 +0000 (UTC)
Subject: ANN: A new version (0.5.1) of python-gnupg has been released.
References: <205418732.5111852.1690023875074.ref@mail.yahoo.com>
Message-ID: <205418732.5111852.1690023875074@mail.yahoo.com>

What Changed?
=============
This is an enhancement and bug-fix release, and all users are encouraged to upgrade.

Brief summary:

 * Added TRUST_EXPIRED to trust_keys.

* Fix #206: Remove deprecated --always-trust in favour of --trust-model always

* Fix #208: Add status_detail attribute to result objects which is populated when
? the status is 'invalid recipient' (encryption/decryption) or 'invalid signer'
? (signing). This attribute will be set when the result object's status attribute is
? set to 'invalid recipient' and will contain more information about the failure in the
? form of reason:ident where reason is a text description of the reason, and
? ident identifies the recipient key.

* Add scan_keys_mem() function to scan keys in a string.

* Fix #214: Handle multiple signatures when one of them is invalid or unverified.

* A problems attribute was added which holds problems reported by gpg
? during verification. This is a list of dictionaries, one for each reported
? problem. Each dictionary will have status and keyid keys indicating
? the problem and the corresponding key; other information in the dictionaries
? will be error specific.

* Fix #217: Use machine-readable interface to query the gpg version.

* Added the ability to export keys to a file.
This release [2] has been signed with my code signing key:

Vinay Sajip (CODE SIGNING KEY) <vinay_sajip at yahoo.co.uk>
Fingerprint: CA74 9061 914E AC13 8E66 EADB 9147 B477 339A 9B86

Recent changes to PyPI don't show the GPG signature with the download links.
An alternative download source where the signatures are available is at [4].
The source code repository is at [1].
Documentation is available at [5].
As always, your feedback is most welcome (especially bug reports [3],
patches and suggestions for improvement, or any other points via this group).

Enjoy!

Cheers

Vinay Sajip

[1] https://github.com/vsajip/python-gnupg
[2] https://pypi.org/project/python-gnupg/0.5.1
[3] https://github.com/vsajip/python-gnupg/issues
[4] https://github.com/vsajip/python-gnupg/releases/
[5] https://docs.red-dove.com/python-gnupg/

From 2QdxY4RzWzUUiLuE at potatochowder.com  Sat Jul 22 10:44:37 2023
From: 2QdxY4RzWzUUiLuE at potatochowder.com (2QdxY4RzWzUUiLuE at potatochowder.com)
Date: Sat, 22 Jul 2023 10:44:37 -0400
Subject: ANN: A new version (0.5.1) of python-gnupg has been released.
In-Reply-To: <205418732.5111852.1690023875074@mail.yahoo.com>
References: <205418732.5111852.1690023875074.ref@mail.yahoo.com>
 <205418732.5111852.1690023875074@mail.yahoo.com>
Message-ID: <ZLvrVUiNgle4RAmf@anomaly>

On 2023-07-22 at 11:04:35 +0000,
Vinay Sajip via Python-list <python-list at python.org> wrote:

> What Changed?
> =============

What changed, indeed.

Maybe I'm old, and curmudgeonly, but it would be nice if the body of
these annoucement emails (not just this one) contained the name of the
program and a one-line summary of what the program does, preferably
right at the top.

(Admittedly, in this case, once I found the name of the program in the
subject and the footnotes, I was able to figure out what it does.  Not
all software is named that usefully.)

From menyland at gmail.com  Sat Jul 22 19:12:41 2023
From: menyland at gmail.com (Chris Nyland)
Date: Sat, 22 Jul 2023 19:12:41 -0400
Subject: Meta Class Maybe?
Message-ID: <CALGOvYYdCaa9HCSrFpc=M=vT5oKiR=UKfQyjP75PRph2jpCmKA@mail.gmail.com>

So I am stuck on a problem. I have a class which I want to use to create
another class without having to go through the boiler plate of subclassing.
Specifically because the subclass needs to have certain class attributes
and I would like to control how those are passed to provide defaults and
such. What I have working right now is

class Foo():
    @classmethod
    def method_a(cls): print(cls.name)

Bar = type('Bar', (Foo,), {'name': 'test1'})

Bar.method_a()

This is sort of fine but the user needs to know how to call type and
include all the base classes etc.

I could just wrap the type call in a function like below

def BarMaker(name):
    return type('Bar', (Foo,), {'name': name})

But then if the user needs to actually subclass Foo, to add additional
methods that is more difficult. Of course those methods could be added as
part of the third argument to types but that just doesn't feel very Python.

This is all complicated by the fact that I am trying to avoid actually
instancating any of these classes because their purpose is to be passed off
to another framework to be executed. In real life most of the classes would
fail to instantiate because they are relying on pieces of the framework
that won't be up and running when this setup is happening.

The solution I am hoping for is something like
Foo(name, **kwds) -> Returns new class type of name
For example
test = Foo('test')

So that then optionally a user could do

class UserClass(Foo):
    def new_method():
        pass
bar = UserClass('Bar')

Or something similar. Since I have a working example with type I feel like
there should be a way to do this with the normal class structure but I am
at a loss for how I have messed with the __new__ and __prepare__ methods
and I can't seem to make anything work and the examples of meta classes
don't clearly show how to convert my type example to a class structure.

Is what I want to do possible?

Chris

From dieter at handshake.de  Sun Jul 23 13:01:31 2023
From: dieter at handshake.de (Dieter Maurer)
Date: Sun, 23 Jul 2023 19:01:31 +0200
Subject: Meta Class Maybe?
In-Reply-To: <CALGOvYYdCaa9HCSrFpc=M=vT5oKiR=UKfQyjP75PRph2jpCmKA@mail.gmail.com>
References: <CALGOvYYdCaa9HCSrFpc=M=vT5oKiR=UKfQyjP75PRph2jpCmKA@mail.gmail.com>
Message-ID: <25789.23787.356219.706259@ixdm.fritz.box>

Chris Nyland wrote at 2023-7-22 19:12 -0400:
>So I am stuck on a problem. I have a class which I want to use to create
>another class without having to go through the boiler plate of subclassing.

Do you know about `__init_subclass__`?
It is called whenever a class is subclassed and can be used to
check/update the newly created class.

From lal at solute.de  Mon Jul 24 05:11:39 2023
From: lal at solute.de (Lars Liedtke)
Date: Mon, 24 Jul 2023 11:11:39 +0200
Subject: pip-sync
Message-ID: <73de4385-7355-484a-9490-bdccb71be851@solute-exc2019.solute.ka>

This email contains a secure message that can be read by opening the attachment.





Lars Liedtke
Senior Software Developer

[Tel.]
[Fax]   +49 721 98993-
[E-Mail]        lal at solute.de<mailto:lal at solute.de>


solute gmbh
Zeppelinstra?e 15
76185 Karlsruhe
Germany


[Logo Solute]

Marken der solute gmbh | brands of solute gmbh
[Marken]

Triff uns auf der DMEXCO am 20. und 21. September in K?ln und sichere dir die Chance auf eine brandneue Apple-Watch bei unserer Live-Auslosung!
Vereinbare hier einen Termin mit uns: https://outlook.office365.com/owa/calendar/solutedmexco at o365.solute.de/bookings/

[dmexco Banner]<https://outlook.office365.com/owa/calendar/solutedmexco at o365.solute.de/bookings/>

Gesch?ftsf?hrer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de <http://www.solute.de/>
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798



Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php

-------------- next part --------------
An embedded message was scrubbed...
From: Lars Liedtke <lal at solute.de>
Subject: Re: pip-sync
Date: Mon, 24 Jul 2023 11:11:34 +0200
Size: 22004
URL: <https://mail.python.org/pipermail/python-list/attachments/20230724/d545a399/attachment.mht>

From lal at solute.de  Mon Jul 24 05:30:05 2023
From: lal at solute.de (Lars Liedtke)
Date: Mon, 24 Jul 2023 11:30:05 +0200
Subject: pip-sync
In-Reply-To: <CACwCsY7YpAxCg-pYNAJr_Z1cGfhCCafidvVzW_bQ6R0GND2ihQ@mail.gmail.com>
References: <CACwCsY7YpAxCg-pYNAJr_Z1cGfhCCafidvVzW_bQ6R0GND2ihQ@mail.gmail.com>
Message-ID: <ff1ba501-8f58-adae-b97c-93df3cf8aeb2@solute.de>

Did maybe pip-sync create the venv with --system-site-packages (at least that's the commandline option for pip)

I only saw behaviour like this so far, when my venv was with --system-site-packages and a package was installed by the system.

Sorry for the first mess.
Cheers

Lars


Lars Liedtke
Senior Software Developer

[Tel.]
[Fax]   +49 721 98993-
[E-Mail]        lal at solute.de<mailto:lal at solute.de>


solute gmbh
Zeppelinstra?e 15
76185 Karlsruhe
Germany


[Logo Solute]

Marken der solute gmbh | brands of solute gmbh
[Marken]

Triff uns auf der DMEXCO am 20. und 21. September in K?ln und sichere dir die Chance auf eine brandneue Apple-Watch bei unserer Live-Auslosung!
Vereinbare hier einen Termin mit uns: https://outlook.office365.com/owa/calendar/solutedmexco at o365.solute.de/bookings/

[dmexco Banner]<https://outlook.office365.com/owa/calendar/solutedmexco at o365.solute.de/bookings/>

Gesch?ftsf?hrer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de <http://www.solute.de/>
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798



Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php


Am 21.07.23 um 20:08 schrieb Larry Martell via Python-list:

I am trying to set up and maintain a venv with pip-sync. On my bare
metal I have the apparmor python package installed, but it is not
installed in my venv and it's not in my requirements file. When I run
pip-sync I get:

Found existing installation: apparmor 2.13.3
ERROR: Cannot uninstall 'apparmor'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.

Since it's not installed in the venv why does it want to uninstall it?


From larry.martell at gmail.com  Mon Jul 24 10:26:40 2023
From: larry.martell at gmail.com (Larry Martell)
Date: Mon, 24 Jul 2023 07:26:40 -0700
Subject: pip-sync
In-Reply-To: <CACwCsY7YpAxCg-pYNAJr_Z1cGfhCCafidvVzW_bQ6R0GND2ihQ@mail.gmail.com>
References: <CACwCsY7YpAxCg-pYNAJr_Z1cGfhCCafidvVzW_bQ6R0GND2ihQ@mail.gmail.com>
Message-ID: <CACwCsY61VL7ahjcO-3czgxe7CnnhCw+y+AiNLOsXiKGkRXAp_w@mail.gmail.com>

On Fri, Jul 21, 2023 at 11:08?AM Larry Martell <larry.martell at gmail.com> wrote:
>
> I am trying to set up and maintain a venv with pip-sync. On my bare
> metal I have the apparmor python package installed, but it is not
> installed in my venv and it's not in my requirements file. When I run
> pip-sync I get:
>
> Found existing installation: apparmor 2.13.3
> ERROR: Cannot uninstall 'apparmor'. It is a distutils installed
> project and thus we cannot accurately determine which files belong to
> it which would lead to only a partial uninstall.
>
> Since it's not installed in the venv why does it want to uninstall it?

Found out what was going on - I had pip-sync installed on the bare
metal and when I ran it from within the venv it was picking that one
up, which then looked at packages outside the venv. After I
uninstalled it from the bare metal it was then working as expected.

From dom.grigonis at gmail.com  Sat Jul 22 19:29:01 2023
From: dom.grigonis at gmail.com (Dom Grigonis)
Date: Sun, 23 Jul 2023 02:29:01 +0300
Subject: Meta Class Maybe?
In-Reply-To: <CALGOvYYdCaa9HCSrFpc=M=vT5oKiR=UKfQyjP75PRph2jpCmKA@mail.gmail.com>
References: <CALGOvYYdCaa9HCSrFpc=M=vT5oKiR=UKfQyjP75PRph2jpCmKA@mail.gmail.com>
Message-ID: <8950458D-793D-4004-9AD5-5C58BBA689C2@gmail.com>



> On 23 Jul 2023, at 02:12, Chris Nyland via Python-list <python-list at python.org> wrote:
> 
> So I am stuck on a problem. I have a class which I want to use to create
> another class without having to go through the boiler plate of subclassing.
> Specifically because the subclass needs to have certain class attributes
> and I would like to control how those are passed to provide defaults and
> such. What I have working right now is

> class Foo():
>    @classmethod
>    def method_a(cls): print(cls.name)
> 
> Bar = type('Bar', (Foo,), {'name': 'test1?})


Could you write a more expressive example of what you are trying to do and what the problem actually is?

The way you wrote the above doesn?t contain any clues why usual subclassing is not appropriate.

By attributes you mean value attributes or methods? Why going the usual route of subclassing & controlling their behaviour via constructor arguments isn?t working?

> This is sort of fine but the user needs to know how to call type and
> include all the base classes etc.


I don?t get what you mean by this either. Very hard to follow everything that went after, given I was lost at this point.

Maybe it?s only me... But I if you clarified these, I might be able to help a bit.

DG

From chris at upliftinglemma.net  Mon Jul 24 22:59:17 2023
From: chris at upliftinglemma.net (Chris Bouchard)
Date: Mon, 24 Jul 2023 22:59:17 -0400
Subject: Odd types.get_original_bases() behavior for classes with generic
 bases but no type arguments
Message-ID: <CAFmgF4VuXLP3NAyShRcODftcayiysO3A3Dq=yy-ufLEcFk-cuw@mail.gmail.com>

(Apologies if this has already been discussed. I tried to search and didn't find
anything relevant.)

I was playing around with 3.12.0b4 this evening and noticed an odd (to me, at
least) behavior with types.get_original_bases(). I hesitate to call it a bug
because I think I understand *why* it's behaving this way?I'm just not sure it's
desirable.


>>> T = typing.TypeVar("T")
>>> class FirstBase(typing.Generic[T]):
...     pass
...
>>> class SecondBase(typing.Generic[T]):
...     pass
...
>>> class First(FirstBase[int]):
...     pass
...
>>> class Second(SecondBase[int]):
...     pass
...
>>> class Example(First, Second):
...     pass
...
>>> types.get_original_bases(Example)
(FirstBase[int],)
>>> Example.__bases__
(First, Second)
>>> types.get_original_bases(First)
(FirstBase[int],)

In other words, types.get_original_bases(Example) is returning the original base
types for First, rather than its own.

I believe this happens because __orig_bases__ is only set when one or more bases
are not types. In this case both bases are types, so Example doesn't get its own
__orig_bases__. Then when types.get_original_bases() tries to get __orig_bases__
with getattr(cls, "__orig_bases__") or something morally equivalent, it searches
the MRO and finds __orig_bases__ on First.

The same thing also happens if all the bases are "bare" generic types.

>>> class First(typing.Generic[T]):
...     pass
...
>>> class Second(typing.Generic[T]):
...     pass
...
>>> class Example(First, Second):
...     pass
...
>>> types.get_original_bases(Example)
(typing.Generic[~T],)

As I said, I'm not clear if this is a bug, or just an unfortunate but intended
behavior. I would personally expect types.get_original_bases() to check if the
type has its *own* __orig_bases__ attribute, and to fall back to __bases__
otherwise. The way it works today makes it unnecessarily difficult to write a
function that, for example, recurses down a type's inheritance tree inspecting
the original bases?I currently have to work around this behavior via hacks like
checking "__orig_bases__" in cls.__dict__ or any(types.get_original_bases(cls)
== types.get_original_bases(base) for base in cls.__bases__). (Unless I'm
missing some simpler solution.)

Is this something that could (should?) be addressed before 3.12 lands?

Thanks,
Chris Bouchard

From chris at upliftinglemma.net  Mon Jul 24 23:10:38 2023
From: chris at upliftinglemma.net (Chris Bouchard)
Date: Mon, 24 Jul 2023 23:10:38 -0400
Subject: Odd types.get_original_bases() behavior for classes with generic
 bases but no type arguments
In-Reply-To: <CAFmgF4VuXLP3NAyShRcODftcayiysO3A3Dq=yy-ufLEcFk-cuw@mail.gmail.com>
References: <CAFmgF4VuXLP3NAyShRcODftcayiysO3A3Dq=yy-ufLEcFk-cuw@mail.gmail.com>
Message-ID: <CAFmgF4UkEAWHB=WqfpgpKgRGqe5c0uAbJY=x7oqDCj5OYNoGrg@mail.gmail.com>

> >>> Example.__bases__
> (First, Second)

Sorry, that should have been

>>> Example.__bases__
(<class '__main__.First'>, <class '__main__.Second'>)

That's what I get for writing an example from memory rather than copying it from
a REPL session. It doesn't change the point I wanted to make, though.

Thanks,
Chris Bouchard

From dom.grigonis at gmail.com  Tue Jul 25 22:22:18 2023
From: dom.grigonis at gmail.com (Dom Grigonis)
Date: Wed, 26 Jul 2023 05:22:18 +0300
Subject: Fallback for operator and other dunder methods
Message-ID: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>

To illustrate what I was trying to achieve:

class A:
    def __init__(self, arr):
        self.arr = arr

    def __getattr__(self, name):
        arr_method = getattr(self.arr, name)
        def wrapper(*args, **kwargs):
            new_arr = arr_method(*args, **kwargs)
            return type(self)(new_arr)
        return wrapper

a = A(np.ones((1, 1)))
print(a.sum().arr)      # 1
print(a + 1)            # TypeError: unsupported operand type(s) for +: 'A' and 'int'

Is there a way to achieve it without actually implementing operators?
I have looked at Proxy objects, but they do not seem suited to achieve this. (e.g. wrapt)

If there is no way to do this, wouldn?t it be sensible to have a new method, say ?__getattrspecial__?? Either with ability to customise for which operators it is being called or not.


?Nothing ever dies, just enters the state of deferred evaluation?
Dg


From rosuav at gmail.com  Wed Jul 26 02:40:20 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 26 Jul 2023 16:40:20 +1000
Subject: Fallback for operator and other dunder methods
In-Reply-To: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
References: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
Message-ID: <CAPTjJmoRd8psQmC+urJAE5QRM8st3_ihv3v8ODQNjRLEiPHfRA@mail.gmail.com>

On Wed, 26 Jul 2023 at 12:23, Dom Grigonis via Python-list
<python-list at python.org> wrote:
> print(a + 1)            # TypeError: unsupported operand type(s) for +: 'A' and 'int'
>
> Is there a way to achieve it without actually implementing operators?
> I have looked at Proxy objects, but they do not seem suited to achieve this. (e.g. wrapt)

These kinds of special methods are not looked up on the object, but on
the type. It's more like type(a).__add__(a, 1). So you would need a
metaclass for this.

ChrisA

From dom.grigonis at gmail.com  Wed Jul 26 02:52:48 2023
From: dom.grigonis at gmail.com (Dom Grigonis)
Date: Wed, 26 Jul 2023 09:52:48 +0300
Subject: Fallback for operator and other dunder methods
In-Reply-To: <CAPTjJmoRd8psQmC+urJAE5QRM8st3_ihv3v8ODQNjRLEiPHfRA@mail.gmail.com>
References: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
 <CAPTjJmoRd8psQmC+urJAE5QRM8st3_ihv3v8ODQNjRLEiPHfRA@mail.gmail.com>
Message-ID: <333FA876-8F7B-42D1-BD5C-6AEB07EE03BB@gmail.com>

Could you give an example? Something isn?t working for me.

> On 26 Jul 2023, at 09:40, Chris Angelico via Python-list <python-list at python.org> wrote:
> 
> On Wed, 26 Jul 2023 at 12:23, Dom Grigonis via Python-list
> <python-list at python.org> wrote:
>> print(a + 1)            # TypeError: unsupported operand type(s) for +: 'A' and 'int'
>> 
>> Is there a way to achieve it without actually implementing operators?
>> I have looked at Proxy objects, but they do not seem suited to achieve this. (e.g. wrapt)
> 
> These kinds of special methods are not looked up on the object, but on
> the type. It's more like type(a).__add__(a, 1). So you would need a
> metaclass for this.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list


From rosuav at gmail.com  Wed Jul 26 03:01:38 2023
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 26 Jul 2023 17:01:38 +1000
Subject: Fallback for operator and other dunder methods
In-Reply-To: <333FA876-8F7B-42D1-BD5C-6AEB07EE03BB@gmail.com>
References: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
 <CAPTjJmoRd8psQmC+urJAE5QRM8st3_ihv3v8ODQNjRLEiPHfRA@mail.gmail.com>
 <333FA876-8F7B-42D1-BD5C-6AEB07EE03BB@gmail.com>
Message-ID: <CAPTjJmok3z54bFSAD5-pSr0ff8aMKruxn95q+nENM5cjDeoePg@mail.gmail.com>

On Wed, 26 Jul 2023 at 16:52, Dom Grigonis <dom.grigonis at gmail.com> wrote:
>
> Could you give an example? Something isn?t working for me.
>

This is a metaclass:

class Meta(type):
    ...
class Demo(metaclass=Meta):
    ...

In order to catch those kinds of attribute lookups, you'll need the
metaclass to hook them. And you might need to use __getattribute__
rather than __getattr__. However, there may also be some checks that
simply look for the presence of the attribute (see: slots), so you may
find that it's even more complicated. It's usually easiest to just
create the slots you want.

ChrisA

From dieter at handshake.de  Wed Jul 26 14:01:09 2023
From: dieter at handshake.de (Dieter Maurer)
Date: Wed, 26 Jul 2023 20:01:09 +0200
Subject: Fallback for operator and other dunder methods
In-Reply-To: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
References: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
Message-ID: <25793.24421.576514.801246@ixdm.fritz.box>

Dom Grigonis wrote at 2023-7-26 05:22 +0300:
> ...
>Is there a way to achieve it without actually implementing operators?
>I have looked at Proxy objects, but they do not seem suited to achieve this.

Proxying is a good approach:
you might have a look at `dm.reuse.proxy.OverridingProxy` (--> `dm.reuse`
on PyPI).

From dom.grigonis at gmail.com  Wed Jul 26 14:35:25 2023
From: dom.grigonis at gmail.com (Dom Grigonis)
Date: Wed, 26 Jul 2023 21:35:25 +0300
Subject: Fallback for operator and other dunder methods
In-Reply-To: <CAPTjJmok3z54bFSAD5-pSr0ff8aMKruxn95q+nENM5cjDeoePg@mail.gmail.com>
References: <2D6F0153-5FAE-49A1-A5B0-23CF9AAED4E7@gmail.com>
 <CAPTjJmoRd8psQmC+urJAE5QRM8st3_ihv3v8ODQNjRLEiPHfRA@mail.gmail.com>
 <333FA876-8F7B-42D1-BD5C-6AEB07EE03BB@gmail.com>
 <CAPTjJmok3z54bFSAD5-pSr0ff8aMKruxn95q+nENM5cjDeoePg@mail.gmail.com>
Message-ID: <9EB0B006-9309-42EE-8D60-A6EF12B0B1BF@gmail.com>

Tried exactly that and didn?t work. Neither __getattr__, nor __getattribute__ of meta is being invoked.

> On 26 Jul 2023, at 10:01, Chris Angelico via Python-list <python-list at python.org> wrote:
> 
> On Wed, 26 Jul 2023 at 16:52, Dom Grigonis <dom.grigonis at gmail.com> wrote:
>> 
>> Could you give an example? Something isn?t working for me.
>> 
> 
> This is a metaclass:
> 
> class Meta(type):
>    ...
> class Demo(metaclass=Meta):
>    ...
> 
> In order to catch those kinds of attribute lookups, you'll need the
> metaclass to hook them. And you might need to use __getattribute__
> rather than __getattr__. However, there may also be some checks that
> simply look for the presence of the attribute (see: slots), so you may
> find that it's even more complicated. It's usually easiest to just
> create the slots you want.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list