Python from Wise Guy's Viewpoint
Ingvar Mattsson
ingvar at cathouse.bofh.se
Mon Oct 20 11:19:14 EDT 2003
More information about the Python-list mailing list
Mon Oct 20 11:19:14 EDT 2003
- Previous message (by thread): Python from Wise Guy's Viewpoint
- Next message (by thread): Python from Wise Guy's Viewpoint
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ Follow-up redirected to comp.lang.lisp ] Joachim Durchholz <joachim.durchholz at web.de> writes: > james anderson wrote: > > > Joachim Durchholz wrote: [SNIP] > >>I'd really like to see a Lisp dialect that valued reliability over raw > >>expressive power. But I fear this isn't very high on the agenda of the > >>Lisp community. Besides, it would be difficult to do that - Lisp offers > >>no protection against peeking at internals and setting up all that > >>unsafe-but-powerful stuff. > > what are "internals", what is "protection"? > > No way to define an opaque type. AFAIK, modern Lisps allow > user-defined types, but they offer no way to protect them against > inspecting their internals. I'd prefer to have at least a grain of > information hiding... Well... Using INSPECT one can "look inside" a type, but one has almost the same (possibly the same) amount of introspection in (say) Python, using dir() (and very handy it is, not as good as reading documentation, but for those "I need to check this now" moments, it can often be sufficient). One should, as usual, follow one's introspective moments by checking The Reference(s), to see if what one saw, introspecting, is "supported" or "unsupported" (if the latter, one can bet things will break in interesting ways, either "soon" or "on next upgarde"). But, at times, that can be the only way to use a third-party module taht *almost* fits one's needs. I saw a horror-story of someone having to retro-fit third-part C++ modules by clever run-time mangling of things, to get it to work Right, instead of "it does almost what the documentation says, but not quite and fixing it is faster than getting a patch or rolling it ourselves". I think it was in a thread in comp.lang.lisp, a few years back, regarding why it was a *bad* thing forbidding access to non-exported sympols from a package. Not exporting something is a good sign taht one shouldn't touch it and well-behaved programmers won't. They *may* file a bug saying "this would be handy if it was supported", but they should, in general, not go ahead and use it. //Ingvar -- Coffee: Nectar of gods / Aesir-mead of sysadmins / Elixir of life
- Previous message (by thread): Python from Wise Guy's Viewpoint
- Next message (by thread): Python from Wise Guy's Viewpoint
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list