PyWart: Packages (oh how thou art lacking!)

Rick Johnson rantingrickjohnson at gmail.com
Mon Nov 11 04:19:44 CET 2013


============================================================
 The Pros of Python Packages:
============================================================

  Python packages require no special syntax to declare which
  modules are members of the package. Instead, Python simply
  allows the programmer to utilize the hierarchy of his file
  system to decide *which* modules are in *which* packages.

  Sure you've got to create a "__init__.py" file under the
  directory which will become the package, which is just one
  operation to preform, as opposed to writing "uses package
  blah" in every damn source file!

  But the real genius is in the consistency!

  By utilizing such a novel approach to packaging, the
  implementation of Python packages remains consistent with
  Python modules. Let's face it people, packaging by any
  other means is just re-inventing the wheel!

============================================================
 The Cons of Python Packages:
============================================================

  1. No ability to EASILY share state between package
  members. Sure you can import and inject symbols until
  you're fingers bleed, but all you've done is create an
  unmaintainable spaghetti mess!

  2. Attempting to use packages to create a hierarchy of
  library modules is even more difficult and opens a
  Pandora's box of confusion, circular imports, name errors,
  unintended side effects, etc, etc...

============================================================
 What should a package be anyway?
============================================================

  Whilst python packages can be useful, their design is so
  woefully inadequate as to render them almost useless. To
  describe the disparities using an example:

    Imagine if classes were nothing more than an
    encapsulation of N functions that share information via
    a global variable "self" -- no inheritance, no
    polymorphism, no overloading, no blah blah blah...

  Sure, i could find a use for such a type, but the usage
  would be painfully limited.

  So now we find ourselves faced with the reality of the
  glaring question --> What the hell should a python package
  be exactly?

  A package SHOULD be an extrapolation of the namespace
  methodology, in the purest form. You start with local
  scope, then you proceed to module level scope, then
  package level scope (well, that's my wish anyway!), and
  finally, global scope[*]

  Just as class members can share information easily via
  "self", package members should have this ability also.

============================================================
 Some food for thought...
============================================================

  "Namespaces are one honking great idea -- let's do more of
  those!"

------------------------------------------------------------
 REFERENCES:
------------------------------------------------------------
  [*] Even though Python does not "officially" support
  global variables, you can emulate such functionality by
  injecting objects into __builtins__, since __builtins__ is
  available in every module namespace.



More information about the Python-list mailing list