. Python 2.1 function attributes

[Roy Katz]

I find this explanation in need of more clarification:


You did not address the issue of multiplying entities.  I personally
see nothing wrong with function objects; they are light, and we can deal
with them.  Why add yet *another* way of doing things? 


# note: compared with f(), this implementation is an extra line 

class G:
    attr = 0
    def __call__(self): pass

g = G() long

---VERSUS---

def f():
  { 'attr':0 }
  pass


So the claim here is that saving a line of code justifies carving Python
with Occam's Razor? Say it ain't so!   

I find the argument for function attributes weak.  Hell, I wish to abolish
.__doc__ for functions as well.  It just doesn't seem
consistent.  Functions are functions, classes are classes.  It seems to me
even kludgier than print>>. 



Roey



On Sat, 27 Jan 2001, Tim Peters wrote:

> Akin to the same point as for letting people write
> 
>     x + 2
> 
> when they could be restricted to writing
> 
>     x + 1 + 1
> 
> That is, convenience, clarity, efficiency and naturalness.  As PEP 228 says,
> people *have* been abusing docstrings for all sorts of things, despite that
> they're well aware of class-base techniques.  If I want to associate data
> (other than a docstring, which is easy) with a function or method, first
> burying the function in an artificial singleton class and then using an
> instance of that class instead is simply convoluted in comparison.
> 
> 
>