I agree, Tim. Clearly, my 'Obfuscated Python' subject line was meant
tongue in cheek - as in, "this is about as obfuscated as I can get
in python". Well - not quite, since you managed to top me with:
[ from an earlier email message: ]
>
> while exec('x=stdin.readline()') or (x and (stdout.write(process(x)) or x)):
> pass
>
> is clearly the _correct_ way to do it <grin>.
>
> I've seen Python criticized as "ugly" precisely because it _doesn't_ have
> a trick-based view of the world. In many ways, it's a dull language,
> borrowing solid old concepts from many other languages & styles: boring
> syntax, unsurprising semantics, few automatic coercions, etc etc. But
> that's one of the things I like about it.
>
> The trickiest areas in my experience have to do with namespace
> management, both the cool way classes introduce dynamic new namespaces,
> and the way assignment in general merely binds a name to an object. You
> can do some very powerful things after grasping these, but they're
> already illustrated well in the distributed Python samples.
Well - sometimes there are "suprising semantics" introduced by the
namespace management.(*) So if we TRULY want to write some obfuscated
python, it should clearly do something subtle with the name space,
or tricky 'eval' or 'compiles' of generated strings, or Classes that
define non-intuitive meanings for '+' or '[i]' . So, yes, you CAN
write _REALLY_ obfuscated python, but you have to go quite out of
your way to make the effort. ( As opposed to 'C', where you have to
go quite out of your way to un-obfuscate it! )
[ (*) Recall the confusion I had long ago with module global names -
it has since been "fixed" with 'global' and a couple of other
changes, but it was, I recall a very subtle and interesting side
effect of the python namespace. ]
>
> even-obfuscated-python's-darned-easy-to-read-ly y'rs - tim
>
But I wouldn't describe python as "dull" !
One of the things that makes it interesting, is exactly how
much Guido has managed to exploit that *one* implementation trick
of 'namespaces'. Python is built around the concept of
namespace - just as arrays are at the core of APL and lists/S-expr's
are the secret of the power of LISP. And as a result, I think it
makes it a quite comprehensible language. I don't often have time
to read thru the python sources, but I still feel I have a sort-of-basic
understanding of how things work "under-the-hood" .
FORTH and LISP both have a very simple, comprehensible core language
upon which a much more elaborate system is constructed. FORTH is
built around threaded-code and dictionaries ( which, unsuprisingly,
can be made to do some similar things as python's namespaces - there
are FORTH words which change the dictionary search order, and thus
the context for evaluation of following words. ) Lisp is built upon
lists and the read-eval-print of S-expressions.
Python is a bit more complicated, but much of that complication is
just (as they say) "surface syntax". In python - everything is an
object, and a name is turned into an object via dictionary lookup
in the namespace of the current context. Modules and classes both
create new namespaces, and reference to a module or a class instance
changes the evaluation context.
This simplicity counts for a lot when you DO need to extend or
embed the interpreter. We have seen a number of posts to this
list about 'I changed python to do this...' ( the most recent
being Lance's addition of line number error tracing to 'compile()' )
The idea of adding a new data type to python doesn't scare me.
( The only thing I thought I might actually need was arrays,
to make more effecient passing to and from a C program that
would have an embedded python interpreter - but someone else
has already done that - Thanks guys! )
Some of this is due to the level of documentation that Guido
has supplied, but a lot of it is due to starting with a clean
design and a simple concept.
I have never looked "under-the-hood" at perl in nearly as much
detail - the surface frightened me off!
-Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
-Univ. of Virginia Department of Molecular Physiology and Biological Physics