https://pantsbuild.org/ logo
Join Slack
Powered by
Floating the discussion of removing `frozen_after_...
# development
b
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
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
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
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
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
I guess that makes sense
b
I speak from personal experience. It always disrupts my mental flow when I have to remember the special pants way of doing this
f
Yeah I hear ya. I guess it kinda annoys me that there isn’t a good way to express this pattern in Python.
b
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
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
Well I wouldn't mind refactoring those. It really ain't that bad of a refactor
w
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
Open in Slack
PreviousNext
Powered by