[Jacob Solinsky] > these local variables are used quite often in the mutate methods, of which > there are several dozen, so storing them by default saves a lot of typing.
There are several things you can do to alleviate the typing problem: 1) Get an IDE that has auto-complete. I recommend PyCharm Community Edition, but there are several. 2) Use better naming: there are many shorter synonyms for "preceding" and "succeding" and the word "morpheme" is redundant. 3) define as much as you can in the higher scopes: C = re.compile("^[bpgkdtszSZjCmnywh]").match M = re.compile("^[mn]$").match class Morpheme: @property def pf(self): return self.pre.form @property def sf(self): return self.suc.form @property def precm(self): return C(self.pf) @property def sucmm(self): return M(self.sf) ... I think what would help most of all is reorganizing your code. As I understand it, a morpheme is the "smallest grammatical unit in a language" <https://en.wikipedia.org/wiki/Morpheme> so maybe it makes more sense to make the morpheme class fairly simple and not have a morpheme have any inherent awareness of its preceding or succeeding morphemes. That seems like the job of a larger construct that would deal with sequences of morphemes. The way you have it right now, the morpheme seems to play a double role a linked-list and a gramatical unit. [Jacob Solinsky] > I found cluttering the Morpheme object instances with flags and such to be > inelegant, since these flags are only used by the mutate method. > That may be an indicator that you're trying to do too much with the morpheme class. [Jacob Solinsky] > Also, without using a hacky solution like making Morpheme a subclass of > types.SimpleNamespace, every new flag I might want to inject has to have a > default value set in the __init__ method to prevent an AttributeError from > being raised. Yes, you typically want to define all your object attributes in __init__ otherwise your objects become fragile and can break if you don't call the right methods in the right order. It's generally considered a bad idea to define instance attributes anywhere else unless it's something like a "private" helper method that gets called inside __init__. [Jacob Solinsky] > Anyways, I will look around in the mail list for discussions of Code > blocks, now that I know they are called. Don't take this the wrong way, but it might be better to acquaint yourself with the set of tools already available before looking for new ones.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/