Instantiating sub-class from super
On 16/10/19 12:38 AM, Rhodri James wrote:
> On 14/10/2019 21:55, DL Neil via Python-list wrote:
>> It seemed better (at the design-level) to have Man( Person ) and
>> Woman( Person ) sub-classes to contain the pertinent attributes,
>> source more detailed and specific questions, and collect such data; by
> Knowing a lot of Trans people as I do, may I gently suggest that this
> solution will find many and varied ways of coming back to bite you?
[with more respect than the previous humor]
You are absolutely correct. The use-case was (over-)simplified, per
That said, if a "trans" person has ovaries or testes (for example) then
a non-traditional sexual identification is irrelevant - for medical
purposes. Diseases in those areas (and now I'm a long way from a
research questionnaire and from Python - but this is roughly how it was
explained to me) still apply, and sadly, may in-fact be considerably
complicated by any medical processes that may have contributed to a
So, yes, the "label" is unimportant - except to politicians and
statisticians, who want precise answers from vague collections of
FYI: This country has been leading the way, to the point where even
asking such questions is no longer allowed under many circumstances.
Back to Python: yes, the model is considerably complicated because there
are no 'straight lines' to divide - that, and the rather arcane
DB-structure we've inherited (which contributed to pilot-ing the
sub-class route) are leading us back to the idea of a 'monolithic'
Person class* with loads of data-points/flags and
conditional-executions, to take care of individual differences and
meeting the (medical) objectives of the questionnaire. Perhaps one of
the physicians will prescribe a head-ache remedy?
* without denigrating the generosity of those who helped with the OP