I'm in regular contact with a few folks who seem remarkably incurious. Seem. Perhaps they're curious about something other than software. I don't know. But I do know they're remarkably incurious about software. And are trying to write Python applications. I know some people don't sail out of sight of …

Whew. Chapter rewrites finished. Technical reviews in process. Things are going pretty well. Look for Packt to publish this in the next few months. Details will be posted. Now. For LinkedIn Learning course recordings.

Here's a popular idea.

... a COBOL-to-X translator, where X is a more-modern programming language ...

This is a noble aspiration.

In principle -- down deep -- all programming can be reduced to an idealized Turing Machine.

This means that we *should* be able to locate all the state changes in a given spaghetti-bowl …

Why didn't COBOL evolve more successfully?

FORTRAN, OTOH, has survived precisely because it--and more importantly, related tools, esp compilers--has evolved to solve/overcome many (certainly not all!) of the sorts of pain-points you describe, while retaining the significant performance edge that (IMHO, ICBW) prevents challengers …

https://twitter.com/audreywatters/status/1246609613203505152

The tweet has since been deleted. Here's the old text

At this point, we're closing in on 9/13 (70%) of the way through the 2nd edition rewrite.

Important changes.

1. Type Hints
2. Type Hints
3. Type Hints

First.

Every single class, method, or function has to be changed to add hints. Every. Single. One. This is kind of huge. The book …

I made some bad decisions when I wrote this a few years ago: https://github.com/slott56/Stingray-Reader. Really bad. And. Recently, I've burdened myself with conflicting goals. Ugh.

I need to upgrade to Python 3.8, and add type hints. This exposed somes badness.

See Stingray Reader Rewrite for …

This seemed like an interesting problem. I hope this isn't someone's take-home homework or an interview question. It seemed organic enough when I found out about it.

Given a document like this...

doc = {
    "key": "the key",
    "tag1": ["list", "of", "values"],
    "tag2": ["another", "list", "here"],
    "tag3": ["lorem", "ipsum", "dolor"],
}

We want …

Using the clear() method of a dict isn't *wrong*. But. The reasons have to be investigated. I got a question about this code not working "properly." ("Properly"? Seems too vague to be useful.)

Here's a summary of the example.

final_list = []
temp_dict = {}
for obj in some_source:
    cool_function(obj, temp_dict)
    final_list.append …

See {filename}/blog/2020/01/2020_01_26-stingrayreader_upgrade.rst

This drifted into some serious rethinking of bad design decisions. (If someone else did this, I'd call it weak, and suggest improvements. It was me. It was bad. I'm a bad programmer and I feel bad about it.)

An an example, there's this …