[Edu-sig] python versus __python__

[Kirby Urner]

Going into my new presentation manager materials (perhaps using the same
Pygame engine I used at OSCON, but as a general purpose module, i.e. not
tied up in that specific content) is the distinction between two kinds of
Python:  Python and __Python__.  

You really get to a new level with Python when you start using its
underunder.  And that occurs, for many, right when they define a first class
(or user type):  in the form of __init__.  __new__ comes even later (a
paradox).

Another fissure defining beginner and advanced:  operator overloading.
That's how it was in C++ books:  we'll get to that later.  Considered an
advanced feature, not even featured in the original Java from Sun.

So a logical course progression might involve doing a lot of non-underunder
stuff at first, exploring but without much introspecting.  Because as soon
as you introspect, ala dir(1), you're into underunder land, and that takes
advanced thinking to negotiate.[1]

Now, just saying there're these two levels isn't to say we can't be up front
about their being there.  I'll tell a class we're tackling Python in two
goes, saving __python__ for Part 2.  I look at Wittgenstein's PI the same
way.  Part 2 is more subtle, and you get more power.  You get to redefine
what you mean by + and *.  Wow.  Snake charmers enter here.

Now there's another way Python gets advanced, which is less about getting
more deeply into Python, and more about getting more deeply into something
else, *using* Python.  That's like when we import a module giving us a wrap
of some external game engine, wherein to construct simulations and so on ala
that project to teach Arabic to soldiers at West Point -- a demo at Pycon
2005 in DC.

So you have different ways of advancing in Python:  into the language more
deeply, to mastery of underunder, metaclasses and beyond; and into foreign
territory, but with Python as your guidebook and phrase book, giving you
confidence amidst all these alien-seeming APIs.  

I suppose poking around under the hood, looking at the C or whatever's
puppeting the Python interpreter, is yet a third direction in which to
advance.  You'll see how underunder is implemented under the hood.  But it
won't be in Python per se, but in Python byte code on a VM (Python-the-agile
skins many a system language -- including in cell phones).

Kirby

[1]

IDLE 1.1      
>>> dir(1)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
'__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
'__floordiv__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__',
'__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__',
'__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__',
'__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__',
'__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__',
'__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__',
'__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__',
'__truediv__', '__xor__']