Hands-On Enterprise Application Development with Python

Python as a language has evolved a lot over the years, but despite this fact, a program written in Python 1.0 will still be able to run in Python 2.7, which is a version that was released 19 years after Python 1.0.

Though a great benefit for the developers of Python applications, this backward compatibility of the language is also a major hurdle in the growth and development of major improvements in the language specification, since a great amount of the older code base will break if major changes are made to the language specification.

With the release of Python 3, this chain of backward compatibility was broken. The language in version 3 dropped the support for programs that were written in earlier versions in favor of allowing a larger set of long-overdue improvements to the language. However, this decision disappointed quite a lot of developers in the community.

In the days of Python 2, the text data type str was used to support ASCII data, and for Unicode data, the language provided a unicode data type. When someone wanted to deal with a particular encoding, they took a string and encoded it into the required encoding scheme.

Also, the language inherently supported an implicit conversion of the string type to the unicode type. This is shown in the following code snippet:

str1 = 'Hello'
type(str1)        # type(str1) => 'str'
str2 = u'World'
type(str2)        # type(str2) => 'unicode'
str3 = str1 + str2
type(str3)        # type(str3) => 'unicode'

This used to work, because here, Python would implicitly decode the byte string str1 into Unicode using the default encoding and then perform a concatenation. One thing to note here is that if this str1 string contained any non-ASCII characters, then this concatenation would have failed in Python, raising aUnicodeDecodeError.

With the arrival of Python 3, the data types that dealt with text changed. Now, the default data type str which was used to store text supports Unicode. With this, Python 3 also introduced a binary data type, called bytes, which can be used to store binary data. These two types, str and bytes, are incompatible and no implicit conversion between them will happen, and any attempt to do so will give rise to TypeError, as shown in the following code:

str1 = 'I am a unicode string'
type(str1) # type(str1) => 'str'
str2 = b"And I can't be concatenated to a byte string"
type(str2) # type(str2) => 'bytes'
str3 = str1 + str2
-----------------------------------------------------------
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't concat str to bytes

As we can see, an attempt to concatenate a unicode type string with a byte type string failed with TypeError. Although an implicit conversion of a string to a byte or a byte to a string is not possible, we do have methods that allow us to encode a string into a bytes type and decode a bytes type to a string. Look at the following code:

str1 = '₹100'
str1.encode('utf-8')
#b'\xe2\x82\xb9100'
b'\xe2\x82\xb9100'.decode('utf-8')
# '₹100'

This clear distinction between a string type and binary type with restrictions on implicit conversion allows for more robust code and fewer errors. But these changes also mean that any code that used to deal with the handling of Unicode in Python 2 will need to be rewritten in Python 3 because of the backward incompatibility.

Python is a dynamically typed language, and hence the type of a variable is evaluated at runtime by the interpreter once a value has been assigned to the variable, as shown in the following code:

a = 10
type(a)        # type(a) => 'int'
a = "Joe"      
type(a)        # type(a) => 'str'

Though dynamic interpretation of the type of a variable can be handy while writing small programs where the code base can be easily tracked, the feature of the language can also become a big problem when working with very large code bases, which spawn a lot of modules, and where keeping track of the type of a particular variable can become a challenge and silly mistakes related to the use of incompatible types can happen easily. Look at the following code:

def get_name_string(name):
    return name['first_name'] + name['last_name']

username = "Joe Cruze"

print(get_name_string(username))

Let's see what happens if we try to execute the preceding program:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in get_name_string
TypeError: string indices must be integers

The program exited with a TypeError because we passed a string type to the get_name_string() method and then tried to access the keys inside a string, which is not the correct solution.

With the release of Python 3.5, the community added support for type hinting that was built into the language. This was not an effort to enforce a method, but was rather provided to support the users who may want to use modules that can catch errors that are related to a variable changing its type in between the execution flow.

The general syntax to mark the type of a variable is as follows:

<variable>: <type> = <value>

To mark the types in a method, the following syntax can be used:

def method_name(parameter: type) -> return_type:
    # method body

One of the examples of how to use type hinting in the program code is shown in the following code:

from typing import Dict

def get_name_string(name: Dict[str, str]) -> str:
    return name['first_name'] + name['last_name']

username = "Joe Cruze"

print(get_name_string(username))

When the preceding code is written in an IDE, the IDE can use these type hints to mark the possible violations of the type change of variable in the code base, which can prove out to be really handy by helping to avoid errors that are related to an incorrect type change when dealing with large code bases.

Enterprise IT is complex, and an application that needs to be built for the enterprise will differ a lot from one that is built for a regular consumer. There are several factors that need to be kept in mind before developing an application for enterprise users. Let's take a look at what makes enterprise IT applications different from regular consumer offerings, as shown in the following list:

Python has been present in the enterprise ecosystem in quite a few forms; be it the automation of boring and repetitive tasks, being used as a glue between two layers of a product, or being used for building quick and easy-to-use clients for big server backends, the language has seen an increasing amount of adoption for various use cases. But what makes Python ready for the development of large enterprise applications? Let's take a look:

from flask import Flask
app = Flask(__name__)

@app.route('/', methods=["GET"])
def hello():
    return "Hello, this is a simple Flask application"

if name == '__main__':
    app.run(host='127.0.0.1', port=5000)

Now, as soon as someone calls the preceding script, they will have a flask HTTP application up and running. All that remains to be done here is to fire up a browser and navigate to http://localhost:5000. Then we will see Flask serving a web application without any sweat. All of this is made possible in under 10 lines of code.

With a lot of external libraries providing support for a lot of tasks, an enterprise developer can easily enable support for new features in the application without having to write everything from scratch, thereby reducing the chance of possible bugs and non-standardized interfaces creeping into the application. 

Given all of the preceding benefits of Python, developer productivity will get a boost when using the language while also reducing the total cost of ownership for the software if decisions are made in a well-planned way. These decisions involve how the application architecture will be laid out and which external libraries to use or to develop in-house. So yes, Python is indeed now ready to be used in the mainstream world of enterprise application development.

For an application inside an organization, there might be various users who are stakeholders, and can define the requirements of the application. These users can be broadly split into two categories:

Involving both kinds of stakeholders in the requirement-gathering process is important, and something that will define how well the enterprise application meets the demands of its users.

Once the users have been surveyed for what they would like to have in the application, the next step is to categorize these requirements. Broadly, the requirements can be categorized into two parts:

Once the requirements are identified and categorized into functional and nonfunctional requirements, they then need to be prioritized according to their importance in the application. If this prioritization is not performed, it will lead to increased costs of development, delayed deadlines, and reduced productivity in the organization. Broadly, we can classify the requirements under the following categories:

Once the requirements have been identified, grouped, and prioritized, a document known as the software requirement specification is generated. This document describes the intended purpose, requirements, and nature of the software that needs to be developed.

The software requirement specification (SRS) will describe the following information:

Once the SRS has been generated, it is sent for review and further negotiations. Once they are successfully completed, the application moves into the design phase, where an application mock-up is devised.