. Python 2.1 function attributes

Roy Katz katz at Glue.umd.edu
Sat Jan 27 09:38:20 EST 2001


On Sat, 27 Jan 2001, Tim Peters wrote:

> Because the technique you suggest has been available for a decade, yet in
> practice people refused to use it, preferring instead to abuse docstrings.
> Have you read the PEP?  "Practicality beats purity" in Python:  an elegant
> solution that masses of experienced Pythoneers refuse to use is an excellent
> predictor of future language change.  And, for example, metaclasses are in
> that boat too.

I considered your argument and have come to agree with you. 
I wanted to organize for myself the separations between functions and
classes. Let's see if we can generalize them, perhaps use their
differences to some advantage. 
Is it possible, then, to organize these as subtypes of some
Entity? This 'Entity' allows for attributes to be attached under its
namespace.  Integers aren't entities.  len() is not an
entity.  User-defined functions and classes -are- entities. 
As subtypes,  Functions and Classes offer these additional
functionalities:


Functions:
  - don't need to be instantiated to be executed
  - very much a singleton 

Classes:
  - always pass self to methods
  - clonable through multiple instantiation

Both:
  - take parameters (functions by their nature; classes through __init__)
  - can accomplish the same thing
  - can be used as data structures

Note that last point:  Is it that people have been clamoring for singleton
support under Python?  A question to consider:   suppose we add class
methods to Python.  Then, the singleton feature of a function's data set
can be mimiced by classes with static methods.  I'm not sure what my point
is, but I'm interested nonetheless. Perhaps adding attributes to functions
takes us one step closer to adding true class methods. 


> Barry also added code to Python 2.1 to let you write, e.g.,
> 
>     def f() >> x:
>         x = 1
>         y = 2
> 
> as a short way to spell "whatever the value of x is at the end of the
> function, return that".  I'm sure you'll agree that's much cleaner than the
> clumsy

I like it, but why the choice of >> over return? 


Roey




More information about the Python-list mailing list