some random reflections of a "Python newbie": (2) language issues

Preston Landers prestonlanders at my-deja.com
Wed Dec 15 18:52:46 EST 1999


In article <38580410.B29EC285 at maxtal.com.au>,
  skaller <skaller at maxtal.com.au> wrote:
> Preston Landers wrote:
>
> > Unfortunately for you, Python dicts are a built-in type (for speed
> > reasons) and thus you cannot subclass it, then then implement your
> > locking mechanism.  This is one of the few obvious inconsistencies
in
> > Python's implementation.  If you could subclass builtins, then what
you
> > want to do would be completely trivial.
>
> 	I don't agree: python is NOT inconsistent here. See how Viper does
it,
> it retains the Python typing model as is, generalising the notion
> of type object instead of insisting that they all be classes,
> and that classes are always types. [This is the case in almost all
> OO programming languages, including C++, Eiffel, and Java: the core
> types are NOT classes. All provide 'class emulations' of the core
types,
> as python does]

Hello,

Thanks for the thoughtful post.

I think we are talking about two different kinds of inconsistency.  I'm
not trying to say that the Python implementation diverges from the
language specification, or that Python is inconsistent with other object
oriented languages. (Though I've not much experience with Eiffel,
neither C++ nor Java are "pure" everything-is-an-object languages.)

I'm speaking from the point of view of a developer who doesn't care
(much) about types vs. classes.  he only wants to say, "Okay, here is a
thing that is in every respect like a dictionary, only it can be locked
and unlocked."  Yes, that would break algorithms that accept a
dictionary and expect to be able to add new items.  However, the
developer simply has to keep this in mind and not use such algorithms!
No language feature comes for free, of course.

In that sense, almost all OO languages suffer from this
'inconsistency.'  I'm not really complaining, just noting it.  Why
should a developer care about a distinction between types and classes?
That is an implementation detail that interferes with the "purity" of OO
and tends to confuse people.

theory-is-always-cleaner-than-practicely-yours,

---Preston


--
|| Preston Landers <prestonlanders at my-deja.com> ||


Sent via Deja.com http://www.deja.com/
Before you buy.



More information about the Python-list mailing list