[Jargon] Python glossary - contribute your definitions

[Mike C. Fletcher]

Skip Montanaro wrote:
...

>I'm still interested in getting this off the ground, though.  To make it
>more likely that something significant gets done, I created a Wiki to which
>people can add definitions:
>
>    http://manatee.mojam.com/python-glossary
>  
>
...


Seems like something that could be hashed out faster and more reasonably 
as a thread on comp.lang.python where people propose, then vote on words 
(and/or definitions) suitable for a glossary.  For example:

    * bot -- mythical or near-mythical creatures which appear as people
      on the comp.lang.python newsgroup, yet seem to operate at an
      impossible level of knowledge, accuracy and verbosity, often in
      regard to obscure and fascinatingly off-topic ideas.  Common
      examples, Tim-bot, Martelli-bot, F-bot.  Note that, for instance,
      Guido is seldom (if ever) described as a bot, whether because his
      posts tend to remain relatively short and on-topic, or because of
      his relatively succlusion within python-dev.
    * PSU -- Python Secret Underground, apparently mythical covert group
      ultimately responsible for the destiny of Python.  According to
      the myths, tends to cut of posters mid-post (making them disappear
      via a band of thugs travelling around in white vans IIRC).  Tends
      to be the target of most "conspiracy theory" posts, as it tends to
      allow for distancing criticism with humour.
    * superclass -- (1) the ancestor of a class within the inheritance
      hierarchy, a class which is one of the base-classes of a given
      class.  (2) In a more limited sense, the class directly above the
      given class in the inheritence hierarchy, this definition comes
      into play more with Python 2.2's method-resolution-order.  As
      distinct from a meta-class (implementation of the class).
    * dictionary, dict -- (1) a key to value mapping (2) a built-in
      type, currently implemented using a highly optimised hash-table
      implementation
    * generator -- a function or method which produces an interable
      stream of values by temporarily suspending operations when an item
      is discovered and resuming them only when the next value is
      returned. Requires that the method not "return" a value, instead
      the method should "yield" values as they are available. 
      Generators allow for calculating results on an as-needed basis.
    * list comprehension -- declarative syntax for initialising new list
      objects, based on functional-language constructs.  Each list
      comprehension can be expanded into an equivalent (series of)
      for-loops and if statements.
    * mro -- method resolution order, the ordering of classes in which
      Python (2.2 and beyond) attempt to resolve instance-attribute
      lookup in a class hierarchy.
    * python-dev -- (1) the mailing list on which the core Python
      development team discusses and organises Python's future
      development (2) the core Python development team itself.
    * standard library -- collection of code distributed with the core
      Python interpreter and generally assumed to be available in most
      environments
          o "blessed into the standard library" is occasionally used to
            describe Guido's acceptence of a module for inclusion in the
            standard library
    * Python-Labs --
    * PBF --
    * PSF --
    * distutils -- (arguably this is just a module, but it's a critical
      module that people hear about w/out context quite often)
    * namespace -- (focus on Python semantics)

Some of those are obviously too spartan to really help a new user, some 
are possibly not appropriate, some may be considered too basic to be 
included, some may be dead wrong.  Having the general populous review 
and suggest improvements interactively would seem to be as useful an 
editing mechanism as any IMO, and would also allow new users to follow 
along in "word a day" style :) .

Setting out a few ground-rules:

    * Cover humour, don't make it (i.e. the PSU mythos has had dozens of
      posts along the years, creating entirely new myths doesn't help,
      people want to know what's being talked about, not "how clever we
      can be")
    * Use neutral terminology as much as possible, imagine you were
      writing for the Jargon file, not a usenet post
    * Provide enough information that a google search will lead the
      interested to the information they need, exhaustive
      (encyclopeadic) entries aren't the goal of a glossary.
    * Skip has final say in resolving any Jargon issues, as the
      python-dev person in charge of the glossary check-in, we're all
      just suggesting things to him, in the end.
    * Focus on terms which are used (commonly) within the Python
      community, but are not generally used by tech folks.  Some
      duplication of Jargon-file elements may be required to cover
      Python-specific sub-specialisations, or to cover very common
      Python idioms, but the Jargon file already covers a lot of tech
      jargon.
    * New users in particular, feel free to pipe up with a word you'd
      like defined.
    * Prefix all subject-lines with [Jargon]

might make the process go a little more smoothly too.

Just my 2c,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/