Draft Pep

[Huaiyu Zhu]

Lulu of the Lotus-Eaters <mertz at gnosis.cx> wrote:
>huaiyu at gauss.almadan.ibm.com (Huaiyu Zhu) wrote previously:
>|def func1 ...
>|def func3 ...
>|def func4 ...
>|callbacks = {
>|   "case a": func1,
>|   "case b": lambda ...
>|   "case c": func3,
>|   "case d": func4,
>|   "case e": lambda ...
>|}
>|Pulling functions out of data structures not only pollutes module name
>|spaces with unwanted names, but also splits semantically connected material
>|to separate locations in the code.
>
>Sure.  But this problem can be 90% mitigated by using a function-level
>scope, IMO:
>
>    def mk_callbacks(dct={}):
>        def func1: ...
>        dct["case a"] = func1
>        dct["case b"] = lambda ...
>        def func3: ...
>        dct["case c"] = func3
>        def func4: ...
>        dct["case d"] = func4
>        dct["case e"] = lambda ...
>        return dct

This and several other replies assume that the dictionary is the only thing
in the data structure.  But that's only an example.  A more realistic
example would be something like

big_struct = {
  'title': ...
  'situation 1': {
      'case a': def ...
      'case b': None
      ...
      }
  'situation 2': [
     def ...
     def ...
     'text'
	 { 'a':1, 'b':2, ... }
     ...
   ]

Defining named functions splits the functionality to other parts of the
program.  If there are many such functions, their names have to be as
verbose as big_struct_situation_1_case_a_func to be really meaningful.  On
the other hand, being positioned at the right place in the structure is a
much better reminder of their role than any posible names.


Huaiyu