class vs type

[Colin J. Williams]

In Python Types and Objects, Shalabh
Chaturvedi says (in the Python 3.0
documentation - New Style Classes)

"The term class is traditionally used to
imply an object created by the class
statement. However, classes are now
synonymous with types. Built-in types
are usually not referred to as classes.
This book prefers using the term type
for both built-in and user created types."

Do we need two different words to
describe what is essentially the same thing?

Colin W.

 

[Hrvoje Niksic]

In Python Types and Objects, Shalabh Chaturvedi says (in the Python
3.0 documentation - New Style Classes)

"The term class is traditionally used to imply an object created by
the class statement. However, classes are now synonymous with
types. Built-in types are usually not referred to as classes. This
book prefers using the term type for both built-in and user created
types."

Do we need two different words to describe what is essentially the
same thing?

We don't, not anymore, which is why the author chooses the word "type"
for both in the last sentence.

But, as the author correctly explains, class and type used to not be
the same thing. Classes were created with 'class', and they were
fundamentally different from C types created in extension modules.
All instances of old-style classes are of type 'instance', which is
why they have the __class__ attribute, so you can find their actual
class. (Functions like "isinstance" contain hacks to support
old-style classes.) New-style classes elevate Python-level classes to
types equal to the built-in ones, which is why the word "type" is now
sufficient for both.

 

[Colin J. Williams]

We don't, not anymore, which is why the author chooses the word "type"
for both in the last sentence.

In this case, why do we continue to use
the word class to generate a type?

But, as the author correctly explains, class and type used to not be
the same thing. Classes were created with 'class', and they were
fundamentally different from C types created in extension modules.
All instances of old-style classes are of type 'instance', which is
why they have the __class__ attribute, so you can find their actual
class. (Functions like "isinstance" contain hacks to support
old-style classes.) New-style classes elevate Python-level classes to
types equal to the built-in ones, which is why the word "type" is now
sufficient for both.

Doesn't Python 3 provide an opportunity
to move away from discussions about
new_style vs old-style? This an
opportunity to treat old-style as a
historical artefact, not requiring
current explanation.

Colin W.

 

[Terry Reedy]

| Doesn't Python 3 provide an opportunity
| to move away from discussions about
| new_style vs old-style? This an
| opportunity to treat old-style as a
| historical artefact, not requiring
| current explanation.

Yes, there will not be 'old-style' classes in Py3 and 3.0 doc will not
mention them.. But we are actually at 2.5 and there will be 2.6, 2.7, 2.8?
that still have them.

 

[Colin J. Williams]

| Doesn't Python 3 provide an opportunity
| to move away from discussions about
| new_style vs old-style? This an
| opportunity to treat old-style as a
| historical artefact, not requiring
| current explanation.

Yes, there will not be 'old-style' classes in Py3 and 3.0 doc will not
mention them.. But we are actually at 2.5 and there will be 2.6, 2.7, 2.8?
that still have them.

Terry,

Thanks for clarifying the intent.

The Python 3.0 doc, under Class, has:
Programmer’s note: Variables defined in
the class definition are class
variables; they are shared by all
instances. To define instance variables,
they must be given a value in the
__init__() method or in another method.
Both class and instance variables are
accessible through the notation
“self.name“, and an instance variable
hides a class variable with the same
name when accessed in this way. Class
variables with immutable values can be
used as defaults for instance variables.
For new-style classes, descriptors can
be used to create instance variables
with different implementation details.

Presumably, it is intended that every
class implicitly inherits from object?

Colin W.

 

[Gabriel Genellina]

The Python 3.0 doc, under Class, has:

Programmer’s note: Variables defined in [...]
For new-style classes, descriptors can
be used to create instance variables
with different implementation details.

Presumably, it is intended that every
class implicitly inherits from object?

For Python 3.0, yes. Where did you read the above text? The 3.0 docs at
http://docs.python.org/dev/3.0/reference/compound_stmts.html#class-definitions
are already updated and don't menction "new-style classes" at all.

 

[Steven D'Aprano]

In this case, why do we continue to use the word class to generate a
type?

Because type is a callable, and class is convenient syntactic sugar.

class Parrot(object):
def speak(self, msg):
return "Polly sez %s" % msg


is much more convenient than:

import new
Parrot = type('Parrot', (object,),
{'speak': lambda self, msg: 'Polly sez %s' % msg})

particularly for large classes with many methods.

 

[Stargaming]

We don't, not anymore, which is why the author chooses the word "type"
for both in the last sentence.

In this case, why do we continue to use the word class to generate a
type? [snip]
Doesn't Python 3 provide an opportunity to move away from discussions
about new_style vs old-style? This an opportunity to treat old-style
as a historical artefact, not requiring current explanation.

So, do we have to decide between 'instance' and 'object' as well?

Old-style classes *are* deprecated in favor of new-style classes
(whoops!) but the term 'class' is still valid (IMO). It's a common phrase
in the OO-world and removing it from a Python programmer's vocabulary
(what essentially wouldn't work so well, I suspect) won't help.

If you're speaking about just the syntax, well okay, this could be
sensible in some unification-focussed vocabulary-minimalistic manner. But
combining the class _statement_ and the type _expression_ would
essentially change class definitions into expressions.

Cheers,
Stargaming