Up to Python 2.1, old-style classes were the only flavour available to the user.
The concept of (old-style) class is unrelated to the concept of type:
if x
is an instance of an old-style class, then x.__class__
designates the class of x
, but type(x)
is always <type
'instance'>
.
This reflects the fact that all old-style instances, independently of
their class, are implemented with a single built-in type, called
instance.
New-style classes were introduced in Python 2.2 to unify the concepts of class and type.
A new-style class is simply a user-defined type, no more, no less.
If x is an instance of a new-style class, then type(x)
is typically
the same as x.__class__
(although this is not guaranteed – a
new-style class instance is permitted to override the value returned
for x.__class__
).
The major motivation for introducing new-style classes is to provide a unified object model with a full meta-model.
It also has a number of immediate benefits, like the ability to
subclass most built-in types, or the introduction of "descriptors",
which enable computed properties.
For compatibility reasons, classes are still old-style by default.
New-style classes are created by specifying another new-style class
(i.e. a type) as a parent class, or the "top-level type" object if no
other parent is needed.
The behaviour of new-style classes differs from that of old-style
classes in a number of important details in addition to what type
returns.
Some of these changes are fundamental to the new object model, like
the way special methods are invoked. Others are "fixes" that could not
be implemented before for compatibility concerns, like the method
resolution order in case of multiple inheritance.
Python 3 only has new-style classes.
No matter if you subclass from object
or not, classes are new-style
in Python 3.
Best Answer
The scope qualifiers
Public
andFriend
determine whether clients in different projects can see the item.Public
items will be accessible to client code in other projects1 and code in the same project.Friend
items are accessible only to code in the same project, not to code in other projects.Private
items are accessible only to code in the same class.Properties are different from public variables, because with properties you can execute your own code when the client gets or sets the value2. EDIT following Deanna's comment: Also note that variables can be passed ByRef to a function and changes will work as expected. This is NOT the case for properties.
NB C# may be more modern, but IMHO the VB6 treatment of properties and public variables is significantly better than the .Net treatment.
IMHO Microsoft made a real design mistake in creating these differences between properties and public fields in .Net. Not convinced? After the first releases of .Net, the C# and VB compilers were modified to support automatically implemented properties. These allow you to create properties in just one line of code, so that it's later possible to add logic on get/set without causing problems. IMHO this proves that public variables should have been made indistinguishable from properties.
1 Assuming your project type actually allows your classes to be used by other projects (i.e. ActiveX DLL, OCX, or ActiveX exe).
2 In the
Property Get
,Property Let
andProperty Set
procedures.