Op 4/12/2024 om 0:14 schreef Greg Ewing via Python-list:
On 4/12/24 3:24 am, Roel Schroeven wrote:
It's not entirely clear to me though how bytes.__new__ *can* set an
object's value. Isn't __new__ also a regular function?
Yes, but the __new__ methods of the builtin immutable objects (int,
str,
On 4/12/24 3:24 am, Roel Schroeven wrote:
It's not entirely clear to me though how bytes.__new__ *can* set an
object's value. Isn't __new__ also a regular function?
Yes, but the __new__ methods of the builtin immutable objects (int,
str, bytes, etc.) are implemented in C, and so are able to do
Op 3/12/2024 om 13:55 schreef Anders Munch via Python-list:
Roel Schroeven wrote:
> As a follow-up, it looks like this behavior is because bytes and int are
immutable.
Yes.
OK.
> But that doesn't tell me why using super().__init__()
doesn't work for immutable classes.
byt
Roel Schroeven wrote:
> As a follow-up, it looks like this behavior is because bytes and int are
> immutable.
Yes.
> But that doesn't tell me why using super().__init__()
> doesn't work for immutable classes.
bytes.__init__ does work, but it's just an inherited o
self, data):
super().__init__(data)
print(MyBytes(b'abcdefghijlkmn'))
This results in an exception:
Traceback (most recent call last):
File "test_mybytes.py", line 4, in
print(MyBytes(b'abcdefghijlkmn'))
^^
File "test_mybytes.
We can use super().__init__() in the __init__() method of a derived
class to initialize its base class. For example:
import string
class MyTemplate(string.Template):
def __init__(self, template_string):
super().__init__(template_string)
print(MyTemplate('Hello ${name}').
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 discus
/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
-
On Wed, 5 Jul 2023 at 10:31, Greg Ewing via Python-list
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
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 construc
> > 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 exp
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
abo
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).
On Tue, 4 Jul 2023 at 22:06, Peter Slížik via Python-list
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
>
> 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 f
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 twic
On Tue, 4 Jul 2023 at 03:39, 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 wri
. 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 replace
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
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
On 23Sep2021 20:38, Mohsen Owzar wrote:
I'm writing since almost one-year codes in Python, using TKinter and
PyQt5.
I'm somehow able to writes GUIs in both of them.
But since I'm using more Pyqt5 and using classes with initialization and
super() constructs, and also I saw lot
Those are contradictory for what you are trying to accomplish unless it is a
Parent - Child relationship (MainWindow - Window):
When you super() an object, it enherits all the properties from its parent
object.
Source:
https://www.w3schools.com/python/python_inheritance.asp
If what you want
On 10/02/2022 09:20, Igor Basko wrote:
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example class B and class C inherit from A
Hi Guys
I'm writing since almost one-year codes in Python, using TKinter and PyQt5.
I'm somehow able to writes GUIs in both of them.
But since I'm using more Pyqt5 and using classes with initialization and
super() constructs, and also I saw lots of videos and examples of coding
On 12/02/2021 02:39, Andras Tantos wrote:
> 1. Ports, which are the connection points on the various netlist
> entities. These would be the inputs and outputs of an AND gate for example
>
> 2. NetTypes, which describe the type of data that can travel through a
> net (and thus through a Port). O
change the __class__ of the port
object at run time to a subclass of Port having the required
features. That would be a lot easier and more efficient than
adding individual methods to every Port instance, and super()
should work normally.
That's actually a pretty good idea, thanks! Let me turn it aro
time to a subclass of Port having the required
features. That would be a lot easier and more efficient than
adding individual methods to every Port instance, and super()
should work normally.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On 2/11/21 1:43 PM, Greg Ewing wrote:
On 12/02/21 7:05 am, Andras Tantos wrote:
a = B()
a.m(41)
a.m = MethodType(method, a)
a.m(42)
Are you sure you really need to inject methods into instances
like this? What problem are you trying to solve by doing so?
There's almost ce
owing code:
from types import MethodType
class A(object):
pass
def m(self, x):
print(f"A.m({x})")
class B(A):
def m(self, x):
print(f"B.m({x})")
ss = super()
ss.m(x)
def method(self, s):
print(f"method({s})")
try:
ss = super() # <-- Complains about __class__
On 12/02/21 7:05 am, Andras Tantos wrote:
a = B()
a.m(41)
a.m = MethodType(method, a)
a.m(42)
Are you sure you really need to inject methods into instances
like this? What problem are you trying to solve by doing so?
There's almost certainly a better way to approach it.
--
pe
>
> class A(object):
> pass
> def m(self, x):
> print(f"A.m({x})")
> class B(A):
> def m(self, x):
> print(f"B.m({x})")
> ss = super()
> ss.m(x)
&
uot;A.m({x})")
class B(A):
def m(self, x):
print(f"B.m({x})")
ss = super()
ss.m(x)
def method(self, s):
print(f"method({s})")
try:
ss = super() # <-- Complains about __class__ cell not being
found
On Sat, Apr 25, 2020 at 4:20 AM Random832 wrote:
>
> On Fri, Apr 24, 2020, at 02:10, Cecil Westerhof wrote:
> > issubclass(bool, int) gives True
> > but
> > super(bool) gives
> >
> > Do I not understand the meaning of super, or is this inconsistent?
>
&g
On Fri, Apr 24, 2020, at 02:10, Cecil Westerhof wrote:
> issubclass(bool, int) gives True
> but
> super(bool) gives
>
> Do I not understand the meaning of super, or is this inconsistent?
I've never heard of a one-argument form for super, but I just tried something
and no
Cecil Westerhof writes:
>> I've never actually looked at the repr of a super object - I've always
>> just called a method on it immediately after constructing it. Never
>> seen a need to hang onto one :)
>
> Well, maybe I will never need it, but I am just cu
Chris Angelico writes:
> On Fri, Apr 24, 2020 at 4:16 PM Cecil Westerhof wrote:
>>
>> issubclass(bool, int) gives True
>> but
>> super(bool) gives
>>
>> Do I not understand the meaning of super, or is this inconsistent?
>>
>> (Until n
On Fri, Apr 24, 2020 at 4:16 PM Cecil Westerhof wrote:
>
> issubclass(bool, int) gives True
> but
> super(bool) gives
>
> Do I not understand the meaning of super, or is this inconsistent?
>
> (Until now I have not down much work with classes in Python.)
>
One-arg
issubclass(bool, int) gives True
but
super(bool) gives
Do I not understand the meaning of super, or is this inconsistent?
(Until now I have not down much work with classes in Python.)
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https
I think this should help
https://stackoverflow.com/questions/1779372/python-metaclasses-vs-class-decorators
On Sat, 4 Apr, 2020, 6:12 pm Antoon Pardon,
wrote:
> Op 29/03/20 om 16:49 schreef Peter Otten:
> > Antoon Pardon wrote:
> >
> >>
> >> I have the following program
> >>
> >> class slt:
> >>
Op 29/03/20 om 16:49 schreef Peter Otten:
> Antoon Pardon wrote:
>
>>
>> I have the following program
>>
>> class slt:
>> __slots__ = ()
>>
...
>>
>> class slt1 (slt):
>> __slots__ = 'fld1', 'fld2'
>>
...
>>
>> class slt2(slt1):
>> __slots__ = 'fld3',
>>
> Anyway, here's my attempt to
Antoon Pardon wrote:
>
> I have the following program
>
> class slt:
> __slots__ = ()
>
> def getslots(self):
> print("### slots =", self.__slots__)
> if self.__slots__ == ():
> return []
> else:
> ls = super().getslots()
> ls.extend(self.__
I have the following program
class slt:
__slots__ = ()
def getslots(self):
print("### slots =", self.__slots__)
if self.__slots__ == ():
return []
else:
ls = super(
it took me a while to figure out what was
happening here myself!
I think the problem is that the act of looking up __getattribute__
on the super object invokes the super object's magic lookup
machinery, and ends up giving a misleading result.
It's clearer if you look for __getattribu
int out with the same address and pass an equality comparison. That
implies that they are the same, and that the super type is NOT doing something
special with that slot.
Given that super().__getattribute__ internally ultimately should be something
else, I am guessing there is something else at p
On 11/03/20 7:02 am, Adam Preble wrote:
Is this foo attribute being looked up in an override of __getattr__,
__getattribute__, or is it a reserved slot that's internally doing this? That's
what I'm trying to figure out.
Looking at the source in Objects/typeobject.c, it uses the
tp_getattro ty
On Tuesday, March 10, 2020 at 9:28:11 AM UTC-5, Peter Otten wrote:
> self.foo looks up the attribute in the instance, falls back to the class and
> then works its way up to the parent class, whereas
>
> super().foo bypasses both instance and class, and starts its lookup in the
&g
> On 4 Mar 2020, at 17:12, Adam Preble wrote:
>
> Months ago, I asked a bunch of stuff about super() and managed to fake it
> well enough to move on to other things for awhile. The day of reckoning came
> this week and I was forced to implement it better for my personal Pytho
Adam Preble wrote:
> If you don't know, you can trap what super() returns some time and poke it
> with a stick. If you print it you'll be able to tell it's definitely
> unique: , >
>
> If you try to invoke methods on it, it'll invoke the superclass' m
On Monday, March 9, 2020 at 9:31:45 PM UTC-5, Souvik Dutta wrote:
> This should be what you are looking for.
> https://python-reference.readthedocs.io/en/latest/docs/functions/super.html
I'm not trying to figure out how the super() function works, but rather the
anatomy of the object
This should be what you are looking for.
https://python-reference.readthedocs.io/en/latest/docs/functions/super.html
On Tue, 10 Mar, 2020, 5:50 am Adam Preble, wrote:
> On Wednesday, March 4, 2020 at 11:13:20 AM UTC-6, Adam Preble wrote:
> > Stuff
>
> I'm speculating that the stuff I don't see w
On Wednesday, March 4, 2020 at 11:13:20 AM UTC-6, Adam Preble wrote:
> Stuff
I'm speculating that the stuff I don't see when poking are reserved slots. I
figured out how much of a thing that is when I was digging around for how
classes know how to construct themselves. I managed to figure out __
Months ago, I asked a bunch of stuff about super() and managed to fake it well
enough to move on to other things for awhile. The day of reckoning came this
week and I was forced to implement it better for my personal Python project. I
have a hack in place that makes it work well-enough but I
lass/instance-name-ref
>
> Note that he's receiving instance-references
>
> therefore when I start sub-classing a property why does he then switch to
> class-references/class-variables
If you were subclassing a property you'd do
class my_property(property):
# tinker
you've misunderstood my question, let me try again:
So this is a simple descriptor class and as you can see, dunder-set needs
3 args: the descriptor CONTAINER/Bar-instance is the first arg, then a
reference to the using instance/Foo-instance
class Bar(object):
def __set__(self, instanc
t; print('Foo', name)
>
> class Baz(Foo):
> @property
> def name(self):
> print('Baz wrapper around getter')
> return super().name
>
> @Foo.name.setter
This looks like a bug as the read-only property defined abov
#x27;Foo', self)
self._name = value
print(self._name)
@name.deleter
def name(self):
print('del')
self._name = None
print('Foo', name)
class Baz(Foo):
@property
def name(self):
pr
On 25/10/19 4:29 AM, Frank Millman wrote:
On 2019-10-19 12:37 AM, DL Neil via Python-list wrote:
On 16/10/19 6:33 PM, Frank Millman wrote:
On 2019-10-14 10:55 PM, DL Neil via Python-list wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-crea
On 2019-10-19 12:37 AM, DL Neil via Python-list wrote:
On 16/10/19 6:33 PM, Frank Millman wrote:
On 2019-10-14 10:55 PM, DL Neil via Python-list wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-c
On 18/10/2019 23:57, DL Neil wrote:
> On 17/10/19 7:52 AM, MRAB wrote:
>> On 2019-10-16 19:43, duncan smith wrote:
>>> On 16/10/2019 04:41, DL Neil wrote:
On 16/10/19 1:55 PM, duncan smith wrote:
> On 15/10/2019 21:36, DL Neil wrote:
>> On 16/10/19 12:38 AM, Rhodri James wrote:
>>>
On 18/10/19 9:27 AM, Eryk Sun wrote:
On 10/17/19, MRAB wrote:
On 2019-10-17 20:06, Eryk Sun wrote:
I'm bugged by how the article mis-characterizes the fundamental
problem. The operating system has nothing to do with the order of a
directory listing, which varies even with an OS, depending on
On 17/10/19 7:52 AM, MRAB wrote:
On 2019-10-16 19:43, duncan smith wrote:
On 16/10/2019 04:41, DL Neil wrote:
On 16/10/19 1:55 PM, duncan smith wrote:
On 15/10/2019 21:36, DL Neil wrote:
On 16/10/19 12:38 AM, Rhodri James wrote:
On 14/10/2019 21:55, DL Neil via Python-list wrote:
...
So, ye
On 17/10/19 4:08 AM, Piet van Oostrum wrote:
DL Neil writes:
That said, if a "trans" person has ovaries or testes (for example) then
a non-traditional sexual identification is irrelevant - for medical
purposes. Diseases in those areas (and now I'm a long way from a
research questionnaire and f
On 16/10/19 6:33 PM, Frank Millman wrote:
On 2019-10-14 10:55 PM, DL Neil via Python-list wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-classes?
Here is a link to an article entitled 'Underst
On 10/17/19, MRAB wrote:
> On 2019-10-17 20:06, Eryk Sun wrote:
>
>> I'm bugged by how the article mis-characterizes the fundamental
>> problem. The operating system has nothing to do with the order of a
>> directory listing, which varies even with an OS, depending on the file
>> system. The latte
On 2019-10-17 20:06, Eryk Sun wrote:
On 10/17/19, Dennis Lee Bieber wrote:
On Wed, 16 Oct 2019 19:52:50 +0100, MRAB
declaimed the following:
Researchers find bug in Python script may have affected hundreds of
studies
https://arstechnica.com/information-technology/2019/10/chemists-discover-cr
On 10/17/19, Dennis Lee Bieber wrote:
> On Wed, 16 Oct 2019 19:52:50 +0100, MRAB
> declaimed the following:
>
>>Researchers find bug in Python script may have affected hundreds of
>> studies
>>https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-n
On 2019-10-16 7:33 AM, Frank Millman wrote:
Here is a link to an article entitled 'Understanding Hidden Subtypes'.
It dates back to 2004, but I think it is still relevant. It addresses
precisely the issues that you raise, but from a data-modelling
perspective, not a programming one.
http://
On 16/10/2019 19:52, MRAB wrote:
> On 2019-10-16 19:43, duncan smith wrote:
>> On 16/10/2019 04:41, DL Neil wrote:
>>> On 16/10/19 1:55 PM, duncan smith wrote:
On 15/10/2019 21:36, DL Neil wrote:
> On 16/10/19 12:38 AM, Rhodri James wrote:
>> On 14/10/2019 21:55, DL Neil via Python-lis
> On 14 Oct 2019, at 21:55, DL Neil via Python-list
> wrote:
>
> Is there a technique or pattern for taking a (partially-) populated instance
> of a class, and re-creating it as an instance of one of its sub-classes?
The pattern I know is to use a factory function to choose between a number
On 2019-10-16 19:43, duncan smith wrote:
On 16/10/2019 04:41, DL Neil wrote:
On 16/10/19 1:55 PM, duncan smith wrote:
On 15/10/2019 21:36, DL Neil wrote:
On 16/10/19 12:38 AM, Rhodri James wrote:
On 14/10/2019 21:55, DL Neil via Python-list wrote:
...
So, yes, the "label" is unimportant - ex
On 16/10/2019 04:41, DL Neil wrote:
> On 16/10/19 1:55 PM, duncan smith wrote:
>> On 15/10/2019 21:36, DL Neil wrote:
>>> On 16/10/19 12:38 AM, Rhodri James wrote:
On 14/10/2019 21:55, DL Neil via Python-list wrote:
>>> ...
>>> So, yes, the "label" is unimportant - except to politicians and
>>
DL Neil writes:
> That said, if a "trans" person has ovaries or testes (for example) then
> a non-traditional sexual identification is irrelevant - for medical
> purposes. Diseases in those areas (and now I'm a long way from a
> research questionnaire and from Python - but this is roughly how it
On 2019-10-14 10:55 PM, DL Neil via Python-list wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-classes?
In a medically-oriented situation, we have a Person() class, and start
collecting infor
On 16/10/19 1:55 PM, duncan smith wrote:
On 15/10/2019 21:36, DL Neil wrote:
On 16/10/19 12:38 AM, Rhodri James wrote:
On 14/10/2019 21:55, DL Neil via Python-list wrote:
...
So, yes, the "label" is unimportant - except to politicians and
statisticians, who want precise answers from vague coll
On 15/10/2019 21:36, DL Neil wrote:
> On 16/10/19 12:38 AM, Rhodri James wrote:
>> On 14/10/2019 21:55, DL Neil via Python-list wrote:
> ...
>
>>> It seemed better (at the design-level) to have Man( Person ) and
>>> Woman( Person ) sub-classes to contain the pertinent attributes,
>>> source more d
On 16/10/19 12:38 AM, Rhodri James wrote:
On 14/10/2019 21:55, DL Neil via Python-list wrote:
...
It seemed better (at the design-level) to have Man( Person ) and
Woman( Person ) sub-classes to contain the pertinent attributes,
source more detailed and specific questions, and collect such dat
On 14/10/2019 21:55, DL Neil via Python-list wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-classes?
In a medically-oriented situation, we have a Person() class, and start
collecting informat
Person-instance is 'converted'* into a Male-instance,
then Male.__init__() will not be executed.
(haven't bothered to experiment with an explicit call, because...)
In this case, that is not an issue, because apart from the value of
"sex", the __init__() actions
DL Neil wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-classes?
Often you can assign to the __class__ attribute of an instance
to change its class.
Python 3.7.3 (default, Apr 8 2019, 22:20:19
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-classes?
In a medically-oriented situation, we have a Person() class, and start
collecting information within an instance (person = Person(), etc).
Du
On 16/07/19 10:08 PM, אורי wrote:
Hi,
1. When we use super() in Python 3, we don't pass it the first argument
(self). Why?
What happens if the first argument is not self?
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
I think it would make more sense t
Às 02:11 de 15/07/19, Chris Angelico escreveu:
> On Mon, Jul 15, 2019 at 10:51 AM Paulo da Silva
> wrote:
>>
...
>>
>> Thank you Jollans. I forgot multiple inheritance. I never needed it in
>> python, so far.
>>
>
> Something to consider is that sup
On Wed, Jul 17, 2019 at 3:58 AM Ian Kelly wrote:
>
> On Tue, Jul 16, 2019 at 1:21 AM Chris Angelico wrote:
> >
> > On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly wrote:
> > >
> > > Just using super() is not enough. You need to take steps if you want to
> >
On Tue, Jul 16, 2019 at 1:21 AM Chris Angelico wrote:
>
> On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly wrote:
> >
> > Just using super() is not enough. You need to take steps if you want to
> > ensure that you class plays nicely with MI. For example, consider the
> &g
suite(self, test_labels=None, *args, **kwargs):
...
return super().build_suite(test_labels=test_labels, *args, **kwargs)
>
> Thanks for your explanation. But I tried your code and it doesn't work
> (with Django==1.11.22):
>
>File "<...>\site-packages\djan
ase\test\models.py", line 35, in build_suite
return super().build_suite(test_labels=test_labels, *args, **kwargs)
TypeError: build_suite() got multiple values for argument 'test_labels'
אורי
u...@speedy.net
On Tue, Jul 16, 2019 at 3:13 PM Rhodri James wrote:
> Hi there! A
Hi there! A lot of the answers to your questions are at least implied
in the Fine Manual
(https://docs.python.org/3/library/functions.html#super), but it's not
very clear and written more for precision than comprehension. Here's my
attempt at explaining :-)
On 16/07/2019 11:08,
On 16/07/19 10:18, Chris Angelico wrote:
> On Tue, Jul 16, 2019 at 6:05 PM Antoon Pardon wrote:
>> On 16/07/19 09:18, Chris Angelico wrote:
>>> On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly wrote:
>>>> Just using super() is not enough. You need to take steps if you want
Hi,
1. When we use super() in Python 3, we don't pass it the first argument
(self). Why?
What happens if the first argument is not self?
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
I think it would make more sense to use something like
self.super().__init__(
On Tue, Jul 16, 2019 at 6:05 PM Antoon Pardon wrote:
>
> On 16/07/19 09:18, Chris Angelico wrote:
> > On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly wrote:
> >> Just using super() is not enough. You need to take steps if you want to
> >> ensure that you class pla
ans escreveu:
>>>>> On 12/07/2019 16.12, Paulo da Silva wrote:
>>>>>> Hi all!
>>>>>>
>>>>>> Is there any difference between using the base class name or super to
>>>>>> call __init__ from base class?
>>&
On 12/07/2019 16.12, Paulo da Silva wrote:
> > > >> Hi all!
> > > >>
> > > >> Is there any difference between using the base class name or super to
> > > >> call __init__ from base class?
> > > >
> > >
> > >> Is there any difference between using the base class name or super to
> > >> call __init__ from base class?
> > >
> > > There is, when multiple inheritance is involved. super() can call
> > > different 'branches' of the inhe
> On 12 Jul 2019, at 15:12, Paulo da Silva
> wrote:
>
> Hi all!
>
> Is there any difference between using the base class name or super to
> call __init__ from base class?
>
> class C1:
> def __init__(self):
> ...
>
>
On Mon, Jul 15, 2019 at 10:51 AM Paulo da Silva
wrote:
>
> Às 15:30 de 12/07/19, Thomas Jollans escreveu:
> > On 12/07/2019 16.12, Paulo da Silva wrote:
> >> Hi all!
> >>
> >> Is there any difference between using the base class name or super to
> >&
Às 16:20 de 12/07/19, Rhodri James escreveu:
> On 12/07/2019 15:12, Paulo da Silva wrote:
> ...
> super() also has major advantages if you are stuck with multiple
> inheritance. Raymond Hettinger has an excellent article on this here:
> https://rhettinger.wordpress.com/2
Às 15:30 de 12/07/19, Thomas Jollans escreveu:
> On 12/07/2019 16.12, Paulo da Silva wrote:
>> Hi all!
>>
>> Is there any difference between using the base class name or super to
>> call __init__ from base class?
>
> There is, when multiple inheritance is invol
On 12/07/2019 16.12, Paulo da Silva wrote:
> Hi all!
>
> Is there any difference between using the base class name or super to
> call __init__ from base class?
There is, when multiple inheritance is involved. super() can call
different 'branches' of the inheritance tree
On 12/07/2019 15:12, Paulo da Silva wrote:
Hi all!
Is there any difference between using the base class name or super to
call __init__ from base class?
class C1:
def __init__(self):
...
class C2(C1):
def __init__(self):
C1.__init__(self) or
1 - 100 of 819 matches
Mail list logo
