anomaly

[zipher]

> > Okay.  I apologize for thinking in C and believing "int" was a keyword.  It isn't in Python as you remind me.  However, this is where I'm arguing the purity has hammered practicality into the ground.
> >
> > Python is trying to be as elegant as LISP in trying to make everything an Object.  It's not necessary, and it's trying to put lipstick on a pig instead of making BBQ.  Python will be as elegant, but in a different direction of the axis.
> 
> How is it a problem for an integer to be an object?

It's not any more of a problem than trying to put lipstick on a pig, but at some point the pig might complain.  In this case, it has to be faced that an integer is a very concrete type -- because we're not running on a Symbolics Machine.  

Once again, Church's Thesis is misinforming people -- it doesn't matter that you can do everything on everything -- at some point the rubber has to hit the road and in Python, when I use an int, I expect some guarantee of O(log n) behavior, because I assume the dev team hasn't done something stupid, like implement bigints in LISP.

> In Python, I can
> put together a generic handler for a generic list and depend on
> everything being an object:
> 
> lst = ["asdf", 2, lambda x: x+1, re.compile("q[a-tv-z]"), 3.14159]

Okay, Chris, now you've made a pig out of lipstick.  The lipstick is lambda expressions.  We already know the BDFL opinion of them.  The pig is whatever that toy problem you just concocted is supposed to do.

> In Java, I would have to box up that integer 2 and that float 3.14159
> (and maybe the string too?) to make it possible to put them into a
> generic collection, because integers and objects are fundamentally
> different things.

No. Yes!? I mean no!  They are different, but it's a type, even though (in this thought experiment) it's not an object.  And types can be put into collections (hey just like C++!).

> In Python, ints and floats and strings all follow
> the same rules as other objects: they can be passed around, stored in
> collections, turned into strings with str() or repr(), etc, etc, etc.

But Chris, you are forgetting:  Python could do all this before the type/class unification.

> They have methods, they react to operators, everything is done
> according to a simple set of rules. This does not harm practicality -
> it's extremely helpful in a number of situations.

But you are infected with script-mind.  Scriptmind is a disease, where no one worries about the underlying architecture or the effects on machine performance.  This is fine for the web, but not for CPython.  Many lost souls have gone the way of Javascript and been infected.  Perhaps you are one of them.
 
> And I still don't see how this has anything to do with your confusion
> about shadowing the name 'int'. As I see it, attempting to redefine
> int to be a null subclass of str should have one of two results:
> either it's a straight-up error, or it does exactly what happens in
> Python - calling 'int' now calls a subclass of 'str'.

It just blurs conceptual boundaries, something I call "SeparabilityOfDomains".

Mark