Are routine objects guaranteed mutable & with dictionary?

[Alf P. Steinbach]

* MRAB:
> Alf P. Steinbach wrote:
>  > * Dennis Lee Bieber:
>  >> On Sat, 05 Dec 2009 11:26:34 +0100, "Alf P. Steinbach"
>  >> <alfps at start.no> declaimed the following in
>  >> gmane.comp.python.general:
>  >>
>  >>> The devolution of terminology has been so severe that now even the
>  >>> Wikipedia article on this subject confounds the general concept of
>  >>> "routine" with the far more specialized term "sub-routine", which
>  >>> is just one kind of routine. It is of
>  >>
>  >>     Well, if this were a FORTRAN IV text from the mid-70s you'd be
>  >> talking about
>  >>
>  >>         function subprograms
>  >> and
>  >>         subroutine subprograms
>  >
>  > It's in that direction yes, but the distinction that you mention,
>  > which is essentially the same as Pascal 'function' versus
>  > 'procedure', or Visual Basic 'function' versus 'sub', is just a
>  > distinction of two variants of subroutines.
>  >
>  > Up above there is the more general concept of a routine, where there
>  > are more possibilites than just subroutines; Python generators are
>  > one example.
>  >
>  > As I mentioned earlier, in Eiffel, which is a more modern language
>  > than Fortran, routines are still called routines. And specialized
>  > terms include "routine". So it's not like that language independent
>  > terminology has been phased out in general; it's mostly only in the C
>  > syntax family (e.g. Python operators come mostly from C) that
>  > "function" is, misleadingly and with associated severe constraints,
>  > used as a general term.
>  >
> In C there were originally only functions; if you didn't specify a
> return type then it would default to 'int' ('void' was a later
> addition).
> 
> In Python there are only functions; if you don't explicitly return a
> value then None is returned.
> 
> The distinction between functions and procedures can be helpful in
> deciding whether something is Pythonic (for example, in the use of list
> comprehensions), but in reality they are all still functions.

I'm sorry, but, first, looking at ways to emulate a syntax, thinking about 
whether something looks like mathematical functions, the eye-candy, is pretty 
irrelevant, at least IMO. To see that it is irrelevant you might consider how 
that works in assembly language. Or you might consider that a call of a C++ 
'void' routine can be used in C++ expressions. I think that even by your mainly 
visual syntax criterion that must be difficult to think of as a "function". 
Another way of looking at it is that the information conveyed by a result 
restricted to N=1 possible significant values, such as Python None or C 
arbitrary value (all possible return values of a non-result-producing routine to 
be treated as the same), is log(N)/log(2) = log(1)/whatever = 0, i.e., the 
routine then produces zero information via its expression result.

Second, what's discussed isn't the distinction between various kinds of 
subroutines, so that wrt. to the earlier thread it's at best a detail.

Although I think that the distinction that you and Dennis raise *is* a useful 
discussion! :-)


Cheers & hth.,

- Alf