[Python-3000] Fwd: proposal: disambiguating type

[Guido van Rossum]

Let's please leave 2.x alone.

On 5/23/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Guido van Rossum wrote:
> > On 5/22/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >> tomer filiba wrote:
> >>
> >>> i suggest splitting this overloaded meaning into two separate builtins:
> >>> * type(name, bases, dict) - a factory for types
> >>> * typeof(obj) - returns the type of the object
> >> Or just drop the function usage altogether and make
> >> __class__ the one obvious way to find out something's
> >> class/type.
> >
> > Well, you could overload __class__ to "lie" -- but type won't. I'd
> > rather not lost that functionality. I expect that with proxies
> > becoming more popular they may start lying about __class__. For most
> > purposes that's fine but I'd like to be able to tell whether I'm
> > dealing with a proxy, if I really need to know.
>
> That suggests to me that Tomer's on the right track in renaming the query
> function and leaving the metaclass alone. A lot of the code that currently
> uses type() directly doesn't work properly with classic classes and other
> metaclasses (like remote proxies) that persuade "__class__" to lie (I don't
> use classic classes if I can help it, so I'm fairly sure some of my own code
> fits into this category).
>
> You could even standardise the "use __class__ if it's present and typeof(x)
> otherwise" pattern as a separate query function:
>
> def classof(instance):
>      try:
>          return instance.__class__
>      except AttributeError:
>          return typeof(instance)
>
> Then:
>
>    type = the standard metaclass
>    typeof = query function that an instance's metaclass cannot affect
>    classof = query function that an instance's metaclass can affect
>
> Metaclasses that play games with __class__ (like types.ClassType) can then be
> detected by the fact that typeof(x) != classof(x).
>
> classof and typeof could actually be added in 2.x - it's only the removal of
> type's single argument behaviour that would have to wait until Py3k (or do the
> deprecation dance in the 2.x series)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>              http://www.boredomandlaziness.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)