On Sun, May 08, 2022 at 11:02:22AM +1000, Chris Angelico wrote:
> On Sun, 8 May 2022 at 10:23, Steven D'Aprano wrote:
> > Outside of that narrow example of auto-assignment of attributes, can
> > anyone think of a use-case for this?
> >
>
> Honestly, I don't know of any. But in response to the
On Sun, 8 May 2022 at 10:23, Steven D'Aprano wrote:
>
> On Sat, May 07, 2022 at 11:38:19AM -0700, Ethan Furman wrote:
>
> > > I'd define it very simply. For positional args, these should be
> > > exactly equivalent:
> > >
> > > def func(self, x, x.y):
> > > ...
> > >
> > > def func(*args):
>
On Sat, May 07, 2022 at 11:38:19AM -0700, Ethan Furman wrote:
> > I'd define it very simply. For positional args, these should be
> > exactly equivalent:
> >
> > def func(self, x, x.y):
> > ...
> >
> > def func(*args):
> > self, x, x.y = args
> > ...
>
> Simple or not, I don't
On 5/7/22 06:24, Chris Angelico wrote:
> On Sat, 7 May 2022 at 23:15, Stephen J. Turnbull wrote:
>>
>> def foo(self, x, y):
>> x.y = y
>>
>> is not a pattern I can recall ever seeing
>
> I'd define it very simply. For positional args, these should be
> exactly equivalent:
>
> def
On Sat, May 7, 2022 at 6:28 AM Chris Angelico wrote:
> > > What would this do?
> > >
> > > def __init__(self, spam.x, eggs.y): pass
> > >
> > > How about this?
> > >
> > > def __init__(self, x, x.y): pass
> > IMO, both of those should be errors. This syntax only makes much
> >
On Sat, 7 May 2022 at 23:15, Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
>
> > What would this do?
> >
> > def __init__(self, spam.x, eggs.y): pass
> >
> > How about this?
> >
> > def __init__(self, x, x.y): pass
>
> IMO, both of those should be errors. This syntax only
Steven D'Aprano writes:
> What would this do?
>
> def __init__(self, spam.x, eggs.y): pass
>
> How about this?
>
> def __init__(self, x, x.y): pass
IMO, both of those should be errors. This syntax only makes much
sense for the first formal argument of a method definition,
On 5/4/2022 1:19 PM, Paul Moore wrote:
Maybe. But really what I want is a way to say "this is what type the
attribute is, but don't assume the init argument is the same type". Or
just not bother with all this at all. This is where it starts to just
become not worth trying to make dataclasses do
On Wed, 4 May 2022 at 17:04, Christopher Barker wrote:
>
> Bringing this back on list -- I hope that was an accident.
If it was, it was me not spotting that your reply to me was on-list, I
thought you're replied offlist so I followed suit. Not a problem
though, I'm fine with this being on-list
Bringing this back on list -- I hope that was an accident.
(NOTE: getting a touch off-topic here -- but I do bring it back around at
the end)
On Wed, May 4, 2022 at 4:38 AM Paul Moore wrote:
> On Tue, 3 May 2022 at 17:46, Christopher Barker
> wrote:
> > On Tue, May 3, 2022 at 5:39 AM Paul
Autocarrot!
--
Eric
> On May 3, 2022, at 8:32 PM, Christopher Barker wrote:
>
>
>
> Sorry - auto-correct is not my friend :-(
>
> -CHB
>
>> On Tue, May 3, 2022 at 12:07 PM Ethan Furman wrote:
>> On 5/2/22 23:21, Christopher Barker wrote:
>>
>> > But yes, there are many use cases not
Sorry - auto-correct is not my friend :-(
-CHB
On Tue, May 3, 2022 at 12:07 PM Ethan Furman wrote:
> On 5/2/22 23:21, Christopher Barker wrote:
>
> > But yes, there are many use cases not suited to dataclasses. The
> question is how many of these would
> > rap parge benefit from
On 5/2/22 23:21, Christopher Barker wrote:
> But yes, there are many use cases not suited to dataclasses. The question is
how many of these would
> rap parge benefit from auto-assigning syntax?
How did you get to "rap parge" from "reap the" ?
On 5/2/22 20:32, Christopher Barker wrote:
>
On Tue, May 3, 2022 at 6:36 AM Paul Moore wrote:
> On Tue, 3 May 2022 at 03:04, Steven D'Aprano wrote:
> >
> > On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
> >
> > > I have classes with 20+ parameters (packaging metadata). You can argue
> > > that a dataclass would be better, or
On Mon, May 2, 2022 at 11:48 AM Steven D'Aprano wrote:
> On Mon, May 02, 2022 at 10:34:56AM -0600, Pablo Alcain wrote:
>
> > For what it's worth,
> > the choice of the `@` was because of two different reasons: first,
> because
> > we were inspired by Ruby's syntax (later on learned that
On Tue, 3 May 2022 at 03:04, Steven D'Aprano wrote:
>
> On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
>
> > I have classes with 20+ parameters (packaging metadata). You can argue
> > that a dataclass would be better, or some other form of refactoring,
> > and you may actually be
On Mon, May 2, 2022 at 9:30 PM Joao S. O. Bueno
wrote:
> Anyway, there is something dataclasses do today that prevent you from jsut
> adding a @dataclass for binding __init__ attributes from an otherwise
> "complete class that does things":
>
I nor anyone else ever claimed dataclasses could be
Anyway, there is something dataclasses do today that prevent you from jsut
adding a @dataclass for binding __init__ attributes from an otherwise
"complete class that does things": it overwrites __init__ itself - one hass
to resort to write "__post_init__" instead,¨
That means that if some class
On Mon, May 2, 2022 at 7:42 PM Steven D'Aprano wrote:
> On Sun, May 01, 2022 at 10:40:49PM -0700, Christopher Barker wrote:
>
> > Yes, any class could use this feature (though it's more limited than
> what
> > dataclasses do) -- what I was getting is is that it would not be
> > (particularly)
On Sun, May 01, 2022 at 10:40:49PM -0700, Christopher Barker wrote:
> Yes, any class could use this feature (though it's more limited than what
> dataclasses do) -- what I was getting is is that it would not be
> (particularly) useful for all classes -- only classes where there are a lot
> of
On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
> I have classes with 20+ parameters (packaging metadata). You can argue
> that a dataclass would be better, or some other form of refactoring,
> and you may actually be right. But it is a legitimate design for that
> use case.
Indeed.
On Mon, 2 May 2022 at 18:46, Steven D'Aprano wrote:
>
> But **not once** when I have read that same method later on have I
> regretted that those assignments are explicitly written out, or wished
> that they were implicit and invisible.
I have classes with 20+ parameters (packaging metadata).
On Mon, May 02, 2022 at 10:34:56AM -0600, Pablo Alcain wrote:
> For what it's worth,
> the choice of the `@` was because of two different reasons: first, because
> we were inspired by Ruby's syntax (later on learned that CoffeeScript and
> Crystal had already taken the approach we are proposing)
On Mon, May 2, 2022 at 7:21 AM Steven D'Aprano wrote:
> On Sun, May 01, 2022 at 06:22:08PM -0700, Devin Jeanpierre wrote:
>
> > Is it unreasonable to instead suggest generalizing the assignment target
> > for parameters? For example, if parameter assignment happened left to
> > right, and
On Sun, May 1, 2022 at 10:35 AM Ethan Furman wrote:
> On 5/1/22 00:21, Christopher Barker wrote:
> > On Sat, Apr 30, 2022 at 2:17 PM Pablo Alcain wrote:
>
>
> >> It shows that out of 20k analyzed classes in the selected libraries
> (including black,
> >> pandas, numpy, etc), ~17% of them
On Mon, May 02, 2022 at 05:57:45PM +0900, Stephen J. Turnbull wrote:
> def __init__(s, s.x, s.y): pass
I think that if this proposal threatens to encourage people to write
that horro, that would be enough of a reason to reject it.
--
Steve
___
On Sun, May 01, 2022 at 06:22:08PM -0700, Devin Jeanpierre wrote:
> Is it unreasonable to instead suggest generalizing the assignment target
> for parameters? For example, if parameter assignment happened left to
> right, and allowed more than just variables, then one could do:
>
> def
Devin Jeanpierre writes:
> Is it unreasonable to instead suggest generalizing the assignment target
> for parameters? For example, if parameter assignment happened left to
> right, and allowed more than just variables, then one could do:
>
> def __init__(self, self.x, self.y): pass
At a
On Sun, May 1, 2022 at 1:16 AM Steven D'Aprano wrote:
> > > On Sat, Apr 23, 2022 at 12:11:07PM -0700, Christopher Barker wrote:
> > > > Absolutely. However, this is not an "all Classes" question.
> > > Isn't it? I thought this was a proposal to allow any class to partake
> in
> > > the dataclass
On Sun, May 1, 2022 at 9:35 AM Ethan Furman wrote:
> My own thoughts about the proposal: It seems interesting, and assigning
> as-is arguments is a chore -- but I'm not sure
> using up a token to help only one method per class is a good trade.
>
Is it unreasonable to instead suggest
On 5/1/22 00:21, Christopher Barker wrote:
> On Sat, Apr 30, 2022 at 2:17 PM Pablo Alcain wrote:
>> It shows that out of 20k analyzed classes in the selected libraries
(including black,
>> pandas, numpy, etc), ~17% of them could benefit from the usage of
auto-assign syntax.
>
> I only read
On Sat, Apr 30, 2022 at 11:54:47PM -0700, Christopher Barker wrote:
> On Sat, Apr 30, 2022 at 6:40 PM Steven D'Aprano wrote:
>
> > On Sat, Apr 23, 2022 at 12:11:07PM -0700, Christopher Barker wrote:
> > > Absolutely. However, this is not an "all Classes" question.
> >
> > Isn't it? I thought
On Sat, Apr 30, 2022 at 2:17 PM Pablo Alcain wrote:
>
>>> B) Most __init__ params need specialized behavior, and are quite
>> distinct from what's needed by __eq__ and __repr__
>>
>> (B) is well covered by the current, you-need-to-specify-everything
>> approach.
>>
>
> I don’t see B as a
On Sat, Apr 30, 2022 at 6:40 PM Steven D'Aprano wrote:
> On Sat, Apr 23, 2022 at 12:11:07PM -0700, Christopher Barker wrote:
> > Absolutely. However, this is not an "all Classes" question.
>
> Isn't it? I thought this was a proposal to allow any class to partake in
> the dataclass autoassignment
On Sat, Apr 23, 2022 at 12:11:07PM -0700, Christopher Barker wrote:
> On Sat, Apr 23, 2022 at 10:53 AM Pablo Alcain wrote:
>
> > Overall, I think that not all Classes can be thought of as Dataclasses
> > and, even though dataclasses solutions have their merits, they probably
> > cannot be
On Sat, Apr 23, 2022, 1:11 PM Christopher Barker
wrote:
> On Sat, Apr 23, 2022 at 10:53 AM Pablo Alcain
> wrote:
>
>> Overall, I think that not all Classes can be thought of as Dataclasses
>> and, even though dataclasses solutions have their merits, they probably
>> cannot be extended to most
On Thu, Apr 28, 2022 at 10:26 PM Ethan Furman wrote:
> > One thing you can say about dataclasses is that they provide a way to
> handle all parameters, mutable and immutable.
>
> Really? I did not know that. Interesting.
>
> Definitely an issue of dataclasses being special, though, and not
>
On 4/28/22 21:46, Christopher Barker wrote:
> One thing you can say about dataclasses is that they provide a way to handle
all parameters, mutable and immutable.
Really? I did not know that. Interesting.
Definitely an issue of dataclasses being special, though, and not attributable
to the
On Thu, Apr 28, 2022 at 4:15 PM Ethan Furman wrote:
> > NOTE: another key question for this proposal is how you would handle
> mutable defaults -- anything
> > special, or "don't do that"?
>
> Why should they be handled at all? If the programmer writes
>
> def __init__(a, @b, @c=[]):
>
On 4/23/22 12:11, Christopher Barker wrote:
> NOTE: another key question for this proposal is how you would handle mutable
defaults -- anything
> special, or "don't do that"?
Why should they be handled at all? If the programmer writes
def __init__(a, @b, @c=[]):
pass
then all
On 4/21/22 15:12, Joao S. O. Bueno wrote:
> On Thu, Apr 21, 2022 at 5:17 PM Pablo Alcain wrote:
>> I think that discussion can probably belong to a specific thread with the
proposal with
>> your questions summary there so everyone can contribute to the
implementation that, clearly,
>> has some
On 4/21/22 10:29, Joao S. O. Bueno wrote:
> I take the freedom to interpret 'no news == good news' on this thread -
> nominally that there are no major disagreements that a decorator
> to auto-commit `__init__` atributes to the instance could be a nice addition
> to the stdlib.
I am strongly
On Sat, Apr 23, 2022 at 10:53 AM Pablo Alcain wrote:
> Overall, I think that not all Classes can be thought of as Dataclasses
> and, even though dataclasses solutions have their merits, they probably
> cannot be extended to most of the other classes.
>
Absolutely. However, this is not an "all
On Thu, Apr 21, 2022 at 7:33 PM Josh Rosenberg <
shadowranger+pythonid...@gmail.com> wrote:
>
> On Wed, Apr 20, 2022 at 3:31 PM Pablo Alcain
> wrote:
>
>>
>> About dataclasses, the point that Chris mentions, I think that they are
>> in a different scope from this, since they do much more stuff.
On Wed, Apr 20, 2022 at 3:31 PM Pablo Alcain wrote:
>
> About dataclasses, the point that Chris mentions, I think that they are in
> a different scope from this, since they do much more stuff. But, beyond
> this, a solution on the dataclass style would face a similar scenario:
> since the
On Thu, Apr 21, 2022 at 5:17 PM Pablo Alcain wrote:
> Hey Joao! For what it's worth, I'm not a big fan of the proposal to be
> honest, for the reasons I have already mentioned. I'm not heavily against
> it, but I would most likely not use it. Nevertheless, I believe it would
> need a PEP since
Hey Joao! For what it's worth, I'm not a big fan of the proposal to be
honest, for the reasons I have already mentioned. I'm not heavily against
it, but I would most likely not use it. Nevertheless, I believe it would
need a PEP since it probably can change substantially the way Python code
is
I take the freedom to interpret 'no news == good news' on this thread -
nominally that there are no major disagreements that a decorator
to auto-commit `__init__` atributes to the instance could be a nice addition
to the stdlib.
I also assume it is uncontroversial enough for not needing a PEP.
I
On Wed, Apr 20, 2022 at 12:30 PM Pablo Alcain wrote:
>
> Regarding the usage of a decorator to do the auto-assignment, I think that
> it has an issue regarding how to select a subset of the variables that you
> would be setting. In the general case, you can probably get away with
> calling
Joao S. O. Bueno wrote:
> There is no need for a whole new syntax for what can trivially be
> accomplished by a decorator,
> and a simple one, in this cases.
> I for one am all for the inclusion of a decorator targeting either the
> __init__ method
> or the class itself to perform this binding of
Regarding the usage of a decorator to do the auto-assignment, I think that
it has an issue regarding how to select a subset of the variables that you
would be setting. In the general case, you can probably get away with
calling `autoassign`. But, for example, if you want to set a but not b,
you'd
On Mon, Apr 18, 2022 at 4:24 PM Joao S. O. Bueno
wrote:
> I for one am all for the inclusion of a decorator targeting either the
> __init__ method
> or the class itself to perform this binding of known arguments to instance
> attributes
> prior to entering __init__. It could live either in
There is no need for a whole new syntax for what can trivially be
accomplished by a decorator,
and a simple one, in this cases.
I for one am all for the inclusion of a decorator targeting either the
__init__ method
or the class itself to perform this binding of known arguments to instance
53 matches
Mail list logo
