Alex Martelli wrote: > > I think it's reasonable to make a name a part of functions, classes and > modules because they may often be involved in tracebacks (in case of > uncaught errors): to me, it makes sense to let an error-diagnosing > tracebacks display packages, modules, classes and functions/methods > involved in the chain of calls leading to the point of error _by name_. > > I think it's reasonable to make a name a part of types for a different > reason: new types are rarely meant to be used "just once"; but also, if > during debugging any object is displayed, it's nice to be able to show, > as part of the display, "this object is of type X and ...", with X shown > as a name rather than as a complete (thus lengthy) description. (any > decent interactive shell/debugger will let you drill down into the > details as and when you need to, of course, but a well-chosen name can > be often sufficient during such interactive exploration/debugging > sessions, and therefore save time and effort).
I agree that symbolic debugging info is a good thing. > Indeed, "given an object, how do I get its NAME" (for inspection and > debugging purposes) is the most frequently asked question on > comp.lang.python, and I've grown a bit tired of answering "you can't, an > object in general intrinsically ``has no name'', it might have many or > none at all, blah blah" -- yeah, this is technically true (in today's > Python), but there's no real reason why it should stay that way forever > (IMHO). If we at least ALLOWED named objects everywhere, this would > further promote the use of names as against mysterious "magic numbers", > since the programmer would KNOW that after > VAT_MULTIPLIER = 1.19 > then displaying in a debugger or other interactive session that > PARTICULAR instance of the value 1.19 would show the name string > 'VAT_MULTIPLIER' as well (or no doubt a more structured name constructed > on the fly, identifying package and module-within-package too). The problem is that a `name' is a mapping from a symbolic identifier to an object and that this mapping must either be global (with the attendant name collision issues) or within a context (with the attendant question of `in which context'). > Mandating names for _everything_ would complicate the language by > forcing it to provide builtin names for a lot of elementary building > blocks: so for most types of objects it's best to "gently nudge". For > functions, classes, modules, and packages, I think the naming is > important enough (as explained above) to warrant a syntax including the > name; better, therefore, not to complicate the language by providing > another different syntax in each case just to allow the name to be > omitted -- why encourage a pratice that's best discouraged, at the price > of language simplicity? I agree. This is why I write (defun foo (x) ...) rather than (setf (symbol-function 'foo) (lambda (x) ...)) However, there are places where names are cumbersome. They are certainly cumbersome for most literal objects like numbers and strings. There are circumstances where they are cumbersome for function objects. The function (lambda (x) (+ x 3)) doesn't really need a name. It isn't any big deal if you give it a name, but it's a trivial annoyance to be forced to give it a name. It becomes a major annoyance when you write code in continuation-passing-style or monadic style. It is an annoyance when refactoring code, too. Suppose you had written (mapcar #'sin list-of-numbers) and you realize that the numbers are in degrees. With an unnamed function, this is an easy fix: (mapcar (lambda (x) (sin (deg->rad x))) list-of-numbers) With a named function, you have to do one of these: (flet ((sin-d (x) (sin (deg->rad x)))) (mapcar #'sin-d list-of-numbers)) or (mapcar (flet ((sin-d (x) (sin (deg->rad x)))) #'sin-d) list-of-numbers) Matthias Felleisen once suggested that *every* internal function should be named. I just said `continuations'. He immediately amended his statement with `except those'. -- http://mail.python.org/mailman/listinfo/python-list
