Joe Marshall <[EMAIL PROTECTED]> wrote: ... > If you language allows unnamed integers, unnamed strings, unnamed > characters, unnamed arrays or aggregates, unnamed floats, unnamed > expressions, unnamed statements, unnamed argument lists, etc. why > *require* a name for trivial functions?
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). This doesn't stop a programmer from using a meaningless name, of course, but it does nudge things in the right direction. > Wouldn't all the other constructs benefit by having a required name as > well? I believe this is a delicate style call, but I agree with your implication that a language should at least _allow_ any object to have a name (even when such objects are more often constructed on the fly, they could still usefully borrow the first [or, maybe, the latest] name they're bound to, if any). If I was designing a language from scratch, I'd probably have as the first few fields of any object _at least_...: a cell pointing to the type object, a utility cell for GC (reference count or generation-count + markflag) a cell pointing to the name object, ...rest of the object's value/state to follow... 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). As to what good practices should be more or less mandated by the language, and what other good practices instead should be just gently nudged towards, that's an interesting design question in each case; to me, a cornerstone for answering it is generally _language simplicity_. When mandating a certain good practice DETRACTS from language simplicity, make it a matter of convention instead; when so mandating ENHANCES language simplicity (by not needing the addition of some other construct, otherwise unneeded in the language), go for the mandate. 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? This DOES imply that some (functions, modules, etc) that are fundamental to the language (and needed to build others) should be provided with a name, but then one tends to do that anyway: what language *DOESN'T* provide (perhaps in some suitable "trigonometry" module) elementary functions named (e.g.) sin, cos, tan, ..., to let the user build richer ones on top of those? Alex -- http://mail.python.org/mailman/listinfo/python-list