| msg46564 - (view) |
Author: Michael Hudson (mwh)  |
Date: 2004-08-06 16:06 |
| 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. |
|
|
| msg46565 - (view) |
Author: Skip Montanaro (skip.montanaro) *  |
Date: 2004-08-06 18:18 |
| 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)? |
|
|
| msg46566 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-08-06 20:44 |
| 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. |
|
|
| msg46567 - (view) |
Author: Anthony Baxter (anthonybaxter) |
Date: 2004-08-07 10:49 |
| 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, ... |
|
|
| msg46568 - (view) |
Author: Michael Hudson (mwh) |
Date: 2004-08-07 13:10 |
| 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?). |
|
|
| msg46569 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-08-07 13:43 |
| 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. |
|
|
| msg46570 - (view) |
Author: Michael Hudson (mwh) |
Date: 2004-08-07 16:57 |
| Logged In: YES user_id=6656 OK, take 2. More documentation, removes the "if (func_name == Py_None)" case in func_repr. |
|
|
| msg46571 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-08-12 14:47 |
| 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. |
|
|
| msg46572 - (view) |
Author: Michael Hudson (mwh) |
Date: 2004-08-12 18:14 |
| 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 |
|
|