[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Matt del Valle]

Just off the top of my head, a context manager like this would give access
to the required local scope, if inspecting the execution frames isn't
considered too hacky.

class LocalsProcessor:
def __enter__(self):
self.locals_ref = inspect.currentframe().f_back.f_locals
self.locals_prev = copy.deepcopy(self.locals_ref)
# deep copy to ensure we also get a copy of the
# __annotations__

def __exit__(self, exception_type, exception_value, traceback):
...
# modify self.locals_ref based on the difference between
# self.locals_ref and self.locals_prev and their
# respective __annotations__


An issue I can see with this approach is that the context manager can only
work off the difference between locals() before and after its scope, so it
would ignore a duplicate assignment to the same value as before, for a name
that existed before the context manager entered, in a way that might be
unexpected:

class Example:
a: str
b: int

with LocalsProcessor():
a: bool
# we can detect that 'a' changed and what it changed to/from
# because its value in the __annotations__ dict is different

b: int
# there is no way to detect that 'b' was redeclared within
# the scope of the contextmanager because it has the same
# annotation before and after


Granted, I have no idea who would ever write code like this (!) but I
thought I'd mention that as a problematic edge-case.

Maybe there's a better way to approach this that I can't think of.

Or maybe it's possible that using context managers for this isn't realistic
because of implementation issues that just can't be resolved. I just really
like the semantics of it :)

On Thu, Mar 11, 2021 at 11:08 PM Paul Bryan  wrote:

> The syntax of what you're proposing seems fairly intuitive (they might not
> even need to be callable).  I'm struggling to envision how the context
> manager would acquire scope to mark fields up in the (not yet defined)
> dataclass, and to capture the attributes that are being defined within.
>
>
> On Thu, 2021-03-11 at 22:53 +, Matt del Valle wrote:
>
> Disclaimer: I posted this earlier today but I think due to some first-post 
> moderation related issues (that I've hopefully now gotten sorted out!) it may 
> not have gone through. I'm posting this again just in case. If it's gone 
> through and you've already seen it then I'm super sorry, please just ignore 
> this.
>
> If something like what you're suggesting were to be implemented I would much 
> rather it be done with context managers than position-dependent special 
> values, because otherwise you once again end up in a situation where it's 
> impossible to easily subclass a dataclass (which was one of the primary 
> reasons this conversation even got started in the first place). So, for 
> example:
>
> import dataclasses
>
>
> @dataclasses.dataclass
> class SomeClass:
> c: bool = False
> # a normal field with a default value does not
> # prevent subsequent positional fields from
> # having no default value (such as 'a' below)
> # however, all further normal fields now must
> # specify a default value (such as 'd' below)
>
> with dataclasses.positional():
> a: int
> b: float = 3.14
> # once a positional field with a default value shows up
> # all further positional fields and ALL normal fields
> # (even retroactively!) must also specify defaults
> # (for example, field 'c' above is
> # now forced to specify a default value)
>
> with dataclasses.keyword():
> e: list
> f: set = dataclasses.field(default_factory=set)
> # once a keyword field with a default value shows up
> # all further keyword fields must also specify defaults
>
> d: dict = dataclasses.field(default_factory=dict)
> # This ordering is clearly insane, but the essential
> # point is that it works even with weird ordering
> # which is necessary for it to work when subclassing
> # where the order will almost always be wonky
> #
> # A sane version of the above would be:
>
>
> @dataclasses.dataclass
> class SomeClass:
> with dataclasses.positional():
> a: int
> b: float = 3.14
>
> c: bool = False
> d: dict = dataclasses.field(default_factory=dict)
>
> with dataclasses.keyword():
> e: list
> f: set = dataclasses.field(default_factory=set)
>
> # either of the above will generate an __init__ like:
> def __init__(self, a: int, b: float = 3.14,
>  /, c: bool = False, d: dict = None,
>  *, e: list, f: set = None):
> self.a = a
> self.b = b
> self.c = c
> self.d = dict() if d is None else d
> self.e = e
> self.f = set() if f is None else f
> # parameters are arranged in order as
> # positional -> normal -> keyword
> # within 

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Eric V. Smith]

That's basically my suggestion with dataclasses.KEYWORD_ONLY, and 
obviously POSITIONAL_ONLY also needs to exist. I'd be flexible on how to 
spell these.


I'm currently thinking we need some way to switch back to "normal" 
(non-keyword-only, non-positional-only) fields. But I'm not done with my 
prototype or use cases.


I also think @dataclass(kwonly=True) is a case that should be supported, 
since I think the most common usage will be to make every field 
keyword-only. I haven't yet looked at what attrs does.


Eric

On 3/11/2021 5:12 PM, Paul Bryan wrote:
If you're proposing something like this, then I think it would be 
compatible:


class Hmm:
  #
  this: int
  that: float
  #
  pos: PosOnly
  #
  these: str
  those: str
  #
  key: KWOnly
  #
  some: list

On Thu, 2021-03-11 at 14:06 -0800, Ethan Furman wrote:

On 3/11/21 10:50 AM, Paul Bryan wrote:

On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:

On 3/10/21 9:47 PM, Eric V. Smith wrote:


I'm not sure of the best way to achieve this. Using flags to field()
doesn't sound awesome, but could be made to work. Or maybe special
field names or types? I'm not crazy about that, but using special
types would let you do something like:

@dataclasses.dataclass
class Point:
 x: int = 0
 _: dataclasses.KEYWORD_ONLY
 y: int
 z: int
 t: int = 0


Maybe something like this?

 class Hmm:
 #
 this: int
 that: float
 #
 pos: '/'
 #
 these: str
 those: str
 #
 key: '*'
 #
 some: list

 >>> Hmm.__dict__['__annotations__']
 {
 'this': ,
 'that': ,
 'pos': '/',
 'these': ,
 'those': ,
 'key': '*',
 'some': ,
 }

The name of 'pos' and 'key' can be convention, since the actual name
is irrelevant.  They do have to be unique, though.  ;-)


It's current convention (and is used by typing module and static type
checkers) that string annotations evaluate to valid Python types.


So make '/' and '*' be imports from dataclasses:

 from dataclasses import dataclass, PosOnly, KWOnly

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org 

To unsubscribe send an email to python-ideas-le...@python.org 

https://mail.python.org/mailman3/lists/python-ideas.python.org/ 

Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6L4W5OB23FBWZ7EZYDNCYSGT2CUAKYSX/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 




___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VPSE34Z35XOXGFJMGTMLWDAMF7JKJYOJ/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

<>___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EGSUJ3HDCI6M75AUZ74BFMJEOMYLVFF7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

The syntax of what you're proposing seems fairly intuitive (they might
not even need to be callable).  I'm struggling to envision how the
context manager would acquire scope to mark fields up in the (not yet
defined) dataclass, and to capture the attributes that are being
defined within.


On Thu, 2021-03-11 at 22:53 +, Matt del Valle wrote:
Disclaimer: I posted this earlier today but I think due to some first-
post moderation related issues (that I've hopefully now gotten sorted o

ut!) it may not have gone through. I'm posting this again just in case.

 If it's gone through and you've already seen it then I'm super sorry, 

please just ignore this.

If something like what you're suggesting were to be implemented I would

 much rather it be done with context managers than position-
dependent special values, because otherwise you once again end up in a 

situation where it's impossible to easily subclass a dataclass (which w

as one of the primary reasons this conversation even got started in the

 first place). So, for example: 

import dataclasses


@dataclasses.dataclass
class SomeClass:
c: bool = False
# a normal field with a default value does not
# prevent subsequent positional fields from
# having no default value (such as 'a' below)
# however, all further normal fields now must
# specify a default value (such as 'd' below)

with dataclasses.positional():
a: int
b: float = 3.14
# once a positional field with a default value shows up
# all further positional fields and ALL normal fields
# (even retroactively!) must also specify defaults
# (for example, field 'c' above is
# now forced to specify a default value)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)
# once a keyword field with a default value shows up
# all further keyword fields must also specify defaults

d: dict = dataclasses.field(default_factory=dict)
# This ordering is clearly insane, but the essential
# point is that it works even with weird ordering
# which is necessary for it to work when subclassing
# where the order will almost always be wonky
#
# A sane version of the above would be:


@dataclasses.dataclass
class SomeClass:
with dataclasses.positional():
a: int
b: float = 3.14

c: bool = False
d: dict = dataclasses.field(default_factory=dict)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)

# either of the above will generate an __init__ like:
def __init__(self, a: int, b: float = 3.14,
 /, c: bool = False, d: dict = None,
 *, e: list, f: set = None):
self.a = a
self.b = b
self.c = c
self.d = dict() if d is None else d
self.e = e
self.f = set() if f is None else f
# parameters are arranged in order as
# positional -> normal -> keyword
# within the order they were defined in each
# individual category, but not necessarily
# whatever order they were defined in overall
#
# This is subclass-friendly!
#
# it should hopefully be obvious that we could
# have cut this class in half at literally any
# point (as long as the the parent class has
# the earlier arguments within each category)
# and put the rest into a child class and
# it would still have worked and generated the
# same __init__ signature
#
# For example:


@dataclasses.dataclass
class Parent:
with dataclasses.positional():
a: int

c: bool = False

with dataclasses.keyword():
e: list


@dataclasses.dataclass
class Child(Parent):
with dataclasses.positional():
b: float = 3.14

d: dict = dataclasses.field(default_factory=dict)

with dataclasses.keyword():
f: set = dataclasses.field(default_factory=set)
# Child now has the same __init__ signature as
# SomeClass above

(In case the above code doesn't render properly on your screen, I've up

loaded it to GitHub at: https://github.com/matthewgdv/dataclass_arg_co
ntextmanager/blob/main/example.py)

Honestly, the more I think about it, the more I love the idea of someth
ing like this (even if it's not exactly the same as my suggestion). Rig
ht now dataclasses do not support the full range of __init__ signatures
 you could generate with a normal class, and they are extremely hostile
 to subclassing. That is a failing that often forces people to fall bac
k to normal classes in otherwise ideal dataclass use-case situations.

On Thu, Mar 11, 2021 at 10:15 PM Paul Bryan  wrote:
> If you're proposing something like this, then I think it would be com

> 
> patible:
> 
> class Hmm:
>  #
>  this: int
>  that: float
>  #
>  pos: PosOnly
>  #
>  these: str
>  those: str
>  #
>  key: KWOnly
>  #
>  some: list
> 
> 
> 
> On Thu, 2021-03-11 at 14:06 -0800, 

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Matt del Valle]

Disclaimer: I posted this earlier today but I think due to some first-post
moderation related issues (that I've hopefully now gotten sorted out!) it
may not have gone through. I'm posting this again just in case. If it's
gone through and you've already seen it then I'm super sorry, please just
ignore this.

If something like what you're suggesting were to be implemented I would
much rather it be done with context managers than position-dependent
special values, because otherwise you once again end up in a situation
where it's impossible to easily subclass a dataclass (which was one of the
primary reasons this conversation even got started in the first place). So,
for example:

import dataclasses


@dataclasses.dataclass
class SomeClass:
c: bool = False
# a normal field with a default value does not
# prevent subsequent positional fields from
# having no default value (such as 'a' below)
# however, all further normal fields now must
# specify a default value (such as 'd' below)

with dataclasses.positional():
a: int
b: float = 3.14
# once a positional field with a default value shows up
# all further positional fields and ALL normal fields
# (even retroactively!) must also specify defaults
# (for example, field 'c' above is
# now forced to specify a default value)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)
# once a keyword field with a default value shows up
# all further keyword fields must also specify defaults

d: dict = dataclasses.field(default_factory=dict)
# This ordering is clearly insane, but the essential
# point is that it works even with weird ordering
# which is necessary for it to work when subclassing
# where the order will almost always be wonky
#
# A sane version of the above would be:


@dataclasses.dataclass
class SomeClass:
with dataclasses.positional():
a: int
b: float = 3.14

c: bool = False
d: dict = dataclasses.field(default_factory=dict)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)

# either of the above will generate an __init__ like:
def __init__(self, a: int, b: float = 3.14,
 /, c: bool = False, d: dict = None,
 *, e: list, f: set = None):
self.a = a
self.b = b
self.c = c
self.d = dict() if d is None else d
self.e = e
self.f = set() if f is None else f
# parameters are arranged in order as
# positional -> normal -> keyword
# within the order they were defined in each
# individual category, but not necessarily
# whatever order they were defined in overall
#
# This is subclass-friendly!
#
# it should hopefully be obvious that we could
# have cut this class in half at literally any
# point (as long as the the parent class has
# the earlier arguments within each category)
# and put the rest into a child class and
# it would still have worked and generated the
# same __init__ signature
#
# For example:


@dataclasses.dataclass
class Parent:
with dataclasses.positional():
a: int

c: bool = False

with dataclasses.keyword():
e: list


@dataclasses.dataclass
class Child(Parent):
with dataclasses.positional():
b: float = 3.14

d: dict = dataclasses.field(default_factory=dict)

with dataclasses.keyword():
f: set = dataclasses.field(default_factory=set)
# Child now has the same __init__ signature as
# SomeClass above


(In case the above code doesn't render properly on your screen, I've
uploaded it to GitHub at:
https://github.com/matthewgdv/dataclass_arg_contextmanager/blob/main/example.py
)

Honestly, the more I think about it, the more I love the idea of something
like this (even if it's not *exactly* the same as my suggestion). Right now
dataclasses do not support the full range of __init__ signatures you could
generate with a normal class, and they are extremely hostile to
subclassing. That is a failing that often forces people to fall back to
normal classes in otherwise ideal dataclass use-case situations.

On Thu, Mar 11, 2021 at 10:15 PM Paul Bryan  wrote:

> If you're proposing something like this, then I think it would be
> compatible:
>
> class Hmm:
>
>  #
>
>  this: int
>
>  that: float
>
>  #
>
>  pos: PosOnly
>
>  #
>
>  these: str
>
>  those: str
>
>  #
>
>  key: KWOnly
>
>  #
>
>  some: list
>
>
>
> On Thu, 2021-03-11 at 14:06 -0800, Ethan Furman wrote:
>
> On 3/11/21 10:50 AM, Paul Bryan wrote:
>
> On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
>
> On 3/10/21 9:47 PM, Eric V. Smith wrote:
>
> I'm not sure of the best way to achieve this. Using flags to field()
> doesn't sound awesome, but could be made to work. Or maybe special
> field names or types? I'm not crazy about 

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

If you're proposing something like this, then I think it would be
compatible:

class Hmm:
 #
 this: int
 that: float
 #
 pos: PosOnly
 #
 these: str
 those: str
 #
 key: KWOnly
 #
 some: list


On Thu, 2021-03-11 at 14:06 -0800, Ethan Furman wrote:
> On 3/11/21 10:50 AM, Paul Bryan wrote:
> > On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
> > > On 3/10/21 9:47 PM, Eric V. Smith wrote:
> > > 
> > > > I'm not sure of the best way to achieve this. Using flags to
> > > > field()
> > > > doesn't sound awesome, but could be made to work. Or maybe
> > > > special
> > > > field names or types? I'm not crazy about that, but using
> > > > special
> > > > types would let you do something like:
> > > > 
> > > > @dataclasses.dataclass
> > > > class Point:
> > > >  x: int = 0
> > > >  _: dataclasses.KEYWORD_ONLY
> > > >  y: int
> > > >  z: int
> > > >  t: int = 0
> > > 
> > > Maybe something like this?
> > > 
> > >  class Hmm:
> > >  #
> > >  this: int
> > >  that: float
> > >  #
> > >  pos: '/'
> > >  #
> > >  these: str
> > >  those: str
> > >  #
> > >  key: '*'
> > >  #
> > >  some: list
> > > 
> > >  >>> Hmm.__dict__['__annotations__']
> > >  {
> > >  'this': ,
> > >  'that': ,
> > >  'pos': '/',
> > >  'these': ,
> > >  'those': ,
> > >  'key': '*',
> > >  'some': ,
> > >  }
> > > 
> > > The name of 'pos' and 'key' can be convention, since the actual
> > > name
> > > is irrelevant.  They do have to be unique, though.  ;-)
> > 
> > It's current convention (and is used by typing module and static
> > type
> > checkers) that string annotations evaluate to valid Python types.
> 
> So make '/' and '*' be imports from dataclasses:
> 
>  from dataclasses import dataclass, PosOnly, KWOnly
> 
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/6L4W5OB23FBWZ7EZYDNCYSGT2CUAKYSX/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VPSE34Z35XOXGFJMGTMLWDAMF7JKJYOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ethan Furman]

On 3/11/21 10:50 AM, Paul Bryan wrote:

On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:

On 3/10/21 9:47 PM, Eric V. Smith wrote:


I'm not sure of the best way to achieve this. Using flags to field()
doesn't sound awesome, but could be made to work. Or maybe special
field names or types? I'm not crazy about that, but using special
types would let you do something like:

@dataclasses.dataclass
class Point:
 x: int = 0
 _: dataclasses.KEYWORD_ONLY
 y: int
 z: int
 t: int = 0


Maybe something like this?

 class Hmm:
 #
 this: int
 that: float
 #
 pos: '/'
 #
 these: str
 those: str
 #
 key: '*'
 #
 some: list

 >>> Hmm.__dict__['__annotations__']
 {
 'this': ,
 'that': ,
 'pos': '/',
 'these': ,
 'those': ,
 'key': '*',
 'some': ,
 }

The name of 'pos' and 'key' can be convention, since the actual name
is irrelevant.  They do have to be unique, though.  ;-)


It's current convention (and is used by typing module and static type
checkers) that string annotations evaluate to valid Python types.


So make '/' and '*' be imports from dataclasses:

from dataclasses import dataclass, PosOnly, KWOnly

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6L4W5OB23FBWZ7EZYDNCYSGT2CUAKYSX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

It's current convention (and is used by typing module and static type
checkers) that string annotations evaluate to valid Python types.

On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
> On 3/10/21 9:47 PM, Eric V. Smith wrote:
> 
> > I'm not sure of the best way to achieve this. Using flags to
> > field() doesn't sound awesome, but could be made to work. Or maybe
> > special field names or types? I'm not crazy about that, but using
> > special types would let you do something like:
> > 
> > @dataclasses.dataclass
> > class Point:
> >  x: int = 0
> >  _: dataclasses.KEYWORD_ONLY
> >  y: int
> >  z: int
> >  t: int = 0
> 
> Maybe something like this?
> 
>  class Hmm:
>  #
>  this: int
>  that: float
>  #
>  pos: '/'
>  #
>  these: str
>  those: str
>  #
>  key: '*'
>  #
>  some: list
> 
>  >>> Hmm.__dict__['__annotations__']
>  {
>  'this': ,
>  'that': ,
>  'pos': '/',
>  'these': ,
>  'those': ,
>  'key': '*',
>  'some': ,
>  }
> 
> The name of 'pos' and 'key' can be convention, since the actual name
> is irrelevant.  They do have to be unique, though.  ;-)
> 
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BIAVX4O6JRPQY7S3XG2IX6BSBZLAR2NS/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BKEP55A72KOF6PWYGJEDXZPMN5CBTL6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ethan Furman]

On 3/10/21 9:47 PM, Eric V. Smith wrote:


I'm not sure of the best way to achieve this. Using flags to field() doesn't 
sound awesome, but could be made to work. Or maybe special field names or 
types? I'm not crazy about that, but using special types would let you do 
something like:

@dataclasses.dataclass
class Point:
 x: int = 0
 _: dataclasses.KEYWORD_ONLY
 y: int
 z: int
 t: int = 0


Maybe something like this?

class Hmm:
#
this: int
that: float
#
pos: '/'
#
these: str
those: str
#
key: '*'
#
some: list

>>> Hmm.__dict__['__annotations__']
{
'this': ,
'that': ,
'pos': '/',
'these': ,
'those': ,
'key': '*',
'some': ,
}

The name of 'pos' and 'key' can be convention, since the actual name is 
irrelevant.  They do have to be unique, though.  ;-)

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BIAVX4O6JRPQY7S3XG2IX6BSBZLAR2NS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ricky Teachey]

On Thu, Mar 11, 2021 at 11:59 AM Eric V. Smith  wrote:

> On 3/11/2021 10:23 AM, Ricky Teachey wrote:
>
> On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan  wrote:
>
>> Given that @dataclass is a decorator, and otherwise you're just defining
>> a class, some concerns:
>>
>> 1. Such proposed syntax would require a change to the language
>> specification.
>>
>> 2. It would seem that / and * in a class not decorated with @dataclass
>> would be of no other utility.
>>
>> Paul
>>
>
> Well the utility of this, without dataclasses, or only for the type
> checker as far as I know:
>
> class C:
> member: Any
>
> Perhaps the additional syntax could also be useful for the type checker?
>
> Type checkers certainly have to be aware of the generated __init__, so
> they're definitely involved.
>
> As long as we're going all "pie in the sky", I'd like to see dataclasses
> baked in to the interpreter. Something like:
>
> dataclass Point:
>   x: int
>   y: int
>
> That's actually a typo I make all the time!
>
Yes, please!

But I don't think there's really any chance of doing anything requiring
> changes to the interpreter. So we're back to either using field() or my
> marker types. Any other ideas that could be implemented today? I don't
> think the "with" suggestion could be made to work, but maybe I lack
> imagination.
>
> Eric
>
Not with that attitude! ;) 

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YV7N4GW4Z45L5SWGPACR44FDKFFWX7MJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Eric V. Smith]

On 3/11/2021 10:23 AM, Ricky Teachey wrote:
On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan > wrote:


Given that @dataclass is a decorator, and otherwise you're just
defining a class, some concerns:

1. Such proposed syntax would require a change to the language
specification.

2. It would seem that / and * in a class not decorated with
@dataclass would be of no other utility.

Paul


Well the utility of this, without dataclasses, or only for the type 
checker as far as I know:


class C:
    member: Any

Perhaps the additional syntax could also be useful for the type checker?


Type checkers certainly have to be aware of the generated __init__, so 
they're definitely involved.


As long as we're going all "pie in the sky", I'd like to see dataclasses 
baked in to the interpreter. Something like:


dataclass Point:
  x: int
  y: int

That's actually a typo I make all the time!

But I don't think there's really any chance of doing anything requiring 
changes to the interpreter. So we're back to either using field() or my 
marker types. Any other ideas that could be implemented today? I don't 
think the "with" suggestion could be made to work, but maybe I lack 
imagination.


Eric

<>___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K2SXT7MKWWPPZEKTRTGKYYLGI5ZQYBJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ricky Teachey]

On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan  wrote:

> Given that @dataclass is a decorator, and otherwise you're just defining a
> class, some concerns:
>
> 1. Such proposed syntax would require a change to the language
> specification.
>
> 2. It would seem that / and * in a class not decorated with @dataclass
> would be of no other utility.
>
> Paul
>

Well the utility of this, without dataclasses, or only for the type checker
as far as I know:

class C:
member: Any

Perhaps the additional syntax could also be useful for the type checker?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OUBTWPGEM5A6LJ2NDM56YJIFE3FFELZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

Given that @dataclass is a decorator, and otherwise you're just
defining a class, some concerns:

1. Such proposed syntax would require a change to the language
specification. 

2. It would seem that / and * in a class not decorated with @dataclass
would be of no other utility.

Paul

On Thu, 2021-03-11 at 10:08 -0500, Ricky Teachey wrote:
> On Thu, Mar 11, 2021 at 10:00 AM Ethan Furman 
> wrote:
> > On 3/11/21 4:20 AM, Ricky Teachey wrote:
> > 
> > > This might be a bit of an extreme step to take, but has new
> > syntax for this ever been discussed? Here I am using the same
> > indicator for keyword arguments as in a function signature, hanging
> > on a line by itself:
> > > 
> > ...
> > > @dataclasses.dataclass
> > > class Comparator:
> > >      /  # args become positional after this line
> > >      a: Any
> > >      b: Any
> > >      *  # args become kwd args after this line
> > >      key: Optional[Callable[whatever]] = None
> > 
> > Actually, the '/' indicates that names /before/ it are positional
> > only.
> > 
> > --
> > ~Ethan~
> > 
> 
> 
> Yes you're of course correct! Sorry!
> 
> So the corrected version would be:
> 
> @dataclasses.dataclass
> class Comparator:
>     a: Any
>     b: Any
>      /  # args before this line positional only
>     *  # args become kwd args after this line
>     key: Optional[Callable[whatever]] = None
> 
> ---
> Ricky.
> 
> "I've never met a Kentucky man who wasn't either thinking about going
> home or actually going home." - Happy Chandler
> 
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/L6Y5C7CFPEQECK5OWVOI4CKAYGHBHAPM/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FJDZ4TDKDSERY5P6F4CU777QC5IEEKHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ricky Teachey]

On Thu, Mar 11, 2021 at 10:00 AM Ethan Furman  wrote:

> On 3/11/21 4:20 AM, Ricky Teachey wrote:
>
> > This might be a bit of an extreme step to take, but has new syntax for
> this ever been discussed? Here I am using the same indicator for keyword
> arguments as in a function signature, hanging on a line by itself:
> >
> ...
> > @dataclasses.dataclass
> > class Comparator:
> >  /  # args become positional after this line
> >  a: Any
> >  b: Any
> >  *  # args become kwd args after this line
> >  key: Optional[Callable[whatever]] = None
>
> Actually, the '/' indicates that names /before/ it are positional only.
>
> --
> ~Ethan~
>

Yes you're of course correct! Sorry! 

So the corrected version would be:

@dataclasses.dataclass
class Comparator:
a: Any
b: Any
 /  # args before this line positional only
*  # args become kwd args after this line
key: Optional[Callable[whatever]] = None

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L6Y5C7CFPEQECK5OWVOI4CKAYGHBHAPM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ethan Furman]

On 3/11/21 4:20 AM, Ricky Teachey wrote:


This might be a bit of an extreme step to take, but has new syntax for this 
ever been discussed? Here I am using the same indicator for keyword arguments 
as in a function signature, hanging on a line by itself:

@dataclasses.dataclass
class Comparator:
     a: Any
     b: Any
     *
     key: Optional[Callable[whatever]] = None

Could also support the positional only version:

@dataclasses.dataclass
class Comparator:
     /  # args become positional after this line
     a: Any
     b: Any
     *  # args become kwd args after this line
     key: Optional[Callable[whatever]] = None


Actually, the '/' indicates that names /before/ it are positional only.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W4U5PCRBEWQZCZOA3LV46W27TGQD6EC6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ricky Teachey]

This might be a bit of an extreme step to take, but has new syntax for this
ever been discussed? Here I am using the same indicator for keyword
arguments as in a function signature, hanging on a line by itself:

@dataclasses.dataclass
class Comparator:
a: Any
b: Any
*
key: Optional[Callable[whatever]] = None
Could also support the positional only version:

@dataclasses.dataclass
class Comparator:
/  # args become positional after this line
a: Any
b: Any
*  # args become kwd args after this line
key: Optional[Callable[whatever]] = None

As far as how these standalone symbols would be parsed, I have no ideas on
that. Because of the way Dataclasses work, the / and * lines would have to
produce SOMETHING for the decorator to find. I'm just not sure what that
something would be.

But I think it looks pretty good if you're already familiar with python
function signature syntax.

Taking this to the logical conclusion:

@dataclasses.dataclass
class Comparator:
/
a: Any
b: Any
*others: Any  # collect more positional args
key: Optional[Callable[whatever]] = None
**kwargs: Any  # collect more kwd args


On Thu, Mar 11, 2021, 12:51 AM Eric V. Smith  wrote:

> As I've said before, I'm not opposed to the feature of keyword-only
> arguments. I think it would be a great addition.
>
> However, the proposal from Laurie O is only for changing fields without
> default values following fields with default values to be keyword-only. At
> least that's how I understand it.
>
> So, that means that:
>
> @dataclasses.dataclass
> class Point:
> x: int = 0
> y: int
> z: int
> t: int = 0
>
> Would generate a __init__ with this signature:
>
> def __init__(self, x=0, *, y, z, t=0):
>
> While it's an interesting application, I think that's just too limiting.
> Among other things, I can't define a dataclass where all fields are
> keyword-only, or a class where there's only a single field and it's
> keyword-only. I also have to have at least one keyword-only field (here, y)
> that has no default value. z and t can have defaults, but not y.
>
> What I'd like to see is some way of having keyword-only arguments, with or
> without defaults. And I'd also like to see if we could get support for
> positional-only arguments at the same time.
>
> I'm not sure of the best way to achieve this. Using flags to field()
> doesn't sound awesome, but could be made to work. Or maybe special field
> names or types? I'm not crazy about that, but using special types would let
> you do something like:
>
> @dataclasses.dataclass
> class Point:
> x: int = 0
> _: dataclasses.KEYWORD_ONLY
> y: int
> z: int
> t: int = 0
>
> And the dataclasses machinery would ignore the "_" field except for making
> everything after it keyword-only. Here the name "_" isn't special: any
> field (of any name) that's of type dataclasses.KEYWORD_ONLY would be
> ignored except for the keyword-only changing behavior. In some ways, it's
> like dataclasses.ClassVar, where the type is treated specially and the
> field doesn't become a __init__ argument.
>
> There are also issues with inheritance that would need to be thought
> through. This idea could also be extended for positional-only.
>
> I'm open to other suggestions.
>
> Eric
> On 3/10/2021 10:22 AM, Guido van Rossum wrote:
>
> I've seen comments from Eric V Smith in this thread and in the PR. If he's
> in favor and it can be done in a backwards compatible way then he can guide
> you to acceptance and merging of your PR. But like all of us he has limited
> time.
>
> On Wed, Mar 10, 2021 at 6:15 AM Laurie O 
> wrote:
>
>> I've had tens of people show interest in my proposal, asking what the
>> blocker is in acceptance. As far as I know, no Python developer has shown
>> any interest in it.
>>
>> My proposal is to automatically make any non-default fields become
>> keyword-only `__init__` parameters, with no need to have any arguments
>> passed to the `dataclass` decorator.
>>
>> My PR: https://github.com/python/cpython/pull/17322
>>
>> My previous mailing-list message:
>> https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to 
> 

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Matt del Valle]

 In response to Eric V. Smith, if something like what you're suggesting
were to be implemented I would much rather it be done with context managers
than special values, because otherwise you once again end up in a situation
where it's impossible to easily subclass a dataclass (which was one of the
primary reasons this conversation even got started in the first place). So,
for example:

import dataclasses


@dataclasses.dataclass
class SomeClass:
c: bool = False
# a normal field with a default value does not
# prevent subsequent positional fields from
# having no default value (such as 'a' below)
# however, all further normal fields now must
# specify a default value (such as 'd' below)

with dataclasses.positional():
a: int
b: float = 3.14
# once a positional field with a default value shows up
# all further positional fields and ALL normal fields
# (even retroactively!) must also specify defaults
# (for example, field 'c' above is
# now forced to specify a default value)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)
# once a keyword field with a default value shows up
# all further keyword fields must also specify defaults

d: dict = dataclasses.field(default_factory=dict)

# this will generate an __init__ like:
def __init__(self, a: int, b: float = 3.14,
 /, c: bool = False, d: dict = None,
 *, e: list, f: set = None):
self.a = a
self.b = b
self.c = c
self.d = dict() if d is None else d
self.e = e
self.f = set() if f is None else f
# parameters are arranged in order as
# positional -> normal -> keyword
# within the order they were defined in each
# individual category, but not necessarily
# whatever order they were defined in overall
#
# This is subclass-friendly!
#
# it should hopefully be obvious that we could
# have cut this class in half at literally any
# point (as long as the the parent class has
# the earlier arguments within each category)
# and put the rest into a child class and
# it would still have worked and generated the
# same __init__ signature
#
# For example:


@dataclasses.dataclass
class Parent:
c: bool = False

with dataclasses.keyword():
e: list

with dataclasses.positional():
a: int


@dataclasses.dataclass
class Child(Parent):
with dataclasses.keyword():
f: set = dataclasses.field(default_factory=set)

d: dict = dataclasses.field(default_factory=dict)

with dataclasses.positional():
b: float = 3.14

# we have shuffled around the ordering of the
# context managers and normal fields in both
# classes and it STILL works unambiguously!


Honestly, the more I think about it the more I'm +1 on something like this
(even if it's not *exactly* my suggestion). Right now dataclasses do not
support the full range of __init__ signatures you could generate with a
normal class (and are extremely hostile to subclassing), and that is a
failing that often forces people to fall back to normal classes in
otherwise ideal dataclass use-case situations.

On Thu, Mar 11, 2021 at 7:35 AM Eric V. Smith  wrote:

> On 3/11/2021 1:41 AM, Paul Bryan wrote:
>
> In my experience, a dataclass with more than a few attributes makes using
> positional arguments unwieldy and error-prone.
>
> Agreed, just like any function or class.
>
> I would think something like @dataclass(kwonly=*bool*) with default of
> False would be reasonably clean to implement and understand.
>
> Yes, I think that's a reasonable thing to do. But I don't want it to be
> the only option, I'd like to be able to mix and match some "normal"
> arguments and some keyword-only (and some positional-only).
>
>
> While I appreciate supporting existing behavior for backward
> compatibility, I'm not so clear on the value of supporting a hybrid of
> positional and keyword __init__ arguments. Could you shed some light on
> your reasoning for supporting it?
>
> The same as any function or class. From PEP 3102:
>
> def compare(a, b, *, key=None):
>
> This seems like a reasonable thing to want a dataclass to represent. Using
> my off-the-cuff proposal from below:
>
> @dataclasses.dataclass
> class Comparator:
> a: Any
> b: Any
> _: dataclasses.KEYWORD_ONLY
> key: Optional[Callable[whatever]] = None
>
> I don't want to restrict dataclasses: I'd like the full range of argument
> types to be available. This is especially true as dataclasses are used for
> more and more things (at least that's what happens in my code).
>
> Eric
>
>
>
> On Thu, 2021-03-11 at 00:47 -0500, Eric V. Smith wrote:
>
> As I've said before, I'm not opposed to the feature of keyword-only
> arguments. I think it would be a great addition.
>
> However, the proposal from Laurie O is only for 

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Eric V. Smith]

On 3/11/2021 1:41 AM, Paul Bryan wrote:
In my experience, a dataclass with more than a few attributes makes 
using positional arguments unwieldy and error-prone.

Agreed, just like any function or class.
I would think something like @dataclass(kwonly=/bool/) with default of 
False would be reasonably clean to implement and understand.
Yes, I think that's a reasonable thing to do. But I don't want it to be 
the only option, I'd like to be able to mix and match some "normal" 
arguments and some keyword-only (and some positional-only).


While I appreciate supporting existing behavior for backward 
compatibility, I'm not so clear on the value of supporting a hybrid of 
positional and keyword __init__ arguments. Could you shed some light 
on your reasoning for supporting it?


The same as any function or class. From PEP 3102:

def compare(a, b, *, key=None):

This seems like a reasonable thing to want a dataclass to represent. 
Using my off-the-cuff proposal from below:


@dataclasses.dataclass
class Comparator:
    a: Any
    b: Any
    _: dataclasses.KEYWORD_ONLY
    key: Optional[Callable[whatever]] = None

I don't want to restrict dataclasses: I'd like the full range of 
argument types to be available. This is especially true as dataclasses 
are used for more and more things (at least that's what happens in my code).


Eric




On Thu, 2021-03-11 at 00:47 -0500, Eric V. Smith wrote:


As I've said before, I'm not opposed to the feature of keyword-only 
arguments. I think it would be a great addition.


However, the proposal from Laurie O is only for changing fields 
without default values following fields with default values to be 
keyword-only. At least that's how I understand it.


So, that means that:

@dataclasses.dataclass
class Point:
    x: int = 0
    y: int
    z: int
    t: int = 0

Would generate a __init__ with this signature:

def __init__(self, x=0, *, y, z, t=0):

While it's an interesting application, I think that's just too 
limiting. Among other things, I can't define a dataclass where all 
fields are keyword-only, or a class where there's only a single field 
and it's keyword-only. I also have to have at least one keyword-only 
field (here, y) that has no default value. z and t can have defaults, 
but not y.


What I'd like to see is some way of having keyword-only arguments, 
with or without defaults. And I'd also like to see if we could get 
support for positional-only arguments at the same time.


I'm not sure of the best way to achieve this. Using flags to field() 
doesn't sound awesome, but could be made to work. Or maybe special 
field names or types? I'm not crazy about that, but using special 
types would let you do something like:


@dataclasses.dataclass
class Point:
    x: int = 0
    _: dataclasses.KEYWORD_ONLY
    y: int
    z: int
    t: int = 0

And the dataclasses machinery would ignore the "_" field except for 
making everything after it keyword-only. Here the name "_" isn't 
special: any field (of any name) that's of type 
dataclasses.KEYWORD_ONLY would be ignored except for the keyword-only 
changing behavior. In some ways, it's like dataclasses.ClassVar, 
where the type is treated specially and the field doesn't become a 
__init__ argument.


There are also issues with inheritance that would need to be thought 
through. This idea could also be extended for positional-only.


I'm open to other suggestions.

Eric

On 3/10/2021 10:22 AM, Guido van Rossum wrote:


___
Python-ideas mailing list --
To unsubscribe send an email to

Message archived at
Code of Conduct:

--
Eric V. Smith
___
Python-ideas mailing list -- python-ideas@python.org 

To unsubscribe send an email to python-ideas-le...@python.org 

https://mail.python.org/mailman3/lists/python-ideas.python.org/ 

Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XSAYT2MFOIBYHYINDHLPR7V2WHCWRYPE/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 




___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UGNLUWT4OQC2JMEXSNIJRRCC4KMBE6XJ/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

<>___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

In my experience, a dataclass with more than a few attributes makes
using positional arguments unwieldy and error-prone. 

I would think something like @dataclass(kwonly=bool) with default of
False would be reasonably clean to implement and understand.

While I appreciate supporting existing behavior for backward
compatibility, I'm not so clear on the value of supporting a hybrid of
positional and keyword __init__ arguments. Could you shed some light on
your reasoning for supporting it?


On Thu, 2021-03-11 at 00:47 -0500, Eric V. Smith wrote:
> As I've said before, I'm not opposed to the feature of keyword-only
> arguments. I think it would be a great addition.
> However, the proposal from Laurie O is only for changing fields
> without default values following fields with default values to be
> keyword-only. At least that's how I understand it.
> So, that means that:
> @dataclasses.dataclass
> class Point:
>     x: int = 0
>     y: int
>     z: int
>     t: int = 0
> Would generate a __init__ with this signature:
> def __init__(self, x=0, *, y, z, t=0):
> While it's an interesting application, I think that's just too
> limiting. Among other things, I can't define a dataclass where all
> fields are keyword-only, or a class where there's only a single field
> and it's keyword-only. I also have to have at least one keyword-only
> field (here, y) that has no default value. z and t can have defaults,
> but not y.
> What I'd like to see is some way of having keyword-only arguments,
> with or without defaults. And I'd also like to see if we could get
> support for positional-only arguments at the same time.
> I'm not sure of the best way to achieve this. Using flags to field()
> doesn't sound awesome, but could be made to work. Or maybe special
> field names or types? I'm not crazy about that, but using special
> types would let you do something like:
> @dataclasses.dataclass
> class Point:
>     x: int = 0
>     _: dataclasses.KEYWORD_ONLY
>     y: int
>     z: int
>     t: int = 0
> And the dataclasses machinery would ignore the "_" field except for
> making everything after it keyword-only. Here the name "_" isn't
> special: any field (of any name) that's of type
> dataclasses.KEYWORD_ONLY would be ignored except for the keyword-only
> changing behavior. In some ways, it's like dataclasses.ClassVar,
> where the type is treated specially and the field doesn't become a
> __init__ argument.
> There are also issues with inheritance that would need to be thought
> through. This idea could also be extended for positional-only.
> I'm open to other suggestions.
> Eric
> On 3/10/2021 10:22 AM, Guido van Rossum wrote:
> 
> > ___
> > Python-ideas mailing list -- 
> > To unsubscribe send an email to 
> > 
> > Message archived at 
> > Code of Conduct: 
> -- 
> Eric V. Smith
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XSAYT2MFOIBYHYINDHLPR7V2WHCWRYPE/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UGNLUWT4OQC2JMEXSNIJRRCC4KMBE6XJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Laurie O]

You're right, the goal of my PR is not to allow specifying keyword-only (or 
positional-only) `__init__` parameters, but rather the goal is to allow child 
classes to be defined with non-defaulted fields (with defaulted fields in 
parent classes). Keyword-only parameters is simply an implementation detail.

I don't know about positional-only parameters, but a more fleshed-out solution 
would do something similar to `attrs` (as linked above) where the fields can be 
specified as keyword-only, which then allows non-defaulted fields in child 
classes as a side-effect.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7WWIZPGR3TM422GEZFLKIPLAIZVUXETV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Eric V. Smith]

As I've said before, I'm not opposed to the feature of keyword-only 
arguments. I think it would be a great addition.


However, the proposal from Laurie O is only for changing fields without 
default values following fields with default values to be keyword-only. 
At least that's how I understand it.


So, that means that:

@dataclasses.dataclass
class Point:
    x: int = 0
    y: int
    z: int
    t: int = 0

Would generate a __init__ with this signature:

def __init__(self, x=0, *, y, z, t=0):

While it's an interesting application, I think that's just too limiting. 
Among other things, I can't define a dataclass where all fields are 
keyword-only, or a class where there's only a single field and it's 
keyword-only. I also have to have at least one keyword-only field (here, 
y) that has no default value. z and t can have defaults, but not y.


What I'd like to see is some way of having keyword-only arguments, with 
or without defaults. And I'd also like to see if we could get support 
for positional-only arguments at the same time.


I'm not sure of the best way to achieve this. Using flags to field() 
doesn't sound awesome, but could be made to work. Or maybe special field 
names or types? I'm not crazy about that, but using special types would 
let you do something like:


@dataclasses.dataclass
class Point:
    x: int = 0
    _: dataclasses.KEYWORD_ONLY
    y: int
    z: int
    t: int = 0

And the dataclasses machinery would ignore the "_" field except for 
making everything after it keyword-only. Here the name "_" isn't 
special: any field (of any name) that's of type dataclasses.KEYWORD_ONLY 
would be ignored except for the keyword-only changing behavior. In some 
ways, it's like dataclasses.ClassVar, where the type is treated 
specially and the field doesn't become a __init__ argument.


There are also issues with inheritance that would need to be thought 
through. This idea could also be extended for positional-only.


I'm open to other suggestions.

Eric

On 3/10/2021 10:22 AM, Guido van Rossum wrote:
I've seen comments from Eric V Smith in this thread and in the PR. If 
he's in favor and it can be done in a backwards compatible way then he 
can guide you to acceptance and merging of your PR. But like all of us 
he has limited time.


On Wed, Mar 10, 2021 at 6:15 AM Laurie O > wrote:


I've had tens of people show interest in my proposal, asking what
the blocker is in acceptance. As far as I know, no Python
developer has shown any interest in it.

My proposal is to automatically make any non-default fields become
keyword-only `__init__` parameters, with no need to have any
arguments passed to the `dataclass` decorator.

My PR: https://github.com/python/cpython/pull/17322


My previous mailing-list message:

https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/


___
Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/

Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/


Code of Conduct: http://python.org/psf/codeofconduct/




--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun here?)/ 



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IN3D7UQQI4HSKSCUPMU3C3RTUG6NWUKG/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

<>___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XSAYT2MFOIBYHYINDHLPR7V2WHCWRYPE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Guido van Rossum]

I've seen comments from Eric V Smith in this thread and in the PR. If he's
in favor and it can be done in a backwards compatible way then he can guide
you to acceptance and merging of your PR. But like all of us he has limited
time.

On Wed, Mar 10, 2021 at 6:15 AM Laurie O 
wrote:

> I've had tens of people show interest in my proposal, asking what the
> blocker is in acceptance. As far as I know, no Python developer has shown
> any interest in it.
>
> My proposal is to automatically make any non-default fields become
> keyword-only `__init__` parameters, with no need to have any arguments
> passed to the `dataclass` decorator.
>
> My PR: https://github.com/python/cpython/pull/17322
>
> My previous mailing-list message:
> https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IN3D7UQQI4HSKSCUPMU3C3RTUG6NWUKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Laurie O]

I've had tens of people show interest in my proposal, asking what the blocker 
is in acceptance. As far as I know, no Python developer has shown any interest 
in it.

My proposal is to automatically make any non-default fields become keyword-only 
`__init__` parameters, with no need to have any arguments passed to the 
`dataclass` decorator.

My PR: https://github.com/python/cpython/pull/17322

My previous mailing-list message: 
https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Bartosz Marcinkowski]

This has been implemented already in attrs 
https://www.attrs.org/en/stable/examples.html#keyword-only-attributes
so I think it makes sense to just translate this to dataclasses, or treat it as 
a starting point for a discussion if there are any objections to 1-to-1 
translation from attrs.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HPBLPPHPTYTWM5LNG5JJCBQCHGLO4WUI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Ricky Teachey]

On Mon, Feb 10, 2020 at 9:30 AM  wrote:

> It's been two years since this proposal has been postponed - I would like
> to revive it.
>
> > > > ...I propose the addition of a keyword_only flag to the
> > > > @dataclass decorator that renders the __init__ method using
> > > > keyword only arguments:
> > > >
> > > > @dataclass(keyword_only=True)
> > > > class Bar(Foo):
> > > >  other_field: int
> > > >
> > > > --George Leslie-Waksman
>
> Guido van Rossum wrote:
> >  We can reconsider for 3.8.
> > --Guido van Rossum (python.org/~guido)
>
> What do you think about implementing this now? What should be the next
> step? Would it require a PEP?
>

Just lending support to the idea: this would be a fantastic addition to the
dataclasses module and I for one would use it CONSTANTLY.

The style of coding I have become accustomed to relying upon (in the
context of professional engineering calculations and analyses) has tended
to favor kwarg-only arguments a majority of the time, for a variety of
reasons. It's possible I'm creating problems for future me, but I don't
think so. When using a good IDE or Jupyter, kwarg-only functions are far
from a hassle to use, they are really a pleasure to use (and read).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FEXK56XBMP46VKF5WYBFXA3WQDWOLYUP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[b . marcinkowski]

It's been two years since this proposal has been postponed - I would like to 
revive it.

A quick recap (quotes edited for brevity):

> > > On 23 January 2018 at 03:33, George Leslie-Waksman
> > > mailto:waks...@gmail.com> wrote:
> > >
> > > The proposed implementation of dataclasses prevents defining
> > > fields with defaults before fields without defaults. This can
> > > create limitations on logical grouping of fields and on 
> > > inheritance.
> > >
> > > Take, for example, the case:
> > >
> > > @dataclass
> > > class Foo:
> > >  some_default: dict = field(default_factory=dict)
> > >
> > > @dataclass
> > > class Bar(Foo):
> > >  other_field: int
> > >
> > > this results in the error:
> > > TypeError: non-default argument 'other_field' follows default
> > > argument
> > >
> > > I understand that this is a limitation of positional arguments
> > > because the effective __init__ signature is:
> > >
> > > def __init__(self, some_default: dict = ,
> > > other_field: int):
> > >
> > > However, keyword only arguments allow an entirely reasonable
> > > solution to this problem:
> > >
> > > def __init__(self, *, some_default: dict = ,
> > > other_field: int):
> > >
> > > And have the added benefit of making the fields in the
> > __init__
> > > call entirely explicit.
> > >
> > > So, I propose the addition of a keyword_only flag to the
> > > @dataclass decorator that renders the __init__ method using
> > > keyword only arguments:
> > >
> > > @dataclass(keyword_only=True)
> > > class Bar(Foo):
> > >  other_field: int
> > >
> > > --George Leslie-Waksman

Guido van Rossum wrote:
>  We can reconsider for 3.8.
> --Guido van Rossum (python.org/~guido)

What do you think about implementing this now? What should be the next step? 
Would it require a PEP?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Y3N6DIC4NLXY36GLZCXHE4NPO4VTNBGS/
Code of Conduct: http://python.org/psf/codeofconduct/