This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?

Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...

Logged In: YES 
user_id=6656

> Should we require that the new function name is a valid
> identifier?

We could, but I don't really see it being worth the effort
(no attempt is made to ensure that a type's __name__ is a
valid identifier today).

> If not, is an empty string an acceptable function name?

Don't see why not.

> Also, are string subtypes allowed?

Again, don't see why not.

> There should be \versionchanged in the documentation.

Yes.  In fact the documentation of function attributes could
do with being rewritten entirely....

I'll note that all the possibilities you mention are
possiblities today, via new.function.  I'm really not
changing very much.

Agree with Anthony that we don't want to allow unicode.

(While we're at it, I see that func_repr takes into account
that func_name might be Py_None, but I don't think this is
actually possible.  Any ideas?).

Logged In: YES 
user_id=21627

These decisions are all fine with me.

As for anonymous functions: It appears that compile.c
2.36/funcobject.c 2.7 introduce the notion of anonymous code
objects (30-Nov-93). compile.c 2.48 (18-Jul-95) takes this
option out again, along with introducing keyword arguments.
So it is probably safe to drop the support for anonymous
functions.

Logged In: YES 
user_id=6656

OK, take 2.  More documentation, removes the "if (func_name == 
Py_None)" case in func_repr.

Logged In: YES 
user_id=21627

I notice an inconsistency in the documentation: all
attribute explanations start with a noun explaining the
thing; func_dict starts with "Contains". I'd still like to
see a \versionchanged indicating that the name is only
writable since 2.4.

Apart from that, the patch looks fine.

Logged In: YES 
user_id=6656

Thanks for the review; I've accomodated both your points.

Checked in as:

Doc/lib/libstdtypes.tex revision 1.163
Doc/ref/ref3.tex revision 1.121
Lib/test/test_funcattrs.py revision 1.14
Objects/funcobject.c revision 2.66
Misc/NEWS revision 1.1083