python versus __python__

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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__']



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: python versus __python__

Arthur-27
Kirby Urner wrote:

>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__.  
>  
>
The ego and the id of it...

is how I sometimes think of it.

>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).
>  
>
Just posted to python-list on this, having found that subclassing
numeric types is done at the __new__ level, not the __init__ level.

I see __init__ as everyday waking consciousness, and __new__ inhabiting
the netherworld.  But making the subconscious conscious leads to good
mental health. Of which I am th strongest of advocates. And I am trying
to dredge up __new__ to the conscious level.

>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.
>  
>
This is something I felt comfortable exploring very early on - to the
extent of having overused it.  I would hate to see you back-end that, as
I think it is kind of fun to play with.  "let's change the boring old
rules of math..." kind of thing.

I understand where you are going ,I think, but I would advocate being a
bit less literal in finding the demarcation at  __xxx__.

You see properties as above ground, and everyday - I still see them as
convenience for some once-in-a-while-necessary magic calls to __xxx__
fairies.

I think the dividing line has something more to do with the degree of
introspection that one undertakes.

Deeper levels of introspection provokes one into a confrontation with
one's Pythonic mortality ;)

Art


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: python versus __python__

Kirby Urner
> This is something I felt comfortable exploring very early on - to the
> extent of having overused it.  I would hate to see you back-end that, as
> I think it is kind of fun to play with.  "let's change the boring old
> rules of math..." kind of thing.
>

Yes, operator overloading is a big part of my "math through programming"
curriculum.  You want your * and + operators to be "modulo N" for example,
the better to appreciate group theory.  Or we might use * to mean 'compose'
as in:

  >>> def f(x):  return 2*x + 1

  >>> def g(x):  return x**2

  >>> class F(object):

        def __init__(self, func):
            self.func = func

        def __mul__(self, other):
            return F(lambda x: self.func(other.func(x)))

        def __call__(self,x):
            return self.func(x)
       
       
  >>> of = F(f)
  >>> og = F(g)
  >>> of(2)
  5
  >>> f(g(2))
  9
  >>> h = of*og
  >>> h(2)
  9
  >>> j = og*of
  >>> j(2)
  25

I think where a lot of kids will first encounter underunder is not in
__init__ but in __name__, as in that "__name__ == '__main__'" trick for
getting scripts to run at the command line, even as they also serve as class
& function repositories for snake charmers in a Python shell.

Kirby

PS:  since you've been studying subclassing primitive types using __new__,
maybe you could show us a user-defined floating point type that reports two
numbers equal if their absolute value difference is less than e.  Anyone?


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: python versus __python__

Kirby Urner
> Kirby
>
> PS:  since you've been studying subclassing primitive types using __new__,
> maybe you could show us a user-defined floating point type that reports
> two numbers equal if their absolute value difference is less than e.  
> Anyone?
>

Like this I guess:

 >>> class Fuzzy(float):
         tol = 1e-8
         
       def __new__(cls, arg=0.0):
                return float.__new__(cls, arg)

         def __eq__(self, other):
                if abs(self-other)<self.tol:
                        return True
                else:
                        return False

               
 >>> j = Fuzzy(10)
 >>> type(j)
 <class '__main__.Fuzzy'>

 >>> k = Fuzzy(10.000000001)

 >>> j == k
 True

 >>> k = Fuzzy(10.01)

 >>> j == k
 False

Kirby


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: python versus __python__

Scott David Daniels
Kirby Urner wrote:
>>Kirby
>>
>>PS:  since you've been studying subclassing primitive types using __new__,
>>maybe you could show us a user-defined floating point type that reports
>>two numbers equal if their absolute value difference is less than e.  
>>Anyone?
>>
>
Fuzzy redone a breath:
class Fuzzy(float):
     tol = 1e-8
     def __new__(cls, arg=0.0):
         return float.__new__(cls, arg)
     def __eq__(self, other):
         return abs(self - other) < self.tol
> ...

Here's the problem:
    Your notion of equality is not transitive.  That's tough -- it
invalidates the assumptions of the float type (and all basic types).
Also, you didn't tweak hash, so a dictionary with these things in them
would not find entries that turn out to be equal.

--Scott David Daniels
[hidden email]

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: python versus __python__

Kirby Urner
> Here's the problem:
>     Your notion of equality is not transitive.  That's tough -- it
> invalidates the assumptions of the float type (and all basic types).
> Also, you didn't tweak hash, so a dictionary with these things in them
> would not find entries that turn out to be equal.
>
> --Scott David Daniels
> [hidden email]

Yes, good tweak, and fair warnings (GvR warned me earlier).  

Fuzzy is no doubt pretty useless, plus I solved my earlier problem a
different way.

This thread has been helpful nonetheless.  I've learned more __python__.

Kirby


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: python versus __python__

Arthur-27


> -----Original Message-----
> From: edu-sig-bounces+ajsiegel=[hidden email] [mailto:edu-sig-
> bounces+ajsiegel=[hidden email]] On Behalf Of Kirby Urner
> Sent: Sunday, October 23, 2005 8:30 PM
> To: 'Scott David Daniels'; [hidden email]
> Subject: Re: [Edu-sig] python versus __python__
>
> Fuzzy is no doubt pretty useless, plus I solved my earlier problem a
> different way.
>
> This thread has been helpful nonetheless.  I've learned more __python__.

Funny the connection.

We're both going off doing useless things with numeric builtins, and playing
around to try to solve some perceived "identity crisis".  Just very
different  kinds of ones.

Art




_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig