[Edu-sig] python versus __python__

[Scott David Daniels]

Arthur wrote:
> Scott David Daniels wrote:
> ... 
> Getting one's arms around all the practical implications of these issues 
> related to mutable, immutable - understanding when one should want to 
> retain object  identity, and when one should want to break it, the full 
> implications of these decisions,  howto  implement one's intentions - 
> is, on one hand - I find, fundamental to getting things to actually 
> happen in Python as one intends, and on the other hand , challenging. It 
> is the fundamental reason I chafe a bit when Python is described as "easy".
Ah, but you are concentrating on fundamental issues of language design
which are, in fact, subtle.  Normally the user of a language simply
accepts the determination of the designer about what is mutable and
what is not, and goes on from there.  I think these issues are indeed
fascinating, but they are issues of language design, not even issues
for the __python__ class.  Python allows you to play with these issues
in your own classes, few other languages allow you that freedom.

> Because I have had  trouble with these issues from day one, it ain't day 
> one anymore, I still have some troubles with them and I prefer to think 
> that it is challenging over thinking that I am dumb.
Well, you are right.

> I am going down the road of the mutable complex number with my eyes 
> (half) open precisely because I want the ability to change the value of 
> a complex number object (and it's subclasses), without changing the 
> identity of the object.
In the first Fortran (and for a number of versions later), you called
"subroutines" with all arguments "by reference."  There were people
who would abuse this ability to change constants (which were shared
across a single "compilation unit") to find compact ways to alter
things that were not properly variables.  This brings new meaning
to "1+1=4 for sufficiently large values of 1".

>>If you define a class named PyGeoTriangle, you create new instances with
>>PyGeoTriangle(<some args>).
> 
> The connection of what you are saying here to the issue on which I am 
> particularly confused  is - well -  confusing, to me.

I'm trying to point out that you understand perfectly that some things
are both objects and callable; you just don't realize that you do.  The
most obvious example is a class, while the second (and far less) obvious
is an instance of a class with a __call__ method.

In the case of a class that you have defined, you can use the class name
itself in calls to things like "isinstance,"

> In Arthur's head there is the numeric type "float", and there is the 
> function float() - both built in.  And in Arthur's head, while  
> functions are first class objects in Python they are objects of a 
> different nature than type in the sense of numeric type.  

> So in some sense what I am not grasping is how class/type unification 
> can be inclusive of verb - i.e, float(1) -  and  noun - i.e., type(1.) 
> - unification - which in Arthur's head, is something else again.
The magic trick of class / type unification is: we both need to name
types (they must have existence as objects) for use in some functions,
and we need to provide constructors for instances of that type.  This
is the same situation we are in about classes.  The class situation is
resolved by making "special" methods that get invoked when the class is
used to call


--Scott David Daniels
Scott.Daniels at Acm.Org