https://pantsbuild.org/ logo
#development
Title
# development
b

bitter-ability-32190

01/09/2023, 7:39 PM
Floating the discussion of removing
frozen_after_init
in lieu of doing what the Python docs recommend in this case: using
object.__setattr__
. See Python docs And FWIW I didn't see this discussed when
frozen_after_init
was introduced: https://github.com/pantsbuild/pants/pull/8431 The motivation is lowering the entry bar for plugin authors: Just do as the Romans do...
😕 1
👍 2
It's ugly because new code looks like:
object.__setattr__(self, "attrname", attrvalue)
instead of
self.attrname = attrvalue
but thats the current art
f

flat-zoo-31952

01/09/2023, 8:55 PM
Is
frozen_after_init
really that much of an additional burden for learners of plugins? I feel like the bit about "throw out virtually anything you know in Python that does IO because you need to interact with a Pants Monad to do anything" is a much bigger hurdle. If anything
frozen_after_init
felt like a welcome convenience because if I'm being forced to use frozen dataclasses to represent all info, at I have this way out.
AFAICT most of the outs that people use
frozen_after_init
for are to do validation, coercion, or other conversion. Would have been nice to use attrs for this rather than dataclasses, but it's too late now, as that's a massive API change attrs and dataclassess can't subclass the other type
b

bitter-ability-32190

01/09/2023, 9:03 PM
It's a death by a thousand paper cuts, and it can only be fixed by healing each one. Just because we might have a huge gash somewhere doesn't mean we can't, and shouldn't try and heal a single one
We try not to increase our surface area wmr.tm 3rdparty packages, and yes most usages are for converters
f

flat-zoo-31952

01/09/2023, 9:08 PM
Yeah I'm with you on the 3rdparty thing for this case, although personally I tend to use
attrs
in all my projects when I can.
But I still think
frozen_after_init
is very useful and simple enough to grok in a minute or two, even if it is a parochialism
b

bitter-ability-32190

01/09/2023, 9:35 PM
TBF the problem isn't specifically frozen_after_init, but the fact that you: • Don't use frozen • Have to use unsafe_hash because.... Reasons (I know why, but do newcomers) • Mypy won't help you if you try and set attributes Instead it's much more ideal to do "the normal thing" instead of inventing our own special little way
f

flat-zoo-31952

01/09/2023, 11:12 PM
I guess that makes sense
b

bitter-ability-32190

01/09/2023, 11:24 PM
I speak from personal experience. It always disrupts my mental flow when I have to remember the special pants way of doing this
f

flat-zoo-31952

01/09/2023, 11:54 PM
Yeah I hear ya. I guess it kinda annoys me that there isn’t a good way to express this pattern in Python.
b

bitter-ability-32190

01/09/2023, 11:58 PM
Not in a typesafe way at least 😅
Also FWIW I floated the idea of adding converter support to dataclass_transform to the typing SIG and the answer was a warm "why not just add it to dataclass?" So I might be PEPing that 😅
🤔 1
@witty-crayon-22786 @happy-kitchen-89482 y'all got thoughts?
h

happy-kitchen-89482

01/10/2023, 2:19 AM
Hmmm
I'm not convinced that this is worth the amount of disruption it will cause, but I am open to being convinced.
Although I suppose we don't have to do a big retcon of all the existing frozen_after_init classes. We can introduce this gradually over time.
There are currently 87 such dataclasses
b

bitter-ability-32190

01/10/2023, 2:43 AM
Well I wouldn't mind refactoring those. It really ain't that bad of a refactor
w

witty-crayon-22786

01/10/2023, 5:55 PM
before
frozen_after_init
, we used to use
__new__
overrides to add constructor logic to namedtuples. i suppose that that isn’t possible with dataclasses, but it was reasonably nice