Zum Hauptinhalt springen
Nicht aus der Schweiz? Besuchen Sie lehmanns.de
Python - Azhar Ul Haque Sario

Python (eBook)

Software Development (Academic Course: 2025 Edition)
eBook Download: EPUB
2025
202 Seiten
Azhar Sario Hungary (Verlag)
978-3-384-75692-3 (ISBN)
Systemvoraussetzungen
5,16 inkl. MwSt
(CHF 4,95)
Der eBook-Verkauf erfolgt durch die Lehmanns Media GmbH (Berlin) zum Preis in Euro inkl. MwSt.
  • Download sofort lieferbar
  • Zahlungsarten anzeigen

Master Python for Real-World Software Engineering in 2025!


This book, Python: Software Development (Academic Course: 2025 Edition), takes you from computational basics to production-ready applications. Start with algorithms, branching, and iteration using pseudocode. Dive into Python's runtime, virtual environments, and pip for professional setups. Explore variables as object references, mutability, and memory models. Master control flow with if-elif-else, loops, and functional decomposition using def, parameters, and the LEGB rule. Handle strings with f-strings, manage files with context managers, and serialize data using JSON, CSV, and XML. Build core data structures like lists, tuples, dictionaries, and sets, plus comprehensions for Pythonic code. Understand iterators, generators, and Big-O complexity for efficient processing of massive datasets. Learn error handling with try-except-else-finally and custom exceptions. Write tests with pytest, use mocks, and adopt TDD. Replace print() with structured logging using getLogger(name). Grasp OOP with classes, inheritance, and composition, favoring Pythonic duck typing over rigid patterns. Conquer asynchronous programming with asyncio for I/O-bound tasks. Analyze data with Polars and Pandas, build ML models with scikit-learn, and deploy APIs using FastAPI or Django. Containerize with Docker and automate with CI/CD via GitHub Actions and MLOps tools like MLflow and DVC. Each chapter ends with hands-on case studies, like file organizers, calculators, log parsers, shopping carts, API clients, and fraud detection systems.


Unlike traditional Python books that recycle beginner syntax or chase trends, this one bridges academic rigor with 2025 job demands. It teaches why mutability matters for design, why generators beat lists for big data, and why structured JSON logs enable microservice debugging-insights missing from most texts. You won't just code; you'll architect maintainable, testable, and scalable systems. From virtual environments on day one to full MLOps pipelines, it equips you for real roles in startups or enterprises. No fluff, just battle-tested skills that make you stand out.


Copyright Disclaimer: This book is independently produced and has no affiliation with any educational board, university, or cited institution. All references are used under nominative fair use for educational purposes.

PART 2: Data Structures and Algorithmic Abstraction


 

Core Data Structures: Lists and Tuples


 

4.1 Lists: The Mutable Dynamic Sequence

 

When you're first learning to code, and especially in Python, the list feels like the most natural, essential tool in your toolbox. It’s the default “put things in a box” solution. You have a collection of usernames? Put them in a list. A series of numbers to process? List. A to-do list? Well, the name says it all. This intuitive comfort is by design. A list is a dynamic collection, and its very essence—its primary identity—is that it is mutable. It is expected to change.

 

This mutability is a powerful promise. When you, as a developer, choose a list to store data, you are sending a clear signal to anyone else who reads your code (including your future self): "This collection is meant to grow, shrink, and be reordered." It's a living, breathing part of your program's state.

 

But what is a list, under the hood? This isn't just academic. Knowing its implementation is the key to understanding why it behaves the way it does. A Python list is not a linked list, as you might find in other languages. It is a dynamic array.

 

Think of it as a row of mailboxes, but one that comes with a "contract" with the post office. You initially rent 10 mailboxes. When you fill all 10, and you need an 11th, the post office doesn't just add one more. It finds a brand new row with, say, 20 mailboxes, moves all your existing mail from the old 10 boxes to the first 10 new ones, and then hands you the key to the new row. This "move" is an expensive operation, but it means you now have plenty of empty space to add mailboxes 11 through 20 very, very quickly.

 

This is exactly how a list's append() method works. Adding an item to the end of a list is, on average, an incredibly fast operation. We call this "amortized O(1)". Most of the time, Python has already pre-allocated extra space, so adding an item is just a matter of placing it in the next empty slot.

 

Let's see this in action. We're building a system to track user logins:

Python

 

# A list is perfect because we expect it to grow all day.

login_events = []

 

login_events.append(('alice', '2025-11-16T09:00:01'))

login_events.append(('bob', '2025-11-16T09:00:03'))

login_events.append(('carol', '2025-11-16T09:01:15'))

# This is fast, efficient, and clean.

 

Now, contrast that with inserting an item at the beginning of the list. What if you wanted to add a "system boot" event at the very start?

Python

 

# This is an O(n) operation... which means it's SLOW.

login_events.insert(0, ('SYSTEM_BOOT', '2025-11-16T08:59:00'))

 

This single line is far more "expensive" than all the appends. To insert at index 0, Python has to take every single item already in the list—Alice, Bob, and Carol—and shift them all one position to the right to make room. If your list has 10 million items, that’s 10 million "move" operations. This is a classic performance trap. A list is fast at the end, but slow at the beginning.

 

This behavior informs how we use its core "mutator" methods—the verbs that change the list in-place:

 

.append(item): Adds a single item to the end. Your default, go-to "add" method.

 

.extend(iterable): This is different. It doesn't add one item; it takes another collection (like another list) and adds all of its elements to the end. It's like merging two shopping lists.

 

.pop(index=-1): Removes an item and returns it. By default, it removes the last item (index -1), which is fast (O(1)) and makes lists behave like a "stack" (Last-In, First-Out). Popping from the beginning (.pop(0)) suffers from the same O(n) slowness as inserting there.

 

.remove(value): This is the one that bites beginners. It doesn't remove by index; it searches the list from the beginning for the first matching value and removes it. This is also an O(n) operation because it has to potentially look at every single item to find the one you want to remove.

 

.sort(): This reorders the list in-place. This is a critical distinction. After you call my_list.sort(), the original order of my_list is gone forever, replaced by the new, sorted order.

 

A list is your best friend when you need a general-purpose, mutable collection. But its flexibility is also its greatest danger. Because it can be changed anywhere, passing a list into a function can lead to "spooky action at a distance," where that function modifies your list in a way you didn't expect. This is where its counterpart, the tuple, comes in.

 

4.2 Tuples: The Immutable Fixed Sequence

 

If the list is an open-ended, dynamic "collection," the tuple is a "record." Its defining characteristic is its immutability. Once a tuple is created, it cannot be changed. Ever. You can't add items, you can't remove items, and you can't sort it.

 

For a beginner, this sounds like a bug, not a feature. Why would you ever want a "list that's broken"? The "Aha!" moment comes when you stop thinking of tuples as collections and start thinking of them as atomic units of data.

 

This "limitation" is, in fact, one of the most powerful features in Python, and it provides three profound advantages that experienced developers rely on every single day.

 

1. Performance and Memory

 

A tuple is, quite simply, "cheaper" for Python to handle than a list. Because its size is fixed, Python knows exactly how much memory to allocate for it. There is no need for the "over-allocation" strategy that lists use.

 

Let's go back to our analogies. A list is an expandable, soft-sided suitcase. It's heavy by itself because it has extra zippers, flexible fabric, and a frame designed to handle growing. A tuple is a custom-molded, hard-shell case. It’s built for one specific thing. It's lighter, more rigid, and uses the absolute minimum material necessary because it will never change shape.

 

When your program creates millions of these data structures, this efficiency adds up. The interpreter can create, store, and access tuple data faster and with a smaller memory footprint.

 

2. Intent (The Human-Readable Contract)

 

This is the most important architectural reason to use a tuple. When you write a function that returns a tuple, you are making a promise to the caller.

 

Imagine a function that gets a user's database record:

Python

 

def get_user_by_id(user_id):

# ... database logic ...

# This user record is fixed.

return ('jdoe', 'john.doe@example.com', 11928)

 

When I call this function and receive ('jdoe', 'john.doe@example.com', 11928), I know instinctively that this is a read-only record. It's an atomic piece of data. The first item is the username, the second is the email, and the third is the user ID. I'm not supposed to .append() a new field to it. I'm not supposed to .sort() it (that would be nonsense!).

 

If the function returned ['jdoe', 'john.doe@example.com', 11928], it sends a dangerously mixed message. It looks like I can, and perhaps should, modify it. Using a tuple communicates intent and "write-protects" the data from accidental modification, making the entire program safer and easier to reason about.

 

 

 

 

3. Hashability (The Technical Superpower)

 

This is the big one. This is the technical capability that separates tuples from lists entirely. Tuples are hashable. Lists are not.

 

What does "hashable" mean? It means the object has a "hash value" (a unique-ish number derived from its contents) that is guaranteed to never change during its lifetime. Because a tuple is immutable, its contents can never change, so its hash value is stable. A list, being mutable, could change at any time, so its hash value would become invalid.

 

Why do we care? Because the single most important data structure in Python, the dictionary, requires its keys to be hashable.

 

A dictionary is a hash map. It uses the key's hash value to instantly calculate where to store the corresponding value. This is what gives dictionaries their blazing-fast O(1) lookups.

 

You cannot use a list as a dictionary key.

Python

 

my_dict = {}

my_key = [1, 2]

my_dict[my_key] = 'value' # This will raise a TypeError: unhashable type: 'list'

 

But you can use a tuple.

Python

 

my_dict = {}

my_key = (1, 2)

my_dict[my_key] = 'value' # This works perfectly!

 

This single capability unlocks a world of programming patterns. As we'll see in the case study, this is how you can represent compound keys, like an (x, y) coordinate on a grid, a (year, month, day) date, or a (product_id, size) SKU.

 

A tuple is your choice for fixed records: coordinates, RGB color values, API responses, database rows. It's a signal of intent, a performance optimization, and a technical necessity for more advanced data structures.

 

4.3 Advanced Unpacking, Slicing, and Multi-Assignment

 

Once you understand the "what" (lists and tuples are sequences), you can explore the "how"—the...

Erscheint lt. Verlag 17.11.2025
Reihe/Serie Software Development
Sprache englisch
Themenwelt Mathematik / Informatik Informatik Programmiersprachen / -werkzeuge
Schlagworte 2025 edition • asyncio concurrency • data structures • MLOps pipeline • professional testing • Python programming • software development
ISBN-10 3-384-75692-4 / 3384756924
ISBN-13 978-3-384-75692-3 / 9783384756923
Informationen gemäß Produktsicherheitsverordnung (GPSR)
Haben Sie eine Frage zum Produkt?
EPUBEPUB (Ohne DRM)

Digital Rights Management: ohne DRM
Dieses eBook enthält kein DRM oder Kopier­schutz. Eine Weiter­gabe an Dritte ist jedoch rechtlich nicht zulässig, weil Sie beim Kauf nur die Rechte an der persön­lichen Nutzung erwerben.

Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belle­tristik und Sach­büchern. Der Fließ­text wird dynamisch an die Display- und Schrift­größe ange­passt. Auch für mobile Lese­geräte ist EPUB daher gut geeignet.

Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise

Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.

Mehr entdecken
aus dem Bereich
Apps programmieren für macOS, iOS, watchOS und tvOS

von Thomas Sillmann

eBook Download (2025)
Carl Hanser Verlag GmbH & Co. KG
CHF 40,95
Apps programmieren für macOS, iOS, watchOS und tvOS

von Thomas Sillmann

eBook Download (2025)
Carl Hanser Verlag GmbH & Co. KG
CHF 40,95