Package: ocd
Do you come from a C++ background? Are you very fond of the popular access modifiers such aspublic,private,protectedetc? Do you worry that some of your python programs will be used by new pythonists and they will abuse your private variables?Well, veteran pythonists will tell you, that, this behavior is over-obsessive and programmers in the python world are all adult people (which is true). In python, you don't usually worry about public or private, instead, you think of internal variables and follow a convention: use a single leading underscore for internal variables (e.g_varname) and two leading underscores if you want name mangling inside a class (e.g__varname). This does not make them protected or private, but python programmers will know whether they are internal, from the leading underscore.Now, some people may still want to protect some of their variables from unknown changes, make them readonly, undeletable, etc. For example:classDefaults():STRONG=2WEAK=1Let's say, some new python programmer is using this piece of code and passingDefaults.WEAKin some methods. Suddenly, he decides that, he will useSTRONGinstead ofWEAKand instead of going through all occurrences ofDefaults.WEAKusage, he does the laziest thing to do: he monkey patches the code:Defaults.WEAK=Defaults.STRONGWith this single line of code, his goal will be accomplished but it's going to be catastrophic if he is not careful (which he is obviously not). This guy may later go to your issue page and open an issue saying that some part of your code is not working as expected.To mitigate this kind of scenario, your obsession might not be that bad of an idea. Now, introducingocdaka Obsessive Coder's Demeanor (made different from Obsessive Compulsive Disorder on purpose :D). Usingocdyou can make your variables readonly, undeletable or both. They can be protected from class or class instances or both.Auto property creationReadonly propertyfromocd.propimportPropfromocd.mixinsimportPropMixinclassDefaults(PropMixin):STRONG=Prop(2,readonly=True)WEAK=Prop(1,readonly=True)# use is the same as before: Defaults.STRONG and Defaults.WEAKThis time, that monkey patch code will raise an exception:Defaults.WEAK=Defaults.STRONG# exception, readonly property value can not be changed.The class attributes have been made into readonly properties, but they are still deletable, which exposes the following vulnerability:delDefaults.WEAKDefaults.WEAK=Defaults.STRONG# now it's OKand we have the following solution:Undead propertyclassDefaults(PropMixin):STRONG=Prop(2,readonly=True,undead=True)WEAK=Prop(1,readonly=True,undead=True)You just need to say, it's an undead property. This time, the monkey patching will fail again:delDefaults.WEAK# exception, undead property can not be deletedDefaults.WEAK=Defaults.STRONGMore intuitive way to make readonly and undead propertiesYou may think that writingProp(2, readonly=True, undead=True)and just2is a big difference and it is. So, we have a solution for this:fromocdimportdefaultsclassDefaults(PropMixin):VarConf=defaults.VarConfAllUnroSTRONG=2WEAK=1Now, all the attributes that do not start with an underscore('_') will be converted to readonly, undead properties. This is because ofVarConf = defaults.VarConfAllUnro.VarConfis a configuration class that needs to define a methodget_conf. The above is roughly equivalent to:classDefaults(PropMixin):classVarConf(defaults.VarConfNone):defget_conf(self,name,value):returnProp(readonly=True,undead=True)STRONG=2WEAK=1As you can see, theget_confmethod has two parameters: name (property name) and value (value of the property), thus, you can decide which one will be what kind of property according to their names and values. You can match names/values with a pattern and make them readonly, match with another pattern and make them non-readonly, or match with another pattern to make them both readonly and undead, etc. You can returnNonefor an attribute to not apply any property conversion on that specific attribute.NotesWe do not allow variables starting with an underscores to be converted to property.Variables with leading underscore can storePropclass objects without getting converted to property.Other access obsessionsWe have several classes to allow different level of obsessions over attribute access, for example:Should the attribute be changeable through class or class instance or both?Should the attribute be deletable through class or class instance or both?Should the attributes be allowed to be accessed as items (e.gobj['name']instead ofobj.name)?You can check out these classes athttps://docs.neurobin.org/ocd/latest/unro.htmlOther obsessionsDeprecate in futureSo, you want to deprecate a function or method from version 2.0 and remove it in 3.0 and the current version is 1.0! No problem, you can obsess on your deprecation plan too:fromocd.deprecateimportdeprecate# If you do not specify the versions, it will be deprecated immediately@deprecate(by='method2',ver_cur=package.__version__,ver_dep='2.0',ver_eol='3.0')defmethod1(self):returnself.method2()When the version reaches 2.0, you will get a warning like this:DeprecatedWarning: `<function method1 at 0x7faf2c362c10>` is deprecated by `method2` from version `2.0` and will be removed in version `3.0`. Current version: `1.0`.and when the version reaches 3.0, you will get a warning like this:UnsupportedWarning: `<function method1 at 0x7faf2c362c10>` was deprecated by `method2` from version `2.0` and planned to be removed in version `3.0`. Current version: `3.0`.The unsupported warning is not that helpful, but you can raise this warning into error in your test suite and force yourself or your team to remove this deprecated method in the planned version. For that, you can use theraiseUnsupportedWarningdecorator:fromocd.deprecateimportraiseUnsupportedWarning@raiseUnsupportedWarningdeftest_method1(self):# your test codepassYou can find the detailed documentation athttps://docs.neurobin.org/ocd/latest/.Installpipinstallocd