[Python-ideas] Jump to function as an an alternative to call function
Abe Dillon
abedillon at gmail.com
Wed Aug 15 21:36:25 EDT 2018
[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180815/b7ffc391/attachment.html>
More information about the Python-ideas
mailing list