[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