violent-python3 modernises a book's source code without rewriting it

A book companion, and the conversion is the project

The repository holds the source code for the book Violent Python by TJ O'Connor. What the project adds is a conversion: the code has been fully converted to Python 3, reformatted to comply with PEP 8, and refactored to eliminate dependency problems caused by deprecated libraries.

That framing matters, because it tells you what to expect. This is not a security tool that happens to be maintained, it is the code that a reader of a book would have typed in, made runnable on a modern interpreter. The chapter structure is preserved on purpose. The documentation states that the directories and files are named so they can be easily related to the content presented in each chapter, and the top level of the repository is chapter01 through chapter07, plus a tests directory, a pyproject.toml, a requirements.txt and a poetry.lock.

The maintainer also points at a sibling effort, a similar conversion of the source of Black Hat Python by Justin Seitz, hosted under the same account, so the same treatment exists for the other well known book in this area.

The audience is a reader with the book in hand who has tried to run an example and hit a wall, either because the code was Python 2 or because a library it imported no longer exists. The second audience is a teacher or a course author who needs working code to assign, and who needs the chapter mapping to stay intact.

The third audience is the more interesting one for engineers: anyone who wants to read a well curated set of small offensive and forensic scripts in their modern form, in order to see how a decade of Python style changes reshape working code.

Setting it up: a venv, a clone and one pip command

The usage instructions are short and the recommendation is a virtual environment, which is described as recommended in the documentation. The commands are given as a sequence from a shell:

user@host:~/DIR$ git clone https://github.com/EONRaider/violent-python3
user@host:~/DIR$ python3 -m venv venv
user@host:~/DIR$ source venv/bin/activate
(venv) user@host:~/DIR$ pip install -r requirements.txt

Note the order in the documentation: the directory is created first, the repository is cloned into it, and the virtual environment is created inside that directory, then activated, and only then are the requirements installed.

Two dependencies deserve a warning before you install them. The requirements list includes scapy, python-nmap and dpkt, which are packet and network libraries, and pybluez, which is marked as optional and only installs on macOS through a marker on the sys_platform value.

The dependency set is otherwise ordinary for the era: pexpect and ptyprocess for the script interaction chapters, beautifulsoup4 and MechanicalSoup for the scraping ones, requests for the HTTP work, geoip2 and IPy for the geolocation material, Pillow for the image chapters, pypdf4 for the PDF parsing examples, and python-nmap for the scanning chapter.

The project also ships a poetry.lock and a pyproject.toml, so there are two ways to resolve the dependency set, and they do not quite agree. The pyproject pins python-nmap to a version in the 0.7 line while the requirements file asks for a version in the 0.6 line. Nothing stops you from using either, but a mismatch like that is worth knowing about before you file a bug about an installation problem.

The conversion rules, and what was deliberately left broken

The notes section is the heart of the project, and it reads like a list of deliberate decisions rather than a changelog.

The mechanical changes come first. The frequent use of string concatenation by the original author was replaced with string interpolation for readability and a more modern standard. Names of files, variables, functions, classes and methods now conform to PEP 8 naming standards. The deprecated optparse library was replaced with argparse throughout, and all argument parsing now sits under the __main__ execution scope of each file. Arguments that were mandatory for the scripts to run but treated as optional in the original code are now positional, and every script that uses argparse now has a usage prompt available through a -h argument.

The notes are also candid about a compromise. Leaving the responsibilities of both the boundary and the controller object to the CLI parser is described as not the best choice in terms of software architecture, but it was left as is due to the necessity of conformity to the original coder's intent. That is the right call for a book companion, and the wrong call for production code, and the project says which one it is.

Two more real fixes. Every PEP 8 E722 bare except violation was refactored with more specific exception clauses, and every place where the author opened a file or a database and left it open was refactored to use context managers.

And one thing was left alone on purpose. The use of global variables was untouched, in preference to producing heavy deviations from the original code's logic. The documentation calls that practice completely inadequate from the perspective of best practices, and leaves it anyway. The encoding comments, the # -*- coding: utf-8 -*- lines, were removed because UTF-8 is the default in Python 3.

The fixes that turned broken examples into working ones

The refactoring section lists the individual files where the conversion went beyond formatting, and those entries are the most useful part of the documentation for anyone deciding whether the code is worth running.

chapter01/vuln_scanner.py was structured so that a non-existent file raised an OSError at runtime, and the fix was to move the iteration control that calls check_vulns() into the conditional statement defined in the main function. In chapter02/nmap_scan.py the main function existed only to call optparse, so it was removed, and the iteration control was moved into the nmap_scan function, because in the original a new call to nmap was executed for each port scanned, which wasted cycles.

chapter02/ssh_brute.py imported pxssh as a standalone library when it is in fact a library under pexpect, and that bug led to a ModuleNotFoundError. It is corrected, and the code as printed in the book was littered with indentation errors that made it unusable, so it was brought to a functioning state. chapter02/ssh_command.py had its initialization moved into the __main__ scope, its shadowing variable names changed, and its prompt information decoded rather than left encoded.

chapter02/ssh_brutekey.py needed a set of pre-generated keys, and the book points the reader at a URL that now returns a 403 response, so a compressed archive of the keys was added to the chapter02 subdirectory. chapter02/ssh_botnet.py had an unused optparse import that was left hanging even in the printed book, and it was removed, with the botnet initialisation and its commands organised under the __main__ scope.

The largest job was chapter03/discover_networks.py, which had to be reimplemented rather than refactored. It used the deprecated mechanize library and interacted with the WiGLE service in a way that was no longer necessary once WiGLE provided an API, and the result was a standardised rewrite with a new wigle_print function.

Two chapters the maintainer calls historical

The notes are unusually honest about the parts that no longer work, and this is the section to read before you plan a study session.

Chapter 5 was refactored even though in practical terms it can be, at best, historical. The reasoning given is specific. Much of the functionality depends not only on very specific cases outlined as examples by the author, but on vulnerabilities that ceased to be realistic in the last few years, such as sniffing traffic from 802.11 wireless networks that still rely on the WEP security algorithm for traffic encryption, or that maintain no security at all. The other obstacle named is the absurd expectation that the reader acquires a specific UAV model in order to see that code at work.

The maintainer adds a mitigation rather than a dismissal: some utility can be extracted from the code related to the sniffing of probing and beacon requests, and that is where the effort of reading the chapter is not wasted.

Chapter 6 has a different problem. The code that makes reference to Google and Twitter proved too outdated in the way they handle current APIs to be worth the trouble of refactoring. The instruction to readers is that if you are interested in dealing with them, you should perform the refactoring and issue a pull request to the repository.

So the honest summary of this repository is that most chapters were modernised to a working state, one was reimplemented against a new API, and two are flagged as no longer practical. Anyone planning to learn from it should read the notes first, because the notes are more informative than the code itself.

A test suite with a coverage floor, in a project that is mostly a book

The pyproject.toml contains more engineering than you would expect from a code archive. The project is managed with poetry, is named violent-python3 at version 0.1.0, declares Python ^3.8, and lists the seven chapter packages explicitly.

The pytest configuration is the part worth copying. It sets a minimum pytest version of 7.0, points testpaths at the tests directory, and names the discovery patterns, then in addopts it runs with the -ra summary, strict markers, coverage over every chapter package, branch coverage, a term-missing report that skips covered lines, plus HTML and XML coverage output, and finally --cov-fail-under=80. The gate is therefore explicit: the run fails if coverage drops below 80 percent.

The markers are defined too, with unit for fast tests, integration for the slower ones, and slow for tests that can be deselected with -m "not slow". The dev dependencies are pytest, pytest-cov and pytest-mock, and the coverage configuration sets branch coverage on and omits the tests, the pycache directories and any virtual environment folders.

For a collection of scripts that were never meant to be a package, that is a significant amount of scaffolding, and it is the part of the repository with the longest useful life. The scripts themselves are pinned to a moment in time by the APIs they call, but the test harness would still work on a refactor.

The repository also has a CHANGELOG_ENTRY.md at the root, which suggests changes are tracked in the conventional changelog style.

No licence, no releases, and a maintainer who pushes occasionally

Two facts are missing that you should notice before you copy anything from this repository.

The first is the licence. The licence field for the project is not stated, and there is no licence file among the top level entries of the repository. For code that you found in a printed book, that is an understandable gap, and the underlying material is a published book rather than an open source project, but it means there is no permission here for you to reuse the code in your own work. Read the terms of the book itself if that matters to you.

The second is the release process. The repository has no GitHub releases, so there is no version to pin and no changelog of published artefacts. The version in pyproject.toml reads 0.1.0, which is the poetry package version rather than a release train.

The repository is not archived and the last push was on 2026-08-12. The pattern visible in the documentation is a maintainer who did a large amount of careful work in one pass, and who has since left the project to occasional fixes, which is the normal state of a book companion repository.

So the way to use this project is as a reference implementation rather than a dependency. Clone it, run the examples that the notes say will work, and use the refactoring decisions as a worked example of what a Python 2 to Python 3 migration looks like when you want to keep the original logic intact. The pip requirements file is there for that purpose, and the pytest configuration is there if you want to extend it.

Editorial conclusion

violent-python3 is worth adopting if you own a copy of Violent Python and want working code to follow along with, because the conversion fixes the parts that stopped running on Python 3 and leaves the teaching structure intact. It is the wrong tool if you want a maintained offensive security toolkit, because the project is a snapshot of a 2010s book and two of its seven chapters are documented as historical. Before you rely on it, read the notes on the chapter 5 and chapter 6 code, and note that the licence is not stated in the repository, there are no tagged releases, and the last push was on 2026-08-12, so treat it as reference material rather than a dependency.

Frequently asked questions

Official sources

1. EONRaider/violent-python3 on GitHub
2. Issues
3. README