On Mon, Apr 13, 2020 at 06:43:53PM -0700, Caleb Donovick wrote:
> > Why can’t you just subclass dict and override that?
>
> Because TypeError: multiple bases have instance lay-out conflict is one of
> my least favorite errors.
For the benefit of the people on this list who aren't as familiar wit
>> On Apr 15, 2020, at 14:08, Caleb Donovick wrote:
>>
>> Besides performance, I don’t think it fits with Guido’s conception of the
>> protocols as being more minimal than the builtin types—e.g., set has not
>> just a & operator, but also an intersection method that takes 0 or more
>> arbitrar
On 4/15/2020 1:52 PM, Ricky Teachey wrote:
Therefore, it seems weird for __init__ not to call super.
I was not part of it, but I know this was heavily discussed during the
development of dataclasses prior to 3.7, and it was decided not to do
this, at least at THAT time (not saying that c
> Besides performance, I don’t think it fits with Guido’s conception of the
protocols as being more minimal than the builtin types—e.g., set has not
just a & operator, but also an intersection method that takes 0 or more
arbitrary iterables; the set protocol has no such method, so
collections.abc.S
Scanning the messages, I met this from Ricky Teachey:
I did write a decorator of my own that replaces the dataclass init with one
> that calls super().__init__(*args, **kwargs) first before proceeding with
> the one written by dataclasses... I can't find it at the moment. But that
> has its own pr
There is a way to have dataclasses as they are now behave collaboratively
with
a further decorator.
For Python 3.8 livefcycle such decorator could live in an external package
-
if its good, it could go into the stdlib, or maybe, another
"dataclasses.collaborative_dataclass" would already create a
On Apr 15, 2020, at 10:16, Brett Cannon wrote:
>
>
>> On Wed, Apr 15, 2020 at 8:45 AM Christopher Barker
>> wrote:
>> > you'd just add *args and **kwargs to the init signature and call
>> > super().__init__(*args, **kwargs).
>>>
>>> Which is what the OP is after.
>>
>> Hmm, makes me wonder
On Apr 15, 2020, at 12:11, Chris Angelico wrote:
>
> On Thu, Apr 16, 2020 at 4:55 AM Ander Juaristi wrote:
>> TLS session resumption is currently supported, but only within the same
>> process. To the best of my knowledge, there is no way to save the TLS
>> session to a file to resume the TLS s
On Thu, Apr 16, 2020 at 4:55 AM Ander Juaristi wrote:
> TLS session resumption is currently supported, but only within the same
> process. To the best of my knowledge, there is no way to save the TLS
> session to a file to resume the TLS session later on. Please tell me how
> this is done if I'm w
> I think ultimately the argument you want to make really is the
> “enlightened laziness” one: there are lots of optional Pandas-y parameters
> in your superclass(es), and most of them you will definitely never care
> about, but a few of them you actually might occasionally care about. What
> then?
> On Apr 15, 2020, at 10:48, Ricky Teachey wrote:
>
>>> It becomes more painful the more parameters the parent has- parameters
>>> which the dataclass may not even care about. It not only makes the class
>>> definition long, it adds so these additional parameters to the init
>>> signature, wh
Hi list,
I haven't seen this being discussed, but TL;DR I just want to propose to
extend the ssl module so that TLS session state can be serialized to disk.
I see a similar issue was being discussed here [0], but cannot tell why
it (apparently) didn't get into. The link to the patch is broken
>
> Therefore, it seems weird for __init__ not to call super.
>
I was not part of it, but I know this was heavily discussed during the
development of dataclasses prior to 3.7, and it was decided not to do this,
at least at THAT time (not saying that can't change, but there were
reasons). If Eric V
>
> It becomes more painful the more parameters the parent has- parameters
> which the dataclass may not even care about. It not only makes the class
> definition long, it adds so these additional parameters to the init
> signature, which is icky for introspection and discoverability. Lots of
> "Wh
I'm just curious: what is the downside of calling super with kwargs?
Usually when I define a class, the first I write is
def __init__(self, **kwargs):
super().__init__(**kwargs)
just in case I want to use the class in cooperative inheritance. I always
thought it couldn't hurt?
I might be a
> On Apr 15, 2020, at 04:26, Ricky Teachey wrote:
>
For simple situations you can call super in the __post_init__ method and
things will work fine:
>>>
>>> But not for the OP's case: he wanted to pass extra parameters in -- and the
>>> dataclass' __init__ won't accept extra argument
On Wed, Apr 15, 2020 at 8:45 AM Christopher Barker
wrote:
> > you'd just add *args and **kwargs to the init signature and call
> super().__init__(*args, **kwargs).
>
>>
>> Which is what the OP is after.
>>
>
> Hmm, makes me wonder if there should be an option to define a __pre_init__
> method.
>
> you'd just add *args and **kwargs to the init signature and call
super().__init__(*args, **kwargs).
>
> Which is what the OP is after.
>
Hmm, makes me wonder if there should be an option to define a __pre_init__
method.
Then you could customize the signature, but still use data classes nifty
f
>
> For simple situations you can call super in the __post_init__ method and
>> things will work fine:
>>
>
> But not for the OP's case: he wanted to pass extra parameters in -- and
> the dataclass' __init__ won't accept extra arguments.
>
>
> Can’t you just create InitVar attributes for the extra
On Apr 14, 2020, at 20:53, Christopher Barker wrote:
>
>> On Tue, Apr 14, 2020 at 7:46 PM Ricky Teachey wrote:
>> For simple situations you can call super in the __post_init__ method and
>> things will work fine:
>
> But not for the OP's case: he wanted to pass extra parameters in -- and the
20 matches
Mail list logo
