Python Software Development Environment

Introduction - Some perspective issues

• Fundamental object organization
  • New dir() builtin, gives a more comprehensive perspective on object attributes
  • New docstrings
  • __doc__ slots in many compound objects to take brief descriptive strings
  • Callables def. syntax for callables and modules auto assigns first statement in code for an object, if it's a string
  • Only started to form docstring format conventions
  • see Python 1.2 'newimp.py' for an example
  • Docstrings
    • Use them!
    • Create docstrings for existing stuff (e.g. sys modules)
    • Identify docstring format conventions
    • Integrate docstrings into existing tools (e.g. pdb, dir)
    • Identify other object self-describing attributes
• module organization - import module packages
  • New import - nesting module packages
    • implements module name partitioning in heirarchical namespace
    • to software packages can have module components with the same name (e.g. email.mbox vs. news.inbox)
    • modules within a s/w package can load each other via relative '__' package-container shorthand
    • All local name references partitioned within the Python modules namespaces, in contrast to Java mechanism
    • In Python, import P.main and import Q.main do not conflict In Java they do.
    • backwards compatible
  • Further ideas for import
    • structure the import implementation so the search and load
    • mechanisms are table-driven, so people can hook in their
    • own origin and load mechanism. (e.g for URL's)
• runtime environment - dubuggers, profilers, env browsers
  • How about emacs? A lot of tools could be implemented in emacs-19 and get a substantial, highly integrated programming environment
  • code editing
  • tags
  • GUD debugger
  • environment browser
• programming style
  • Var Names
  • disciplines (aka 'magic methods') __init__
  • exposed internal routines, names...: _underscore
  • constants: UPPERCASE
  • classes: Capitolized
  • global names: not_abreaviated
  • boolean vars: long_informative_names
  • name groupes lacking name space: common short prefix + '_' : sys.exc_type, sys.exc_value
  • avoid using globals
  • modules with mostly just one class, named after the class
  • put all imports near the top
  • use doc string, including module doc, and version
  • use a version string, but only whn you use it with discipline
• documentation formats and efforts
  • In addition to the micro-scale docstrings, we need mode documentation of existing pythion stuff, and promotion and some system to create documentation in general
  • What doc format should we support
    • HTML means pretty-looking for web browsers
    • Texinfo is more immediately searchable, but not web
    • ILU's TIM (similar to texinfo) is another possibility...
      • TIM looks very nice technically since it has the highest level abstractions for documentation :-) Guido and Bill Janssen are going to look into this
    • A list on python.org will be started to further discuss
  • Do we need, and can we muster a documentation project like Linux? -- Yes, but no one volunteered to start it.
• code versioning
• I18N
  • Guido envisions a possible new data type to support UNICODE
• Deeper Python Programming Envirnonment items
  • extension/embedding frameworks
  • persistence
  • runtime
  • GUI builders