• Choose a category
• All
• Classic-Fiction

>>> print(X)

None

>>> L = [None] * 100 # Initialize a list of 100 Nones

>>> L

[None, None, None, None, None, None, None, None, None, None, None, None,

None, None, None, None, None, None, None, None, ...a list of 100 Nones...]

How to Break Your Code’s Flexibility

I’ll have more to say about all of Python’s object types later, but one merits special treatment here. The type object, returned by the type built-in function, is an object that gives the type of another object; its result differs slightly in 3.0, because types have merged with classes completely (something we’ll explore in the context of “new-style” classes in Part VI). Assuming L is still the list of the prior section:

# In Python 2.6:

>>> type(L) # Types: type of L is list type object

>>> type(type(L)) # Even types are objects

# In Python 3.0:

>>> type(L) # 3.0: types are classes, and vice versa

>>> type(type(L)) # See Chapter 31 for more on class types

Besides allowing you to explore your objects interactively, the practical application of this is that it allows code to check the types of the objects it processes. In fact, there are at least three ways to do so in a Python script:

>>> if type(L) == type([]): # Type testing, if you must...

print('yes')

yes

>>> if type(L) == list: # Using the type name

print('yes')

yes

>>> if isinstance(L, list): # Object-oriented tests

print('yes')

yes

Now that I’ve shown you all these ways to do type testing, however, I am required by law to tell you that doing so is almost always the wrong thing to do in a Python program (and often a sign of an ex-C programmer first starting to use Python!). The reason why won’t become completely clear until later in the book, when we start writing larger code units such as functions, but it’s a (perhaps the) core Python concept. By checking for specific types in your code, you effectively break its flexibility—you limit it to working on just one type. Without such tests, your code may be able to work on a whole range of types.

This is related to the idea of polymorphism mentioned earlier, and it stems from Python’s lack of type declarations. As you’ll learn, in Python, we code to object interfaces (operations supported), not to types. Not caring about specific types means that code is automatically applicable to many of them—any object with a compatible interface will work, regardless of its specific type. Although type checking is supported—and even required, in some rare cases—you’ll see that it’s not usually the “Pythonic” way of thinking. In fact, you’ll find that polymorphism is probably the key idea behind using Python well.

User-Defined Classes

We’ll study object-oriented programming in Python—an optional but powerful feature of the language that cuts development time by supporting programming by customization—in depth later in this book. In abstract terms, though, classes define new types of objects that extend the core set, so they merit a passing glance here. Say, for example, that you wish to have a type of object that models employees. Although there is no such specific core type in Python, the following user-defined class might fit the bill:

>>> class Worker:

def __init__(self, name, pay): # Initialize when created

self.name = name # self is the new object

self.pay = pay

def lastName(self):

return self.name.split()[-1] # Split string on blanks

def giveRaise(self, percent):

self.pay *= (1.0 + percent) # Update pay in-place

This class defines a new kind of object that will have name and pay attributes (sometimes called state information), as well as two bits of behavior coded as functions (normally called methods). Calling the class like a function generates instances of our new type, and the class’s methods automatically receive the instance being processed by a given method call (in the self argument):

>>> bob = Worker('Bob Smith', 50000) # Make two instances

>>> sue = Worker('Sue Jones', 60000) # Each has name and pay attrs

>>> bob.lastName()