Re: Instantiating sub-class from super
On 25/10/19 4:29 AM, Frank Millman wrote: On 2019-10-19 12:37 AM, DL Neil via Python-list wrote: On 16/10/19 6:33 PM, Frank Millman wrote: On 2019-10-14 10:55 PM, DL Neil via Python-list wrote: Is there a technique or pattern for taking a (partially-) populated instance of a class, and re-creating it as an instance of one of its sub-classes? Here is a link to an article entitled 'Understanding Hidden Subtypes'. It dates back to 2004, but I think it is still relevant. It addresses precisely the issues that you raise, but from a data-modelling perspective, not a programming one. http://tdan.com/understanding-hidden-subtypes/5193 I found it invaluable, and applied the concepts in my own business/accounting application. Having created the ability to make subtypes visible and explicit, I found all kinds of unexpected uses for them. The article seems to be missing a couple of images (Figure 1 and Figure 2) showing the data relationships. I downloaded the original article onto my computer years ago, and my local copy does have the images, so if you would like to see them let me know and I will upload my version somewhere to make it accessible. Superb! Yes please Frank - I've also approached it from the data/DB side, and thus presumably why I was puzzling over how one implements in Python. (alternatively, email a PDF/similar directly) Hi I have just got back from a few days break and have only seen your message now. Did you see the message I posted on the 17th with a download link? If not, would you like me to post it again? I did spot the later post - but only after I'd written the above. I've been amused by the similarities between their case and ours, and enjoyed learning a lesson (or two?). Thanks and apologies. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 2019-10-19 12:37 AM, DL Neil via Python-list wrote: On 16/10/19 6:33 PM, Frank Millman wrote: On 2019-10-14 10:55 PM, DL Neil via Python-list wrote: Is there a technique or pattern for taking a (partially-) populated instance of a class, and re-creating it as an instance of one of its sub-classes? Here is a link to an article entitled 'Understanding Hidden Subtypes'. It dates back to 2004, but I think it is still relevant. It addresses precisely the issues that you raise, but from a data-modelling perspective, not a programming one. http://tdan.com/understanding-hidden-subtypes/5193 I found it invaluable, and applied the concepts in my own business/accounting application. Having created the ability to make subtypes visible and explicit, I found all kinds of unexpected uses for them. The article seems to be missing a couple of images (Figure 1 and Figure 2) showing the data relationships. I downloaded the original article onto my computer years ago, and my local copy does have the images, so if you would like to see them let me know and I will upload my version somewhere to make it accessible. Superb! Yes please Frank - I've also approached it from the data/DB side, and thus presumably why I was puzzling over how one implements in Python. (alternatively, email a PDF/similar directly) Hi I have just got back from a few days break and have only seen your message now. Did you see the message I posted on the 17th with a download link? If not, would you like me to post it again? Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 18/10/2019 23:57, DL Neil wrote: > On 17/10/19 7:52 AM, MRAB wrote: >> On 2019-10-16 19:43, duncan smith wrote: >>> On 16/10/2019 04:41, DL Neil wrote: On 16/10/19 1:55 PM, duncan smith wrote: > On 15/10/2019 21:36, DL Neil wrote: >> On 16/10/19 12:38 AM, Rhodri James wrote: >>> On 14/10/2019 21:55, DL Neil via Python-list wrote: >> ... >> So, yes, the "label" is unimportant - except to politicians and >> statisticians, who want precise answers from vague collections of >> data... (sigh!) >> > > [snip] > > No not (real) statisticians. People often want us to provide precise > answers, but they don't often get them. > > "It ain’t what you don’t know that gets you into trouble. It’s what > you > know for sure that just ain’t so." (Mark Twain - perhaps) +1 Although, you've undoubtedly heard people attempt to make claims of having 'accurate figures' (even, "that came from Stats") when you told them that the limitations and variations rendered the exercise laughable... My favorite (of the moment) is a local computer store who regularly offer such gems as: (underneath the sales (web-) page for an upmarket *desktop* computer) "people who bought this also bought" followed by at least two portable PC carry cases. They must be rather large carry-bags! (along with such surprises as keyboard, mouse, ...) This morning I turned-down a study for a political group. One study has already been completed and presented. The antagonist wanted an A/B comparison (backing his 'side', of course). I mildly suggested that I would do it, if he'd also pay me to do an A/B/C study, where 'C' was a costing - the economic opportunity cost of 'the people' waiting for 'the government' to make a decision - (and delaying that decision by waiting for "study" after "study" - The UK and their (MPs') inability to decide "Brexit" a particularly disastrous illustration of such) Sorry, don't want to incur the anger of the list-gods - such calculations would be performed in Python (of course) >>> >>> Clearly, all such analyses should be done in Python. Thank God for rpy2, >>> otherwise I'd have to write R code. It's bad enough having to read it >>> occasionally to figure out what's going on under the hood (I like >>> everything about R - except the syntax). >>> > I have too many examples of people ignoring random variation, testing >>> hypotheses on the data that generated the hypotheses, shifting the >>> goalposts, using cum / post hoc ergo propter hoc reasoning, assuming >>> monocausality etc. In some areas these things have become almost >>> standard practice (and they don't really hinder publication as long as >>> they are even moderately well hidden). Of course, it's often about >>> policy promotion, and the economic analyses can be just as bad (e.g. >>> comparing the negative impacts of a policy on the individual with the >>> positive impacts aggregated over a very large population). And if it's >>> about policy promotion a press release is inevitable. So we just need to >>> survey the news media for specific examples. Unfortunately there's no >>> reliable service for telling us what's crap and what isn't. (Go on, >>> somebody pay me, all my data processing / re-analysis will be in Python >>> ;-).) >>> >> Even when using Python, you have to be careful: >> >> Researchers find bug in Python script may have affected hundreds of >> studies >> https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-not-so-cross-platform/ > > > > I think both of our 'Python' comments were made tongue-in-cheek. Sadly > the tool won't guarantee the result... > > > At my first research project, before I'd even completed my first degree, > I noticed a similar fault in some code*. There was I, the youngest, > newest, least-est member of staff, telling the prof/boss and all the > other researchers that they'd made a serious error, upon which various > papers had been based plus a white-paper for government consideration. > Oops! > > (Basic-Plus on DEC PDP/Vax-en introduced a 'virtual storage array', ie > on-disk cf in-RAM. However, it did not wipe the disk-space prior to use > (whereas arrays were zero-ed, IIRC). Thus, random data purporting to be > valid data-entered. Once corrected and re-run "my results" (as they were > termed - not sure if insult or compliment) were not hugely different > from the originals). > > All we can do, is add some checks-and-balances rather than relying on > 'the computer'. > > Upon which point: those of us who learned 'complicated math' with the > aid of a slide-rule, employ a technique of mentally estimating the > result in both the first first few digits and scale - and thus noticing > any completely incongruous 'result'. Even with lessons in "The > Scientific
Re: Instantiating sub-class from super
On 18/10/19 9:27 AM, Eryk Sun wrote: On 10/17/19, MRAB wrote: On 2019-10-17 20:06, Eryk Sun wrote: I'm bugged by how the article mis-characterizes the fundamental problem. The operating system has nothing to do with the order of a directory listing, which varies even with an OS, depending on the file system. The latter could store each entry in a tree structure that's sorted by filename, or it could use a mapping with hash values, or it could simply use the first available slot in a list, based on the order of past create and delete operations. "The operating system has nothing to do with the order of a directory listing"? Well, that depends on the operating system. It might guarantee the order. That would be typically provide no benefit and be an unnecessary expense in the kernel, especially for directories that contain thousands of entries, considering applications typically need a particular sort order anyway. Also, while such a system could make this default order cheap for its own platform-restricted file systems, supporting other file systems such as NTFS and ext3 would bear the cost of having to dynamically sort directory listings instead of just listing the entries as they're naturally stored in the file-system data structures. To be fair to the original developers, not many people develop with multiple platforms in-mind. Perhaps more *nix devs do think 'platform' because the user-community may be MS-Win-based... When building an application, if it works for you, that's great. If others then want to use it, there is an amount of "caveat emptor" - particularly when jumping platforms. With the gift of hind-sight, some ideas may seem weak, even reprehensible; but they worked at the time. Just this morning I was reading about 'legal' Linux file/path syntax, and saw an article which recounted that Bourne (as in -Shell) had a series of files - one for each of the legal characters, which could be used as some sort of lookup. Are there easier ways once RAM has become cheap(er)? NB have no idea of the veracity of this claim. I've been working on a consolidation of personal file/dir-manipulation utilities (as many 'here' know, and have kindly guided/assisted) but have not given any thought to non-Posix systems at all (contrary to the aims of importlib, for example). If someone takes *my* code and tries to run it on MS-Win Python, they'll soon find-out! That said, I'm not expecting to publish any results with the expectation of world-domination... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 17/10/19 7:52 AM, MRAB wrote: On 2019-10-16 19:43, duncan smith wrote: On 16/10/2019 04:41, DL Neil wrote: On 16/10/19 1:55 PM, duncan smith wrote: On 15/10/2019 21:36, DL Neil wrote: On 16/10/19 12:38 AM, Rhodri James wrote: On 14/10/2019 21:55, DL Neil via Python-list wrote: ... So, yes, the "label" is unimportant - except to politicians and statisticians, who want precise answers from vague collections of data... (sigh!) [snip] No not (real) statisticians. People often want us to provide precise answers, but they don't often get them. "It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so." (Mark Twain - perhaps) +1 Although, you've undoubtedly heard people attempt to make claims of having 'accurate figures' (even, "that came from Stats") when you told them that the limitations and variations rendered the exercise laughable... My favorite (of the moment) is a local computer store who regularly offer such gems as: (underneath the sales (web-) page for an upmarket *desktop* computer) "people who bought this also bought" followed by at least two portable PC carry cases. They must be rather large carry-bags! (along with such surprises as keyboard, mouse, ...) This morning I turned-down a study for a political group. One study has already been completed and presented. The antagonist wanted an A/B comparison (backing his 'side', of course). I mildly suggested that I would do it, if he'd also pay me to do an A/B/C study, where 'C' was a costing - the economic opportunity cost of 'the people' waiting for 'the government' to make a decision - (and delaying that decision by waiting for "study" after "study" - The UK and their (MPs') inability to decide "Brexit" a particularly disastrous illustration of such) Sorry, don't want to incur the anger of the list-gods - such calculations would be performed in Python (of course) Clearly, all such analyses should be done in Python. Thank God for rpy2, otherwise I'd have to write R code. It's bad enough having to read it occasionally to figure out what's going on under the hood (I like everything about R - except the syntax). > I have too many examples of people ignoring random variation, testing hypotheses on the data that generated the hypotheses, shifting the goalposts, using cum / post hoc ergo propter hoc reasoning, assuming monocausality etc. In some areas these things have become almost standard practice (and they don't really hinder publication as long as they are even moderately well hidden). Of course, it's often about policy promotion, and the economic analyses can be just as bad (e.g. comparing the negative impacts of a policy on the individual with the positive impacts aggregated over a very large population). And if it's about policy promotion a press release is inevitable. So we just need to survey the news media for specific examples. Unfortunately there's no reliable service for telling us what's crap and what isn't. (Go on, somebody pay me, all my data processing / re-analysis will be in Python ;-).) Even when using Python, you have to be careful: Researchers find bug in Python script may have affected hundreds of studies https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-not-so-cross-platform/ I think both of our 'Python' comments were made tongue-in-cheek. Sadly the tool won't guarantee the result... At my first research project, before I'd even completed my first degree, I noticed a similar fault in some code*. There was I, the youngest, newest, least-est member of staff, telling the prof/boss and all the other researchers that they'd made a serious error, upon which various papers had been based plus a white-paper for government consideration. Oops! (Basic-Plus on DEC PDP/Vax-en introduced a 'virtual storage array', ie on-disk cf in-RAM. However, it did not wipe the disk-space prior to use (whereas arrays were zero-ed, IIRC). Thus, random data purporting to be valid data-entered. Once corrected and re-run "my results" (as they were termed - not sure if insult or compliment) were not hugely different from the originals). All we can do, is add some checks-and-balances rather than relying on 'the computer'. Upon which point: those of us who learned 'complicated math' with the aid of a slide-rule, employ a technique of mentally estimating the result in both the first first few digits and scale - and thus noticing any completely incongruous 'result'. Even with lessons in "The Scientific Approach" am not aware that the 'calculator' or 'computer generations' were/are taught such 'common sense'... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 17/10/19 4:08 AM, Piet van Oostrum wrote: DL Neil writes: 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 transition. So what if a person has both ovaries and testes? It is better to keep all options open rather than making hasty subdivisions. Exactly! The objective is not to sub-divide, but to ensure that those to whom various questions are relevant have their answers recorded, but those for whom the section is irrelevant are not over-burdened. In this context that means attributes (that can be None) rather than subclasses. Which seems to be the way we're headed... Thanks! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 16/10/19 6:33 PM, Frank Millman wrote: On 2019-10-14 10:55 PM, DL Neil via Python-list wrote: Is there a technique or pattern for taking a (partially-) populated instance of a class, and re-creating it as an instance of one of its sub-classes? Here is a link to an article entitled 'Understanding Hidden Subtypes'. It dates back to 2004, but I think it is still relevant. It addresses precisely the issues that you raise, but from a data-modelling perspective, not a programming one. http://tdan.com/understanding-hidden-subtypes/5193 I found it invaluable, and applied the concepts in my own business/accounting application. Having created the ability to make subtypes visible and explicit, I found all kinds of unexpected uses for them. The article seems to be missing a couple of images (Figure 1 and Figure 2) showing the data relationships. I downloaded the original article onto my computer years ago, and my local copy does have the images, so if you would like to see them let me know and I will upload my version somewhere to make it accessible. Superb! Yes please Frank - I've also approached it from the data/DB side, and thus presumably why I was puzzling over how one implements in Python. (alternatively, email a PDF/similar directly) -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 10/17/19, MRAB wrote: > On 2019-10-17 20:06, Eryk Sun wrote: > >> I'm bugged by how the article mis-characterizes the fundamental >> problem. The operating system has nothing to do with the order of a >> directory listing, which varies even with an OS, depending on the file >> system. The latter could store each entry in a tree structure that's >> sorted by filename, or it could use a mapping with hash values, or it >> could simply use the first available slot in a list, based on the >> order of past create and delete operations. >> > "The operating system has nothing to do with the order of a directory > listing"? > > Well, that depends on the operating system. It might guarantee the order. That would be typically provide no benefit and be an unnecessary expense in the kernel, especially for directories that contain thousands of entries, considering applications typically need a particular sort order anyway. Also, while such a system could make this default order cheap for its own platform-restricted file systems, supporting other file systems such as NTFS and ext3 would bear the cost of having to dynamically sort directory listings instead of just listing the entries as they're naturally stored in the file-system data structures. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 2019-10-17 20:06, Eryk Sun wrote: On 10/17/19, Dennis Lee Bieber wrote: On Wed, 16 Oct 2019 19:52:50 +0100, MRAB declaimed the following: Researchers find bug in Python script may have affected hundreds of studies https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-not-so-cross-platform/ That article bugs me... As I understand it, the results are affected by the ORDER in which, otherwise independent, file NAMES were returned by the OS. Fine: manually ordering the names by some algorithm produces consistent results across various OSs -- but what evidence is there that this file name sort is producing "correct" results? What is the sorting criteria -- it is not mentioned in the article. Are the file names time-stamped (in which case a time-ordered sort does make sense)? I'm bugged by how the article mis-characterizes the fundamental problem. The operating system has nothing to do with the order of a directory listing, which varies even with an OS, depending on the file system. The latter could store each entry in a tree structure that's sorted by filename, or it could use a mapping with hash values, or it could simply use the first available slot in a list, based on the order of past create and delete operations. "The operating system has nothing to do with the order of a directory listing"? Well, that depends on the operating system. It might guarantee the order. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 10/17/19, Dennis Lee Bieber wrote: > On Wed, 16 Oct 2019 19:52:50 +0100, MRAB > declaimed the following: > >>Researchers find bug in Python script may have affected hundreds of >> studies >>https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-not-so-cross-platform/ > > That article bugs me... > > As I understand it, the results are affected by the ORDER in which, > otherwise independent, file NAMES were returned by the OS. > > Fine: manually ordering the names by some algorithm produces consistent > results across various OSs -- but what evidence is there that this file > name sort is producing "correct" results? What is the sorting criteria -- > it is not mentioned in the article. Are the file names time-stamped (in > which case a time-ordered sort does make sense)? I'm bugged by how the article mis-characterizes the fundamental problem. The operating system has nothing to do with the order of a directory listing, which varies even with an OS, depending on the file system. The latter could store each entry in a tree structure that's sorted by filename, or it could use a mapping with hash values, or it could simply use the first available slot in a list, based on the order of past create and delete operations. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 2019-10-16 7:33 AM, Frank Millman wrote: Here is a link to an article entitled 'Understanding Hidden Subtypes'. It dates back to 2004, but I think it is still relevant. It addresses precisely the issues that you raise, but from a data-modelling perspective, not a programming one. http://tdan.com/understanding-hidden-subtypes/5193 I found it invaluable, and applied the concepts in my own business/accounting application. Having created the ability to make subtypes visible and explicit, I found all kinds of unexpected uses for them. The article seems to be missing a couple of images (Figure 1 and Figure 2) showing the data relationships. I downloaded the original article onto my computer years ago, and my local copy does have the images, so if you would like to see them let me know and I will upload my version somewhere to make it accessible. I received a couple of requests for a link to the original article, so I uploaded it to filebin. Here is the link - https://filebin.net/1ia5kcq2sbp57t1o The file will be deleted automatically in one week. I don't know if that is good netiquette. Should I use a site where it never expires? Google Drive? Recommendations welcome. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 16/10/2019 19:52, MRAB wrote: > On 2019-10-16 19:43, duncan smith wrote: >> On 16/10/2019 04:41, DL Neil wrote: >>> On 16/10/19 1:55 PM, duncan smith wrote: On 15/10/2019 21:36, DL Neil wrote: > On 16/10/19 12:38 AM, Rhodri James wrote: >> On 14/10/2019 21:55, DL Neil via Python-list wrote: > ... > So, yes, the "label" is unimportant - except to politicians and > statisticians, who want precise answers from vague collections of > data... (sigh!) > [snip] No not (real) statisticians. People often want us to provide precise answers, but they don't often get them. "It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so." (Mark Twain - perhaps) >>> >>> +1 >>> >>> Although, you've undoubtedly heard people attempt to make claims of >>> having 'accurate figures' (even, "that came from Stats") when you told >>> them that the limitations and variations rendered the exercise >>> laughable... >>> >>> My favorite (of the moment) is a local computer store who regularly >>> offer such gems as: (underneath the sales (web-) page for an upmarket >>> *desktop* computer) "people who bought this also bought" followed by at >>> least two portable PC carry cases. They must be rather large carry-bags! >>> (along with such surprises as keyboard, mouse, ...) >>> >>> This morning I turned-down a study for a political group. One study has >>> already been completed and presented. The antagonist wanted an A/B >>> comparison (backing his 'side', of course). I mildly suggested that I >>> would do it, if he'd also pay me to do an A/B/C study, where 'C' was a >>> costing - the economic opportunity cost of 'the people' waiting for 'the >>> government' to make a decision - (and delaying that decision by waiting >>> for "study" after "study" - The UK and their (MPs') inability to decide >>> "Brexit" a particularly disastrous illustration of such) >>> >>> >>> Sorry, don't want to incur the anger of the list-gods - such >>> calculations would be performed in Python (of course) >> >> Clearly, all such analyses should be done in Python. Thank God for rpy2, >> otherwise I'd have to write R code. It's bad enough having to read it >> occasionally to figure out what's going on under the hood (I like >> everything about R - except the syntax). >> > I have too many examples of people ignoring random variation, testing >> hypotheses on the data that generated the hypotheses, shifting the >> goalposts, using cum / post hoc ergo propter hoc reasoning, assuming >> monocausality etc. In some areas these things have become almost >> standard practice (and they don't really hinder publication as long as >> they are even moderately well hidden). Of course, it's often about >> policy promotion, and the economic analyses can be just as bad (e.g. >> comparing the negative impacts of a policy on the individual with the >> positive impacts aggregated over a very large population). And if it's >> about policy promotion a press release is inevitable. So we just need to >> survey the news media for specific examples. Unfortunately there's no >> reliable service for telling us what's crap and what isn't. (Go on, >> somebody pay me, all my data processing / re-analysis will be in Python >> ;-).) >> > Even when using Python, you have to be careful: > > Researchers find bug in Python script may have affected hundreds of studies > https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-not-so-cross-platform/ > Yes, the problem of standing on the shoulders of others (not necessarily giants). I assume the problematic code was tested on an OS that happened to sort the results as required. Years ago I had a similar issue with a race condition, but we caught it because I developed the code under Linux and everybody else on the project ran it under Windows (where the bug surfaced). Note to self: before I do any more parallel programming check out how to test for race conditions. Duncan -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
> On 14 Oct 2019, at 21:55, DL Neil via Python-list > wrote: > > Is there a technique or pattern for taking a (partially-) populated instance > of a class, and re-creating it as an instance of one of its sub-classes? The pattern I know is to use a factory function to choose between a number of concrete classes based on some information. In this case it seems that after collecting enough information you could create such a class. The other thought is to have the classes support a method that returns a "better" class. x.setProp(...) x = x.upgradeInstance() I have seen code that messes around with __class__ but I think that its a maintenance issue to do that. Apart from the person who writes that code would have a clue what it's doing. Barry > > > In a medically-oriented situation, we have a Person() class, and start > collecting information within an instance (person = Person(), etc). > > During the data-collection process the person's sex may become obvious, eg > few males have become/been pregnant. > > We could stick with Person() and implement specific methods therein, rather > than separate Man and Woman sub-classes, but... > > 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 gender. > > In coding-practice, once gender becomes apparent, how should the instance of > the Man() or Woman() sub-class be created - and established with the ID and > other attributes previously collected as a Person instance? > > This attempt seems hack-y: > > man = Man() > man.__dict__.update( person.__dict__ ) > > > Is there a pythonic tool for such, or is the task outlined > fundamentally-inappropriate? > > -- > Regards, > =dn > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 2019-10-16 19:43, duncan smith wrote: On 16/10/2019 04:41, DL Neil wrote: On 16/10/19 1:55 PM, duncan smith wrote: On 15/10/2019 21:36, DL Neil wrote: On 16/10/19 12:38 AM, Rhodri James wrote: On 14/10/2019 21:55, DL Neil via Python-list wrote: ... So, yes, the "label" is unimportant - except to politicians and statisticians, who want precise answers from vague collections of data... (sigh!) [snip] No not (real) statisticians. People often want us to provide precise answers, but they don't often get them. "It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so." (Mark Twain - perhaps) +1 Although, you've undoubtedly heard people attempt to make claims of having 'accurate figures' (even, "that came from Stats") when you told them that the limitations and variations rendered the exercise laughable... My favorite (of the moment) is a local computer store who regularly offer such gems as: (underneath the sales (web-) page for an upmarket *desktop* computer) "people who bought this also bought" followed by at least two portable PC carry cases. They must be rather large carry-bags! (along with such surprises as keyboard, mouse, ...) This morning I turned-down a study for a political group. One study has already been completed and presented. The antagonist wanted an A/B comparison (backing his 'side', of course). I mildly suggested that I would do it, if he'd also pay me to do an A/B/C study, where 'C' was a costing - the economic opportunity cost of 'the people' waiting for 'the government' to make a decision - (and delaying that decision by waiting for "study" after "study" - The UK and their (MPs') inability to decide "Brexit" a particularly disastrous illustration of such) Sorry, don't want to incur the anger of the list-gods - such calculations would be performed in Python (of course) Clearly, all such analyses should be done in Python. Thank God for rpy2, otherwise I'd have to write R code. It's bad enough having to read it occasionally to figure out what's going on under the hood (I like everything about R - except the syntax). > I have too many examples of people ignoring random variation, testing hypotheses on the data that generated the hypotheses, shifting the goalposts, using cum / post hoc ergo propter hoc reasoning, assuming monocausality etc. In some areas these things have become almost standard practice (and they don't really hinder publication as long as they are even moderately well hidden). Of course, it's often about policy promotion, and the economic analyses can be just as bad (e.g. comparing the negative impacts of a policy on the individual with the positive impacts aggregated over a very large population). And if it's about policy promotion a press release is inevitable. So we just need to survey the news media for specific examples. Unfortunately there's no reliable service for telling us what's crap and what isn't. (Go on, somebody pay me, all my data processing / re-analysis will be in Python ;-).) Even when using Python, you have to be careful: Researchers find bug in Python script may have affected hundreds of studies https://arstechnica.com/information-technology/2019/10/chemists-discover-cross-platform-python-scripts-not-so-cross-platform/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 16/10/2019 04:41, DL Neil wrote: > On 16/10/19 1:55 PM, duncan smith wrote: >> On 15/10/2019 21:36, DL Neil wrote: >>> On 16/10/19 12:38 AM, Rhodri James wrote: On 14/10/2019 21:55, DL Neil via Python-list wrote: >>> ... >>> So, yes, the "label" is unimportant - except to politicians and >>> statisticians, who want precise answers from vague collections of >>> data... (sigh!) >>> >> >> [snip] >> >> No not (real) statisticians. People often want us to provide precise >> answers, but they don't often get them. >> >> "It ain’t what you don’t know that gets you into trouble. It’s what you >> know for sure that just ain’t so." (Mark Twain - perhaps) > > +1 > > Although, you've undoubtedly heard people attempt to make claims of > having 'accurate figures' (even, "that came from Stats") when you told > them that the limitations and variations rendered the exercise laughable... > > My favorite (of the moment) is a local computer store who regularly > offer such gems as: (underneath the sales (web-) page for an upmarket > *desktop* computer) "people who bought this also bought" followed by at > least two portable PC carry cases. They must be rather large carry-bags! > (along with such surprises as keyboard, mouse, ...) > > This morning I turned-down a study for a political group. One study has > already been completed and presented. The antagonist wanted an A/B > comparison (backing his 'side', of course). I mildly suggested that I > would do it, if he'd also pay me to do an A/B/C study, where 'C' was a > costing - the economic opportunity cost of 'the people' waiting for 'the > government' to make a decision - (and delaying that decision by waiting > for "study" after "study" - The UK and their (MPs') inability to decide > "Brexit" a particularly disastrous illustration of such) > > > Sorry, don't want to incur the anger of the list-gods - such > calculations would be performed in Python (of course) Clearly, all such analyses should be done in Python. Thank God for rpy2, otherwise I'd have to write R code. It's bad enough having to read it occasionally to figure out what's going on under the hood (I like everything about R - except the syntax). I have too many examples of people ignoring random variation, testing hypotheses on the data that generated the hypotheses, shifting the goalposts, using cum / post hoc ergo propter hoc reasoning, assuming monocausality etc. In some areas these things have become almost standard practice (and they don't really hinder publication as long as they are even moderately well hidden). Of course, it's often about policy promotion, and the economic analyses can be just as bad (e.g. comparing the negative impacts of a policy on the individual with the positive impacts aggregated over a very large population). And if it's about policy promotion a press release is inevitable. So we just need to survey the news media for specific examples. Unfortunately there's no reliable service for telling us what's crap and what isn't. (Go on, somebody pay me, all my data processing / re-analysis will be in Python ;-).) Duncan -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
DL Neil writes: > 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 > transition. So what if a person has both ovaries and testes? It is better to keep all options open rather than making hasty subdivisions. In this context that means attributes (that can be None) rather than subclasses. -- Piet van Oostrum WWW: http://piet.vanoostrum.org/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 2019-10-14 10:55 PM, DL Neil via Python-list wrote: Is there a technique or pattern for taking a (partially-) populated instance of a class, and re-creating it as an instance of one of its sub-classes? In a medically-oriented situation, we have a Person() class, and start collecting information within an instance (person = Person(), etc). During the data-collection process the person's sex may become obvious, eg few males have become/been pregnant. We could stick with Person() and implement specific methods therein, rather than separate Man and Woman sub-classes, but... 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 gender. In coding-practice, once gender becomes apparent, how should the instance of the Man() or Woman() sub-class be created - and established with the ID and other attributes previously collected as a Person instance? This attempt seems hack-y: man = Man() man.__dict__.update( person.__dict__ ) Is there a pythonic tool for such, or is the task outlined fundamentally-inappropriate? Here is a link to an article entitled 'Understanding Hidden Subtypes'. It dates back to 2004, but I think it is still relevant. It addresses precisely the issues that you raise, but from a data-modelling perspective, not a programming one. http://tdan.com/understanding-hidden-subtypes/5193 I found it invaluable, and applied the concepts in my own business/accounting application. Having created the ability to make subtypes visible and explicit, I found all kinds of unexpected uses for them. The article seems to be missing a couple of images (Figure 1 and Figure 2) showing the data relationships. I downloaded the original article onto my computer years ago, and my local copy does have the images, so if you would like to see them let me know and I will upload my version somewhere to make it accessible. Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 16/10/19 1:55 PM, duncan smith wrote: On 15/10/2019 21:36, DL Neil wrote: On 16/10/19 12:38 AM, Rhodri James wrote: On 14/10/2019 21:55, DL Neil via Python-list wrote: ... So, yes, the "label" is unimportant - except to politicians and statisticians, who want precise answers from vague collections of data... (sigh!) [snip] No not (real) statisticians. People often want us to provide precise answers, but they don't often get them. "It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so." (Mark Twain - perhaps) +1 Although, you've undoubtedly heard people attempt to make claims of having 'accurate figures' (even, "that came from Stats") when you told them that the limitations and variations rendered the exercise laughable... My favorite (of the moment) is a local computer store who regularly offer such gems as: (underneath the sales (web-) page for an upmarket *desktop* computer) "people who bought this also bought" followed by at least two portable PC carry cases. They must be rather large carry-bags! (along with such surprises as keyboard, mouse, ...) This morning I turned-down a study for a political group. One study has already been completed and presented. The antagonist wanted an A/B comparison (backing his 'side', of course). I mildly suggested that I would do it, if he'd also pay me to do an A/B/C study, where 'C' was a costing - the economic opportunity cost of 'the people' waiting for 'the government' to make a decision - (and delaying that decision by waiting for "study" after "study" - The UK and their (MPs') inability to decide "Brexit" a particularly disastrous illustration of such) Sorry, don't want to incur the anger of the list-gods - such calculations would be performed in Python (of course) -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 15/10/2019 21:36, DL Neil wrote: > 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 gender. >> >> 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 > list-advice. > > 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 > transition. > > So, yes, the "label" is unimportant - except to politicians and > statisticians, who want precise answers from vague collections of > data... (sigh!) > [snip] No not (real) statisticians. People often want us to provide precise answers, but they don't often get them. "It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so." (Mark Twain - perhaps) Duncan -- https://mail.python.org/mailman/listinfo/python-list
Re: 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 gender. 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 list-advice. 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 transition. So, yes, the "label" is unimportant - except to politicians and statisticians, who want precise answers from vague collections of data... (sigh!) 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 -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
On 14/10/2019 21:55, DL Neil via Python-list wrote: Is there a technique or pattern for taking a (partially-) populated instance of a class, and re-creating it as an instance of one of its sub-classes? In a medically-oriented situation, we have a Person() class, and start collecting information within an instance (person = Person(), etc). During the data-collection process the person's sex may become obvious, eg few males have become/been pregnant. We could stick with Person() and implement specific methods therein, rather than separate Man and Woman sub-classes, but... 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 gender. 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? -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
Hi Greg,
On 15/10/19 11:37 AM, Gregory Ewing wrote:
DL Neil wrote:
Is there a technique or pattern for taking a (partially-) populated
instance of a class, and re-creating it as an instance of one of its
sub-classes?
Often you can assign to the __class__ attribute of an instance
to change its class.
Python 3.7.3 (default, Apr 8 2019, 22:20:19)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Person:
... pass
...
>>> class Male(Person):
... pass
...
>>> p = Person()
>>> p.__class__ = Male
>>> isinstance(p, Male)
True
>>>
Brilliantly easy. Thanks!
Is this manipulation documented/explained anywhere? Would you describe
it as 'good practice', or even: sensible?
You would then be responsible for initialising any attributes of
Male that Person didn't have.
Understood.
The contents of Person.__init__( -whatever- ) are executed at instantiation.
The contents of Male.__init__( - whatever- ) will be executed during a
'normal' instantiation.
If, however, a Person-instance is 'converted'* into a Male-instance,
then Male.__init__() will not be executed.
(haven't bothered to experiment with an explicit call, because...)
In this case, that is not an issue, because apart from the value of
"sex", the __init__() actions are all provided by super().
Further experimentation revealed something I wasn't sure to expect. Thus
although:
class Male( Person ):
etc
class Person():
etc
won't work, because Person has yet to be defined; in the correct
sequence, we *can* 'anticipate' names within the super-class:
class Person():
etc
def convert( self ):
self.__class__ = Male
class Male( Person ):
etc
Agreed, better is:
def convert( self, sub_class ):
self.__class__ = sub_class
...
p = Person()
p.convert( Male )
Amusingly enough, could "convert"* the p-instance again-and-again.
* careful terminology!
PoC code:
class Person():
def __init__( self ):
self.ID = "Respondent"
self.converter = { "M":Male, "F":Female }
def questionnaire( self, sex ):
self.sex = sex
def super_function( self ):
print( "Pulling on tights and donning cape..." )
def convert( self ):
self.__class__ = self.converter[ self.sex ]
class Male( Person ):
def male_only( self ):
print( "I am secure in my man-hood" )
class Female( Person ):
def female_only( self ):
print( "Thy name is vanity" )
p = Person()
print( "PersonOBJ ~", p )
print( "Person __class__ ~", p.__class__ )
print( "PersonID ~", p.ID )
p.questionnaire( "M" )
print( "M, MaleOBJ ~", p.sex, p.converter[ p.sex ] )
p.convert()
print( "PersonOBJ ~", p )
print( "Person __class__ ~", p.__class__ )
print( "PersonID ~", p.ID )
p.male_only()
p.super_function()
p.questionnaire( "F" )
print( "F, FemaleOBJ ~", p.sex, p.converter[ p.sex ] )
p.convert()
print( "PersonOBJ ~", p )
print( "Person __class__ ~", p.__class__ )
print( "PersonID ~", p.ID )
p.female_only()
p.super_function()
p.male_only() # Exception
Output:
Showing that:
- the object remains the same, even as its type/class is 'converted'
- the object retains any value established before 'conversion'
or, the 'conversion' process carries-across all data-attributes
- after conversion the sub-class's methods become available
- after conversion the super-class's methods remain available
- after a further 'conversion', the same experience
but methods particular to the first conversion have been 'lost'.
(as expected)
[~]$ python3 person.py
PersonOBJ ~ <__main__.Person object at 0x7f014085bdd0>
Person __class__ ~
PersonID ~ Respondent
M, MaleOBJ ~ M
PersonOBJ ~ <__main__.Male object at 0x7f014085bdd0>
Person __class__ ~
PersonID ~ Respondent
I am secure in my man-hood
Pulling on tights and donning cape...
F, FemaleOBJ ~ F
PersonOBJ ~ <__main__.Female object at 0x7f014085bdd0>
Person __class__ ~
PersonID ~ Respondent
Thy name is vanity
Pulling on tights and donning cape...
Traceback (most recent call last):
File "person.py", line 58, in
p.male_only() # Exception
AttributeError: 'Female' object has no attribute 'male_only'
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Instantiating sub-class from super
DL Neil wrote: Is there a technique or pattern for taking a (partially-) populated instance of a class, and re-creating it as an instance of one of its sub-classes? Often you can assign to the __class__ attribute of an instance to change its class. Python 3.7.3 (default, Apr 8 2019, 22:20:19) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class Person: ... pass ... >>> class Male(Person): ... pass ... >>> p = Person() >>> p.__class__ = Male >>> isinstance(p, Male) True >>> You would then be responsible for initialising any attributes of Male that Person didn't have. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
