Python complaints

[skaller]

Tim Peters wrote:
> 
> [John Skaller]
> >       Integers are NOT objects in Python, they're values.
> > Same for strings and tuples. We can pretend they're objects,
> > and say they're 'immutable', but the truth is that they're
> > just plain values.
> 
> The implementation doesn't support this view -- e.g., intobject.c has every
> bit as much "object hair" as listobject.c.

I'm sure it does -- in CPython. But that is irrelevant, when considering
the abstract language. Int in python is neither mutable, nor does it
support polymorhpic methods: class instances are both mutable and
support
polymorphic methods (via inheritance, for example) by contrast.

There is only one hint in the python language I can think of that
integers are objects, and that is the builtin function 'id', 
and the corresponding 'is' operator. In CPython:

	id(1) != id(1)
	1 is not 1

are true: they're distinct objects. But this is NOT the case in Viper;
ints, strings and tuples  are compared by value, _even_ by the 'is'
operator, and the id's of equal values are identical.

It's hard to say if this is compliant to 'python'
since the existing 'specification' is somewhat implementation dependent;
but I believe my implementation is reasonable. As for implementation
details,
in Viper, integers, strings, and tuples are in fact represented
by 'values', not objects, at least in terms of the implementation
languages
terminology.

Of course, underlying a representation of a value in memory, there is 
(almost) always an object in the C sense, but that isn't what 
I call an 'object' in the more abstract sense.

>it's unclear what you're saying. 

	Hope the above clears it up.

> Perhaps that ints & strings etc don't support methods?
> That's just historical accident, and in the current CVS snapshot most of the
> string module's functionality has been reimplemented as methods of string
> objects (very nice, btw! most <wink> people will like this).

	That is an issue of scoping and grammar and has no bearing
at all on the 'objectness' of the entity. There is no semantic
difference
between non-polymophic methods called like:

	x.f()

and a function call

	f(x)

and this is in fact the case for python class 'methods':
they are in fact ordinary functions, individually.
However the dynamic lookup gives the impression
of polymorphism, so I'd agree that they deserve the name
'methods' in the OO sense.
 
> >       My new Viper interpreter may support 'mutable'
> > integers and strings as follows: you write:
> >
> >       x := 1
> >       x++
> >       x+=1
> >
> > This notation actually creates a reference (pointer) to the value,
> > so x is a 'reference to an integer', and x++ actually means:

[]

> > Comments on this idea appreciated.
> 
> I'm a long-time fan of augmented assignment (+= and friends), but prefer to
> live without the pre- and post-increment gimmicks.  Introducing references
> isn't necessary to implement the former, so unless you've got some other
> killer use in mind for references I'd recommend not doing it that way (extra
> syntax, extra complications, & mainline Python will likely never do it that
> way).

	OK. I implemented the following operators last night in Viper:

	+= -= *= /= %= <<= >>= |= &= ^= := ++ -- 
	(i.e. all the 'C' assignment operators, plus := which is the same as =)

I didn't use references. [you are probably right about the extra
complications]
You can write:

	x += 1

but it is a _statement_, and no multiple occurences are permitted,
that is, you cannot write:

	x += y += 1

since I think that would be confusing. So you can write:

	++i

but NOT

	x = y[i++]

The semantics of lhs op= rhs are: evaluate the left and right hand
sides, and apply
the functional operation 'op' implied, then assign the result to the
lhs.
There is a deficiency in my implementation at present:

	x[ f() ] += 1

will call f() twice.

> If/when Guido adds augmented assignment to Python (he's not oppposed to it),
> 
>     thing += thang
> 
> will most likely compile to (pseudo-code):
> 
>     call thing.__addeq__(thang) # must return a result on the stack
>     bind "thing" to the result in thing's namespace
> 
> It's then up to each object's __addeq__ method to decide whether to return
> self (to effect a mutating +=) or to return a different object (to effect a
> functional +=).  It's likely that int.__addeq__ will do the latter and
> list.__addeq__ the former, so that
> 
>     x = 42
>     y = x
>     x += 1
>     print x, y, x is y
> 
> prints
> 
>     43, 42, 0
> 
> while
> 
>     x = [1, 2, 3]
>     y = x
>     x += [4]
>     print x, y, x is y
> 
> prints
> 
>     [1, 2, 3, 4], [1, 2, 3, 4], 1
> 
> when=-everything's-a-reference-nothing-isn't-ly y'rs  - tim

I appreciate this explanation. My current implementation
is different, and what you suggest above is probably correct.
in particular:

	x += y

means the same as

	x = x + y

in my implementation, so for a list, I get

	[1,2,3,4] [1,2,3] 0

BTW: In the current CPython object model, extension types
have a 'vtable' and adding extra operators to the language
makes that table larger (modulo extra indirections, as used
to reduce the overhead at present).

Viper has none of these problems, since methods of
objects of a particular type are plain functions,
exactly the same as for class instances [literally!]
Instead of a table of methods, Viper methods are defined
as ordinary class methods: you could define:

	class PyIntType:
		...
		def __addeq__(self, value): ...

if you wanted, or not: the 'table of methods' is a dictionary
of arbitrary length, and the entries are accessed by name,
not by slot number.

This is inefficient, compared to the CPython mechanism.
This is fixed in two ways: builtin types do not use this
mechanism, the interpreter 'knows' the operations on them
and just does them. The other mechanism is compilation.
The first stage of that is called binding: replacing
named lookup with indexing (same as CPython's fast-load
for local variables). This can be done in the interpreter
right now [manually] for modules and functions.
[I have yet to implement the mechanism for classes and instances]

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850