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 <p.f.mo...@gmail.com> wrote:
> On Tue, 3 May 2022 at 17:46, Christopher Barker <python...@gmail.com>
> wrote:
> > On Tue, May 3, 2022 at 5:39 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> >>
> >> > > I have classes with 20+ parameters (packaging metadata). You can
> argue
> >> > > that a dataclass would be better,
> >
> > I sure would — I’ve done exactly this, and it seems to me to be exactly
> the right solution.
>
> Sorry, you're right. There are issues with a dataclass based approach
> (I've tried it, so I know ;-)) but they aren't around repeating self.x
> = x over and over. My point here was that the @-based solution isn't
> useful as often as people are claiming.
Agreed here -- I'm probably responsible for much of the talk about
dataclasses, so sorry about that. In fact, my only point there was that
dataclasses are a solution to the "I'm writing many versions of self.x = x
in my __init__ method, and that seems unnecessary" problem, and that I
think that very problem is the strongest case for auto-assignment. Ergo,
auto-assignment isn't a critical feature.
> "lots of
> parameters are simply hard, and in practical cases, @ doesn't help
> enough to make a difference"
Agreed -- if it's a complex case, neither datclasses nor auto-assignment
would help.
I've used attrs, which has field converters.
...
> The problem with __post_init__ (I think) is
> that it confuses the type checkers (beware, untested code below!):
>
Does the attrs approach work any better for this?
@dataclass
> class Metadata:
> version: str # Actually a Version, but that's not the type we
> want the constructor to accept.
>
> def __post_init__(self):
> self.version = Version(self.version)
>
> And the reality is worse. We want the constructor to take a Version,
> or anything that can be converted to a Version
> (which, if I check the
> source of the library, *is* just str - but I don't want to necessarily
> copy that declaration as it might change). And yet we want the
> typechecker to know that metadata.version is always a Version. All of
> that information is available statically (we call Version on the input
> data, and self.version is always the result of that call) but I can't
> see how to explain that to the type checker.
Frankly, I see that as a limitation of static typing -- how does one
describe "anything that can be turned into a Version? -- sure, the Version
__init__ can take either a Version or a str -- but only certain strs will
make any sense -- so what's the point?
Honestly, I think if you want your code to be statically "safe" then you
should have this metadata class require a Version object, which would
require its users to do the conversion first.
Which is why I like the Dynamic nature of Python, and haven't gotten
excited about static typing.
I suppose the way to solve this without dataclasses or auto-assignment is
to type the class attribute and the __init__ parameter separately, yes?
(which auto-assignment wouldn't help with, either)
(untested, and probably wrong, 'cause I'm not that familiar with typing)
Class Metadata:
version: Version
...
def __init__(self, version: Version | str, ...):
...
Is that right?
What this tells me is that if you want dataclasses to be more
typing-friendly, then there should be a way to specify the __init__ type
separately, which could be done with a parameter to the Field object.
Bringing it back OT:
As much as I hate to say it: For folks advocating an auto-assignment
feature -- you should probably consider how it would play with static
typing :-(
-CHB
> I'm not obsessive about
> typing, but dataclasses do naturally encourage using them. And if I do
> use types, I want them to be *right*, or VS Code and mypy will spend
> all their time complaining about correct code :-(
>
> This is all irrelevant to the discussion at hand, and quite possibly
> way too nitpicking to even be worth caring about, but it's what I mean
> when I say "things are still hard".
>
> Paul
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/RELK2ZD5VXKH3PPXX4JNY7KGKZSNDN37/
Code of Conduct: http://python.org/psf/codeofconduct/
