[Jargon] Python glossary - contribute your definitions
Mike C. Fletcher
mcfletch at rogers.com
Sat Sep 6 22:54:44 CEST 2003
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:
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
* 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
o "blessed into the standard library" is occasionally used to
describe Guido's acceptence of a module for inclusion in the
* 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
* 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
* New users in particular, feel free to pipe up with a word you'd
* Prefix all subject-lines with [Jargon]
might make the process go a little more smoothly too.
Just my 2c,
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list