> > 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
--
https://mail.python.org/mailman/listinfo/python-list
