I really like the idea of using Python to generate another .py file with the dynamic definitions taken into account.
That way you separate the "hackery" into a single function or module, document how it works, and have it also annotate the dynamically generated python source containing the class definitions as you need them with top of file doc-string stating "this file was dynamically generated by xxx - don't modify by hand". That way your code is not confusing, you isolate the trick and the resulting source, and you have full source files with all class attributes that developers can look at and source control, rather than looking at a weird looking class definition. It's just a simple python file after all, no tricks. On Fri, Nov 9, 2018 at 11:50 PM Albert-Jan Roskam <sjeik_ap...@hotmail.com> wrote: > > > On 10 Nov 2018 01:03, Steven D'Aprano <st...@pearwood.info> wrote: > > On Thu, Nov 08, 2018 at 11:34:35AM -0500, Avi Gross wrote: > > An interesting discussion that is outside the scope of a group like this > is > > HOW malicious things can be done and perhaps how to avoid them. > > > > Isn't the rule, simply: > > this_is_stupid = eval(input("please enter malicious code: ")) > > ... and other uses range from 'code smell' to 'elegant' (where namedtuple > is an example of the latter) > > > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- *Pablo Lucena* _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor