https://pantsbuild.org/ logo
Join Slack
Powered by
Random question: has there been any thought given ...
# development
h
Random question: has there been any thought given to using standard Python3.7 dataclasses and type annotations instead of our custom 
datatype
? Would that be hard to do?
a
yes!
we should do it and it is planned! let me find the ticket
w
i think that we might still end up with some customizations to avoid mutability and prevent overriding 
eq
, but using it as an implementation detail might work.
a
i was trying to start moving towards that when i made 
DatatypeMixin
and 
ChoicesMixin
, to decouple the extended functionality we're looking for from the specific backend implementation
h
You can mark dataclasses as 
frozen=True
šŸ‘ 1
Which emulates immutability to a good enough degree
šŸ‘ 1
w
how do you enforce that they are marked? and/or make that the default.
(anywho: it feels to me like swapping from extending 
namedtuple
to extending "dataclass")
h
Yes Iā€™m hoping to see this. For enforcing that people make it frozen, I think code review should catch most cases
w
Well, that's why superclass. To avoid allowing them to do the wrong
h
We can superclass dataclass then. Sgtm
h
Presumably you can check that they're marked when validating the product graph
extending 
dataclass
is less of a win IMO, because now the code needs to import from Pants again
šŸ‘ 1
a
not necessarily
or at least, pants will accept exactly one type, be it a 
datatype
or 
dataclass
. the surrounding python code should only need a two-way adapter to its own objects
w
And there is nothing enforcing use of datatype with the engine (...yet?). From a sandbox perspective that may eventually be a thing, but it isn't now
a
retweet
Open in Slack
PreviousNext
Powered by