Vladimir Marangozov wrote: > Gordon McMillan wrote: > > > > I don't see anything here but an argument that allowing > > attributes on function objects makes them vaguely similar to > > instance objects. To the extent that I can agree with that, I fail > > to see any harm in it. > > > > To the extent it encourages confusion, I think it sucks. > > >>> def this(): > ... sucks = "no" > ... > >>> this.sucks = "yes" > >>> > >>> print this.sucks > 'yes' > > Why on earth 'sucks' is not the object defined in the function's namespace? Because that one is a local. Python allows the same name in different places. Used wisely, it's a handy feature of namespaces. > Who made that deliberate decision? What decision? To put a name "sucks" both in the function's locals and as a function attribute? To print something accessed with object.attribute notation in the obvious manner? Deciding not to cause gratuitous UnboundLocalErrors? This is nowhere near as confusing as, say, putting a module named X in a package named X and then saying "from X import *", (hi, Marc-Andre!). > Clearly 'this' defines a new namespace, > so it'll be also legitimate to get a NameError, or to: > > >>> print this.sucks > 'no' > > Don't you think? Only if you've done "this.sucks = 'no'". Or are you saying that if functions have attributes, people will all of a sudden expect that function locals will have initialized and maintained state? We certainly get plenty of newbie confusion about namespaces, assignment and scoping; maybe I've seen one or two where people thought function.local should be legal (do Python-tutors see this?). In those cases, is it the existence of function.__doc__ that causes the confusion? If yes, and this is a serious problem, then you should be arguing for the removal of __doc__. If not, why would allowing adding more attributes exacerbate the problem? > And don't explain to me that this is because there's a code object, > different from the function object, which is compiled at the function's > definition, then assotiated with the function object, blah, blah, blah... No problem. [Actually, the best argument against this I can see is that functional-types already try to use function objects where any sane person knows you should use an instance; and since this doesn't further their agenda, the bastard's will just scream louder <wink>]. - Gordon
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4