Coder Legion - Recent posts tagged syntax

Syntaxerror invalid syntax /Needs Improvement

Wed, 19 Aug 2026 05:47:33 +0000

The SyntaxError: invalid syntax is a common error encountered by Python developers. It occurs when the Python interpreter encounters an invalid syntax in the parsing stage of the source code. This error can be caused by a variety of human mistakes, such as forgetting to include quotes, missing commas, or misspelling keywords. In this tutorial, we will explore some common causes of this error and learn how to solve them.

Causes of the Error

No Quotes

One of the most common causes of the error is forgetting to include quotes around string literals. For example, the following code will produce this error:

print(Opensource Program)

Output

File "", line 1 print(Opensource Program) ^^^^^^^^^^^^^^^^^^
SyntaxError: invalid syntax.

Missing Commas

Another common cause of this error is forgetting to include a comma between items in a list or dictionary. Let's take a look at an example:

grades = {
'Biology': 54,
'Chemistry': 76
'Swahili': 65
}
print(f'Chemistry grade is {grades["Chemistry"]}.')

Output

File "", line 3 'chemisty':76 ^ SyntaxError: invalid syntax.
Perhaps you forgot a comma?

Misspelling Keywords

This error can also occur when misspelling a keyword, such as "for" or "if". Below is an example:

fro i in range(5):

Output

File "", line 1 fro i in range(5): ^ SyntaxError: invalid
syntax

Failing to Add a Keyword Altogether

This error can also occur when a keyword is missing altogether, such as "in" in a for loop.

for i range(5):

Output

File "", line 1 for i range(5): ^^^^^ SyntaxError: invalid
syntax

Using Invalid Syntax with Functions

This error can also occur when using invalid syntax with functions, such as using a semicolon instead of colons. The following code will produce this error:

def exFun();

Output

File "", line 1 def exFun(); ^ SyntaxError: expected ':'

Switching Python Versions

This error can also occur when switching between different versions of Python. For example, the following code will produce this error in Python 3:

print 'am a star in the ocean'

Output

File "", line 1 print 'am a star in the ocean'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SyntaxError: Missing parentheses in call to
'print'. Did you mean print(...)?

Missing Parenthesis

This error can occur when a parenthesis is missing in a function definition. For example, the following code will produce this error:

def my_function
print("Hello, world!")

Output

File "", line 1 def my_function ^ SyntaxError: expected '('

Wrong Indentation

This error can occur when the indentation of code is incorrect, such as in a function definition. For example, the following code will produce this error:

def my_function():
print("Hello, world!") print("This line is improperly indented.")

Output

File "", line 3 print("This line is improperly indented.")
IndentationError: unexpected indent

Unmatched Quotes

This error can occur when quotes are not closed properly in a string. Here is how it occurs:

x = "Hello, world!

Output

File "", line 1 x = "Hello, world! ^ SyntaxError:
unterminated string literal (detected at line 1)

Solution

To solve the "SyntaxError: invalid syntax" error, it is important to carefully review the code and check for any of the causes listed above.

Once the cause of the error has been identified, it can usually be easily corrected.

For example, if the error is caused by missing quotes, simply adding the missing quotes will solve the problem. If the error is caused by a missing comma, adding the missing comma will solve the problem. If the error is caused by a misspelled keyword, correcting the spelling will solve the problem. And so on.

It is also important to pay attention to the error message and the line number that is indicated, as this can provide a clue as to where the problem is located in the code.

In addition to reviewing and correcting the code, it is also important to ensure that the correct version of Python is being used. If the code was written in an older version of Python, it may not be compatible with a newer version and will need to be updated

FAQ

Can I use a code formatter to fix the "SyntaxError: invalid syntax" error?

Yes, using a code formatter can also be a helpful tool for identifying and correcting syntax errors in your code. A code formatter can automatically format your code according to a specific style guide, making it easier to spot and fix any invalid syntax.

Conclusion

While the SyntaxError: invalid syntax error is common especially since we as humans are prone to error, it is easy to solve . By understanding the causes of this error and learning how to solve it, you will be better equipped to troubleshoot and correct any issues that arise in your Python code.

References

Python's official documentation on the specific error message "SyntaxError: invalid syntax": https://docs.python.org/3/library/exceptions.html#SyntaxError

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Wed, 25 Feb 2026 17:55:52 +0000

Finally, it arrived! Well, not exactly here yet, but getting closer.

Overview

Divooka intends to make visual programming simple and accessible - the accessible part is achieved both through wide availability and the general-purpose nature of the programming system, but the simple part is what we spend lots of effort thinking hard trying to improve.

In the past, dealing with complex configuration takes the form of either "explosion" of arguments or dedicated Make XXX construction functions:

The problem arises due to direct exposure of all input arguments in visual programming. Both approach makes the canvas look busy, with the former a common approach in existing systems - using a struct sounds good on paper but still requires a complex looking construction node. This is a common problem in visual programming systems, below shows how it's done in Blender and ComfyUI.

You do get used to it after a while, but a busy looking canvas remains a busy-looking canvas. In Blender, you can sort of "collapse" a node:

As Blender is constantly improving, we can also now collapse property groups as shown in the earlier screenshot.

As a syntax purist and (unfortunately) very conscious about my working space, my eyes can't tolerate messiness. I kind of like how Houdini approaches this.

Essentially they offload all the complexity to the properties panel - this has the huge benefit of making everything look very clean. But the downside is Houdini rely heavily on scripting expressions (like Excel).

TerraGen and World Machine mixes the approach:

In both cases, connections represent flow of terrain data only and additional configurations are offloaded to property panels. In TerraGen especially, this allows those properties to be animated. The downside, once again, is whatever is offloaded to property panels are no longer programmable using nodes.

Our Approach

Our proposed solution for Divooka looks like this: fundamentally all properties remain as node inputs, but compound values (especially value types) should just allow "editing in place" through a property panel. If more complex programming is needed, one can easily fall back to Make XXX nodes again.

Future Work

There is still remaining work on type check, hierarchical compound types, arrays, and serialization, and also node rendering.

Conclusion

As usual with all the exciting language features of Divooka we intend to introduce, there are lots of details to take care of here.

Object-Oriented Configuration: Why TOML Is the Only Choice

Thu, 16 Oct 2025 21:34:35 +0000

Configuration languages shape how developers think about their systems. We chose TOML because it brings object-oriented thinking to configuration—concepts with operations, not nested metadata.

Configuration Languages Are Contentious

Developers have strong opinions about configuration formats. YAML advocates appreciate the clean look and minimal syntax. JSON supporters like the explicit structure and universal tooling. INI users value simplicity. Each choice involves tradeoffs, and those tradeoffs matter when you're configuring something that needs to be both human-readable and machine-reliable.

We've all been burned by configuration. YAML turns no into false. JSON strips trailing commas. INI has no nesting. This is cognitive overhead that distracts from what you're actually trying to configure.

What if configuration could think like code?

TOML Keeps Configuration Explicit

When we needed a configuration format for a system with complex validation rules and nested test cases, we evaluated the usual suspects. YAML would give us clean syntax but unpredictable parsing. JSON would be explicit but verbose and unforgiving. We needed something developers could read, write, and trust without fighting the format.

TOML stood out because it's explicitly declarative. What you write is what you get. No type coercion surprises, no invisible whitespace dependencies, no ambiguity about structure. But unlike JSON's verbosity, TOML has syntactic features that make configurations genuinely pleasant to write.

Dot Notation Without Explicit Nesting

Here's where TOML gets interesting. You can reference nested attributes using dot notation without having to explicitly define the parent structure first:

[eval]
description = "Test response accuracy"
type = "accuracy"
targets.agents = ["*"]
targets.tools = []

Notice targets.agents and targets.tools? We didn't have to write:

[eval]
description = "..."
type = "accuracy"

[eval.targets]
agents = ["*"]
tools = []

We just used dot notation inline. The structure is implicit but unambiguous. TOML creates the targets object automatically. This is a small thing that adds up when you're writing dozens of configs. It allows you to think in terms of attributes, not nesting depth. You are, however, free to construct the full nested structure if you prefer that style; in cases where we have this flexibility, we prioritize grouping similar concepts together for clarity.

Array of Tables: Repeatable Structures

Configuration often involves repeating the same structure with different values—test cases, server definitions, deployment targets. TOML's [[double bracket]] syntax creates arrays of tables cleanly:

[[eval.cases]]
prompt = "What is the capital of France?"
output.contains = "Paris"

[[eval.cases]]
prompt = "Explain what HTTP is"
output = {
  similar = "HTTP is a protocol for transferring data over the web.",
  threshold = 0.8
}

[[eval.cases]]
prompt = "Get weather data"
[eval.cases.output.schema]
temperature = { type = "float" }
condition = { type = "str" }
humidity = { type = "int" }

Each [[eval.cases]] declaration adds another item to the array. The structure is visually distinct. The repetition is obvious. You can scan through entries without getting lost in nesting.

Dot Notation as Behavior Modifiers

Here's where TOML's dot syntax enables something clever: you can use it to attach behavior modifiers to fields without introducing extra nesting. Instead of wrapping configuration in container objects, you extend the field name itself:

[[eval.cases]]
prompt = "What is the capital of France?"
output.contains = "Paris"

[[eval.cases]]
prompt = "What's the weather like?"
output.startswith = ["It's", "Currently", "The weather"]

[[eval.cases]]
prompt = "Extract the user's email address"
output.match = "\w+@\w+\.\w+"

Each suffix—.contains, .startswith, .match—changes how the value gets interpreted. The field name carries the semantic meaning. You're not nesting objects or adding metadata layers. You're using the key itself to express intent.

This is object-oriented thinking applied to configuration. You have a concept. You apply operations to it. It's how developers already think—now it's how configuration works. When someone sees output.contains, they immediately understand the pattern. They can intuit what other operations exist. Compare this to YAML or JSON where you'd need wrapper objects:

{
  "output": {
    "strategy": "contains",
    "value": "Paris"
  }
}

Or nested structures:

output:
  contains: "Paris"

TOML keeps it flat. The field name describes the behavior, and the value is just the value—no extra layers wrapping things up.

This pattern extends to schema definitions. Field validation rules attach directly to field names:

[[eval.cases]]
prompt = "Validate user profile"
[eval.cases.output.schema]
username = {
  type = "str",
  min_length = 3,
  max_length = 20
}
age = {
  type = "int",
  min = 13,
  max = 120
}

The validation constraints are readable and self-documenting. No wrapper objects, no indirection—just direct field definitions with their validation rules.

Inline Tables for Compact Structure

When configuration objects are small, TOML lets you write them inline:

latency = { max_ms = 3000 }
output = { similar = "expected text", threshold = 0.8 }
tools = [{ name = "add", args = [2, 2] }]

This is more readable than splitting every small object into its own [section] block, but it's still explicit. You can see exactly what's nested and what isn't.

What TOML Gets Right

Ecosystem adoption: Python's packaging ecosystem standardized on TOML. pyproject.toml replaced setup.py and became the official configuration format for Python projects. Poetry, Ruff, Black, pytest—all use TOML. When the Python community—known for pragmatism and careful design decisions—chooses TOML as the de facto standard, that's a signal worth paying attention to.

Explicit types: Strings need quotes. Numbers don't. Booleans are true or false, not yes/no/on/off. Dates are ISO 8601. No guessing.

Readable structure: Keys are unquoted unless they need special characters. Sections use [headers] that stand out visually. Comments use # like most scripting languages.

No invisible whitespace: Unlike YAML, indentation is cosmetic. Your config won't break because someone's editor uses tabs instead of spaces. We chose TOML knowing this would eliminate an entire category of bugs.

The Tradeoffs We Accepted

TOML isn't perfect. Deeply nested structures get verbose—you end up with long dotted paths or multiple [section.subsection.subsubsection] headers. If your config is a deeply nested tree, JSON or YAML might feel more natural.

TOML also doesn't support references or anchors like YAML does. You can't define a block once and reuse it elsewhere. For configurations where reusability matters more than explicitness, that's a real limitation.

And TOML is less universally supported than JSON. Most languages have libraries, but JSON is everywhere. If you need to parse configs in obscure environments or legacy systems, JSON's ubiquity wins.

Could TOML Be Better?

One pattern we noticed: when you're defining attributes deep inside an array of tables, you have to repeat the full path:

[[eval.cases]]
prompt = "Test prompt"
  [eval.cases.output.schema]
  field1 = { type = "str" }
  field2 = { type = "int" }

[[eval.cases]]
prompt = "Another test"
  [eval.cases.output.schema]
  field1 = { type = "str" }
  field2 = { type = "int" }

That [eval.cases.output.schema] is verbose. What if TOML supported a shorthand where a leading dot means "relative to the parent table"?

[[eval.cases]]
prompt = "Test prompt"
  [.output.schema]
  field1 = { type = "str" }
  field2 = { type = "int" }

This would indicate "relative to the last table-array item." It's a small syntactic feature that would reduce visual noise in configs with deep nesting under array items. Maybe that's worth exploring as a TOML extension, or maybe it introduces ambiguity that breaks the explicit clarity that makes TOML work. Worth considering.

Why Configuration Format Matters

Configuration gets read and written constantly. Developers write it when defining behavior. They read it when debugging. They scan it during code review. They modify it when requirements change. The format needs to be immediately legible and predictable.

This matters especially when the system being configured is already complex or non-deterministic. Configuration shouldn't add another layer of cognitive overhead—that's the problem we started with. TOML's declarative clarity lets developers focus on what they're configuring, not how the format will interpret it.

For Agent CI, TOML is our primary integration point. Evaluation configurations live in .agentci/evals/ and define all testing behavior without requiring changes to application code. This separation means you can add comprehensive evaluation coverage to existing agents without modifying prompts, tools, or deployment logic. The configuration format becomes the interface. It needs to be readable, maintainable, and expressive enough to handle complex validation rules. TOML gives us that.

The Broader Pattern

This choice reflects a larger philosophy: developer tools should be predictable. Surprises belong in what you're building, not in the tools you're using to build it.

YAML's type coercion might save a few characters, but it creates confusion when Norway becomes true because it matches a boolean alias. JSON's strict structure eliminates ambiguity but makes you count brackets and remember commas. TOML finds middle ground—explicit enough to be predictable, expressive enough to be pleasant.

Configuration languages shape how developers think about their systems. A good config format makes structure obvious, reduces ceremony, and doesn't surprise you. TOML does that.

If you're curious how these patterns play out in practice, the evaluation configs we've been using as examples are open source: github.com/Agent-CI/client-config. If this resonates with configuration frustrations you've hit—or if you've found other patterns that work—we want to hear about it. Configuration design is iterative. The more real-world usage we can learn from, the better.

Travis Dent is CEO of Agent CI, bringing systematic software development practices to AI agent development.

Topic 20250618: Procedural Context is More Learning (and Syntax) to Users

Wed, 18 Jun 2025 17:44:27 +0000

Overview

When people first open Divooka, they see a network of interconnected nodes where connections represent data flow.

Even someone who has never seen visual programming or Divooka before can read the titles of the nodes and input parameters and have a pretty good guess at what the program does.

Thus, a key to using Divooka (in the dataflow context) efficiently is understanding the execution runtime - what nodes are active, what the dependency tree is, and how caching works.

As someone who has been using Unreal Engine Blueprint since 2014, the concept of "execution flow" appears natural to me - but when showing this to new users, it became evident that it takes time to tune in and learn to read the diagrams.

We'll take a look at what procedural context is, then briefly analyze why that's the case.

The Procedural Constructs

The procedural context in Divooka provides many constructs that may be familiar to those from traditional programming languages.

An example is shown below:

Common Constructs

Conditional logic is done using the Branch node.

Loops are implemented using the Repeat node.

Iteration is done using the For Each node.

Functions are handled using the Execute Event and Custom Event nodes.

A switch-case structure is implemented using the Switch node.

(Pending image)

Unique Constructs

In addition, Divooka also offers constructs that are unique to it:

Sequence nodes are used to define multiple sequential steps.

Events are entry points defined by the framework (procedural context base type).

Implementation Note

Certain constructs are currently missing:

Break: to exit a loop prematurely.

Caveats of States

What's more, in procedural context there is the possibility of manipulating state - for example, incrementing a number to be used next time.

Thus, to use the procedural context effectively, users need to learn a good amount of "syntax": control flow, state handling, and more.

The Two Contexts

Given that all of the top 10 most popular programming languages support imperative/procedural programming as the default mode, one might expect this to be the most straightforward paradigm. In reality, that's not the case.

Use the dataflow context for data-centric operations, such as data transformations.

Use the procedural context for logic-centric operations, such as branching and conditional executions.

Unlike procedural context, when using dataflow context, users need to learn only a single syntax: connections represent data flows, and everything (almost) always executes - depending on node activation status. To follow the flow of a program is simply to follow the connections - there's no concern about branches or alternate execution paths.

Conclusion

The procedural context is more complex for several reasons:

Connections now represent both data and execution flow
Some nodes can interrupt, diverge from, or selectively execute downstream connections - requiring users to understand exact behaviors to make accurate predictions
There are many types of flow control nodes, each requiring learning
State is involved

Part of the reason Divooka started with the dataflow context was exactly to reduce this complexity. However, as programs become more complicated and procedural logic becomes involved, it's not possible to avoid procedural context - in fact, having it is often more convenient than not.

Users must make informed decisions about what to put into procedural context and what to offload to dataflow context.

References

Regular Expression - A Comprehensive Guide

Mon, 02 Jun 2025 23:03:31 +0000

(Originally posted on Methodox Wiki, visit the page for a live tester!)

Contents

Introduction
Live Tester
Practical Syntax
Comprehensive Reference
Conclusion

(Due to CoderLegion content length limit, section 4 is ommitted)

1. Introduction

Text - whether it’s log files, configuration data, user input, or documents - is everywhere in programming. From simple scripts to full-blown applications, developers frequently need to search, validate, extract, or transform pieces of text. While many IDEs and editors (like Notepad++, VS Code, or Sublime Text) offer basic find-and-replace functionality, they quickly reach their limits when you need to handle patterns, conditional logic, or repeated structures. That’s where regular expressions (regex) come in.

At its core, a regular expression is a compact, declarative way to describe a set of strings. Instead of manually scanning through text to find, say, all warning messages in a log, you can write a single pattern that matches timestamps, log levels, filenames, email addresses, URLs - you name it. Once you understand the fundamentals, regex can become one of the most powerful “weapons” in your developer toolbox.

Consider a typical log snippet:

2025-05-31 14:23:48 [Info] Starting application...
2025-05-31 14:23:50 [Info] Loading application data...
2025-05-31 14:23:55 [Warning] Missing font file: New Times Roman.
2025-05-31 14:24:22 [Info] The application has started, with 1 warning.
2025-05-31 14:25:01 [Error] Unhandled exception: NullReferenceException.

If you want to answer questions like:

“What warnings were emitted, and when?”
“Which lines contain error messages?”
“How many times did the application start?”

You could write a script in your favorite language that splits on spaces, checks tokens, and does string comparisons. But that quickly becomes tedious: parsing variability in timestamps, handling optional fields, or ignoring whitespace quirks can make your code fragile.

With a well-crafted regex, however, you can match on the entire log line, capture the timestamp, the log level, and the rest of the message - all in one pattern. More importantly, regex can handle any text-based format for which there’s a consistent structure: CSV files, HTML/XML tags, custom configuration formats, and so on.

By the end of this article, you will:

Understand the basic motivation behind regular expressions.
See practical syntax elements and examples for day-to-day tasks.
Have a handy reference that summarizes the most commonly used regex constructs.

Whether you’ve done a bit of “find and replace” in an editor, or you’ve written simple string processing code, this guide will bridge the gap and show you how to level up with regular expressions.

2. Live Tester

See original post.

3. Practical Syntax

In this section, we’ll cover the core building blocks of regex patterns. Each subsection introduces a concept, followed by real-world examples - some based on log processing, others on everyday tasks like validating email addresses or extracting numbers from text.

3.1 Literal Characters and Simple Matches

At the simplest level, a regex can be just literal characters. For example:

Pattern Error will match any occurrence of the substring “Error” in a text.
Pattern 2025-05-31 will match that exact date string.

However, real-world text rarely lines up perfectly. Log messages, for instance, include varying timestamps and different log levels. To match them in a generic way, you need metacharacters.

Key Point: Most characters in a regex match themselves literally, except for special metacharacters (like ., *, ?, \, etc.). To match a literal period, bracket, or other metacharacter, you must “escape” it with a backslash (\. to match a literal dot, \[ to match a literal left bracket, and so on).

3.2 Character Classes (`[]`) and Ranges

A character class is a bracketed set of characters that match exactly one character from the set. For example:

[AEIOU] matches any single uppercase vowel.
[0-9] matches any digit from 0 through 9.
[A-Za-z0-9_] matches a typical word character (letter, digit, or underscore).

Example 1: Matching a Four-Digit Year

Suppose you want to match any year between 1900 and 2099:

^(19|20)[0-9]{2}$

^ and $ are anchors (we’ll cover them in a moment).
(19|20) matches either “19” or “20”.
[0-9]{2} matches exactly two digits.
Altogether, this matches “1900” through “2099”.

Example 2: Extracting Log Levels

Given a log line like:

2025-05-31 14:23:55 [Warning] Missing font file: New Times Roman.

You can match the log level (Info, Warning, Error, etc.) with:

\[(Info|Warning|Error|Debug)\]

\[` and `\] match literal square brackets.
(Info|Warning|Error|Debug) matches one of those four words.

If you expect additional levels (e.g., Trace or Fatal), you can add them inside the parentheses:

\[(?:Info|Warning|Error|Debug|Trace|Fatal)\]

Here we’ve used (?: … ) to create a non-capturing group (we’ll talk about groups more in section 5).

3.3 Quantifiers: Repetition Control

Quantifiers specify how many times the preceding element should match. The most common quantifiers are:

* – Match zero or more times (greedy).
+ – Match one or more times (greedy).
? – Match zero or one time (makes the preceding token optional).
{n} – Match exactly n times.
{n,m} – Match between n and m times (inclusive).
{n,} – Match n or more times.

Example 3: Matching Timestamps

A timestamp like 2025-05-31 14:23:48 can be matched with:

\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}

\d is shorthand for [0-9].
\d{4} matches exactly four digits (the year).
- matches a literal hyphen.
\d{2} matches two digits (month and day).
\s+ matches one or more whitespace characters (space, tab).
\d{2}:\d{2}:\d{2} matches HH:MM:SS.

If you’re sure there’s exactly one space between date and time, you could use \s instead of \s+.

Example 4: Optional File Extension

Suppose you have filenames like report.txt or report. To match both, you could use:

^report(?:\.txt)?$

^ and $ ensure we match the entire string.
(?:\.txt)? means “optionally match ‘.txt’”.
- \. matches a literal dot.
- txt matches “txt”.
- The ? after the group makes it optional.

3.4 Anchors: Positioning Matches

Anchors specify positions in the text rather than actual characters:

^ – Start of the line/string.
$ – End of the line/string.
\b – Word boundary (between \w and \W).
\B – Non-word boundary.

Example 5: Lines Starting with “Error”

If you want to catch any line that begins with the word “Error” (as a standalone word), you can write:

^Error\b.*$

^Error ensures the line starts with “Error”.
\b asserts a word boundary so that “Errors” or “ErrorCode” are not matched.
.* matches the rest of the line (any character, zero or more times).
$ anchors the end of line.

3.5 Groups and Capturing

Parentheses ( and ) serve two main purposes:

Grouping: Treat multiple tokens as a single unit (often used with quantifiers or alternation).
Capturing: Store the text matched by that group for later retrieval (in code or in a replacement string).

Example 6: Capturing Timestamps and Levels

Given:

2025-05-31 14:23:55 [Warning] Missing font...

You might write:

^(\d{4}-\d{2}-\d{2})\s+(\d{2}:\d{2}:\d{2})\s+\[(Info|Warning|Error|Debug)\]\s+(.*)$

(\d{4}-\d{2}-\d{2}) captures the date (Group 1).
(\d{2}:\d{2}:\d{2}) captures the time (Group 2).
(Info|Warning|Error|Debug) captures the log level (Group 3).
(.*) captures the rest of the message (Group 4).
In most languages, after matching, you can extract Group 1, Group 2, etc.:
- e.g., in C#: match.Groups[1].Value gives the date.

If you want to group without capturing (for alternation or quantifier purposes), use (?: … ). For instance:

(?:Info|Warning|Error|Debug)

does not create a numbered backreference.

3.6 Common Metacharacters and Escape Sequences

Some of the most frequently used shorthand and metacharacters include:

. – Matches any character except newline (in most flavors; some allow a “dotall” mode to match newline).
\d – Digit (equivalent to [0-9]).
\D – Non-digit (equivalent to [^0-9]).
\w – Word character (letter, digit, underscore; [A-Za-z0-9_]).
\W – Non-word character (anything not in \w).
\s – Whitespace character (space, tab, newline, etc.).
\S – Non-whitespace character.
\t, \n, \r – Tab, newline, carriage return.

Tip: When writing regexes in code, you often need to escape backslashes. For instance, in C# you can use verbatim string literals (@"\d{4}-\d{2}-\d{2}") to avoid double escapes.

3.7 Practical Example: Extracting Email Addresses

Say you have a document or a configuration file and need to pull out all email addresses. A simple - but not fully RFC‑compliant - pattern is:

\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b

\b – Ensure we start at a word boundary.
[A-Za-z0-9._%+-]+ – One or more letters, digits, dots, underscores, percent signs, plus, or hyphens (the local part before the @).
@ – Literal “@” symbol.
[A-Za-z0-9.-]+ – One or more letters, digits, dots, or hyphens (domain).
\. – Literal dot.
[A-Za-z]{2,} – At least two letters for the TLD (e.g., “com”, “org”, “io”).
\b – End at a word boundary to prevent partial matches (so we don’t match trailing punctuation).

Testing It

Given:

Please contact *Emails are not allowed* or *Emails are not allowed* for more info. Alternatively, reach out to admin@localhost if testing locally.

*Emails are not allowed* matches.
*Emails are not allowed* matches.
admin@localhost does not match because localhost has no “. + two-or-more-letters” TLD.

3.8 Practical Example: Validating North American Phone Numbers

North American Numbering Plan (NANP) phone numbers often look like:

123-456-7890
(123) 456-7890
123.456.7890
+1 (123) 456-7890

A practical regex might be:

^(\+1\s?)?           # Optional country code +1 and a space
(?:\(\d{3}\)|\d{3})  # Either (123) or 123
[ .-]?               # Separator: space, dot, or hyphen (optional)
\d{3}                # Next three digits
[ .-]?               # Separator again (optional)
\d{4}$               # Last four digits

When compacted (and removing whitespace/comments):

^(\+1\s?)?(?:\(\d{3}\)|\d{3})[ .-]?\d{3}[ .-]?\d{4}$

^ and $ anchor the pattern to the entire string.
(\+1\s?)? – Optionally match “+1” followed by an optional space.
(?:$\d{3}$|\d{3}) – Either three digits inside parentheses or three digits without.
[ .-]? – Optionally match a space, a dot, or a hyphen.
\d{3} – Three digits.
[ .-]? – Separator again.
\d{4} – Four digits.

This pattern will match most common North American formats. By tweaking the groups and quantifiers, you can adapt it for other regions or stricter/looser rules.

3.9 Practical Example: Parsing Log Files

Returning to our log example, suppose you want to extract only the warning messages and their timestamps. You might apply a regex like:

^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[Warning\]\s+(.*)$

Group 1 captures the timestamp (2025-05-31 14:23:55).
Group 2 captures the message itself (Missing font file: New Times Roman.).

In most programming languages:

C# (using System.Text.RegularExpressions):

var pattern = @"^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[Warning\]\s+(.*)$";
var matches = Regex.Matches(logContents, pattern, RegexOptions.Multiline);
foreach (Match m in matches) {
    string timestamp = m.Groups[1].Value;
    string message   = m.Groups[2].Value;
    Console.WriteLine($"[{timestamp}] Warning: {message}");
}

Python (using the re module):

import re

pattern = r'^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[Warning\]\s+(.*)$'
for line in log_contents.splitlines():
    m = re.match(pattern, line)
    if m:
        timestamp = m.group(1)
        message   = m.group(2)
        print(f"[{timestamp}] Warning: {message}")

Even if you’ve only ever clicked “Replace” in an editor, these examples should give you a clear sense of how powerful a single regex can be. You define “match everything up until [Warning], then capture whatever comes next”, and you get exactly the data you want.

3.10 Testing and Debugging Regex

When you’re new to regex, it’s easy to overlook small mistakes - missing an escape, misplacing a quantifier, forgetting an anchor. Here are a few tips:

Use an Online Tester
Websites like regex101.com (PCRE, JavaScript, Python), RegexStorm (for .NET), or regexr.com let you type your pattern, paste test text, and see matches/highlights in real time.
Start Simple, Then Grow
If you need a complex pattern, start with a small piece. For instance, test just \d{4}-\d{2}-\d{2} on the date first, then add time, then add log level, etc.

Comment Your Patterns (When Supported)
Some languages/flavors support the “extended” or “free-spacing” mode, where you can add whitespace and # comments inside your regex:

(?x)            # Enable free-spacing mode
^               # Start of line
(\d{4}-\d{2}-\d{2})   # Group 1: Date
\s+             # One or more spaces
(\d{2}:\d{2}:\d{2})   # Group 2: Time
\s+             # One or more spaces
\[Warning\]     # Literal [Warning]
\s+             # One or more spaces
(.*)            # Group 3: Message text
$

This makes maintenance and future edits easier, especially for complex regexes.

Escape Early
If you need to match special characters (., *, ?, +, [, ], (, ), |, ^, $, \), always escape them with a backslash unless you explicitly want their special behavior.

4. Comprehensive Reference

Omitted due to content length limit. Visit Methodox Wiki for more.

5. Conclusion

By now you should have a solid grasp of:

Why regular expressions are invaluable for text processing.
How to write basic patterns: literals, character classes, quantifiers, anchors.
How to use groups, lookarounds, and backreferences for more advanced matching.
Which tokens and constructs constitute the “core” of most practical regexes.
Where to look when you need to refresh your memory (the reference section above, or a site like regexstorm.net/reference).

With a few dozen minutes of practice - writing regexes against sample text - you’ll rapidly gain confidence. Remember:

Test early and often in an online tester or your IDE’s “Find in Files” - seeing the matches in real time is far more enlightening than manually eyeballing code.
Readability matters. If the pattern becomes unreadable, use the free-spacing mode ((?x)) and add comments.
Keep it simple for common tasks. You rarely need the most arcane syntax; matching log levels, dates, email addresses, or basic CSV fields can usually be done with straightforward character classes and quantifiers.

Once you’ve mastered the basics, you can explore more advanced topics like:

Atomic grouping and possessive quantifiers (for performance-critical patterns).
Recursive patterns (in PCRE or some advanced flavors) to match nested constructs.
Conditional subpatterns (in PCRE or .NET) where you test if a group has matched before deciding the next part of the pattern.

But those are topics for another day. For now, lean on the examples and reference sheet above, and try applying regex to your next text‑processing challenge. In no time, you’ll find yourself thinking in patterns - and you won’t look back.

Congratulations on starting your pattern crafting journey! Keep this guide handy, bookmark your favorite regex tester, and remember that a well‑written regular expression often turns hours of manual parsing into a single line of elegant code.

References

RegStorm for C#

SQL - A Quick Intro

Mon, 02 Jun 2025 23:03:06 +0000

SQL - A Quick Intro

Overview

In this article, we’ll walk through the essentials of SQL using the SQLite dialect. We’ll start by creating a couple of sample tables and populating them with data. These tables will serve as the foundation for our examples in later sections. By the end of this overview, you will have a simple schema to work with and understand how to set the scene for common SQL operations.

-- Create a table for users
CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY,
    username TEXT NOT NULL,
    email TEXT NOT NULL,
    joined_date TEXT NOT NULL  -- stored as ISO-8601 strings in SQLite
);

-- Create a table for orders
CREATE TABLE IF NOT EXISTS orders (
    id INTEGER PRIMARY KEY,
    user_id INTEGER NOT NULL,
    product TEXT NOT NULL,
    quantity INTEGER NOT NULL,
    order_date TEXT NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

-- Insert sample data into users
INSERT INTO users (username, email, joined_date) VALUES
    ('alice', '*Emails are not allowed*', '2023-01-15'),
    ('bob', '*Emails are not allowed*', '2023-02-10'),
    ('carol', '*Emails are not allowed*', '2023-03-05');

-- Insert sample data into orders
INSERT INTO orders (user_id, product, quantity, order_date) VALUES
    (1, 'Keyboard', 2, '2023-04-01'),
    (1, 'Mouse', 1, '2023-04-07'),
    (2, 'Monitor', 1, '2023-04-15'),
    (3, 'Desk Lamp', 3, '2023-05-02'),
    (2, 'USB Cable', 5, '2023-05-10');

These two tables - users and orders - will be the basis for our queries. Feel free to run these statements in an SQLite environment (e.g., the sqlite3 CLI or any GUI tool) to experiment with the examples that follow.

Common Syntax

In this section, we’ll introduce the four most common SQL statements:

SELECT
UPDATE
DELETE
INSERT

We’ll focus on the typical usage patterns for each statement without covering every possible option or keyword. All SQL keywords are shown in uppercase by convention - this is a good practice. However, they are usually case-insensitive to the SQL engine.

1. SELECT

The SELECT statement is used to retrieve data from one or more tables. At its simplest, you specify the columns you want and the table from which to retrieve them:

SELECT id, username, email
FROM users;

If you want all columns, use *:

SELECT *
FROM orders;

You can filter results using WHERE:

SELECT username, email
FROM users
WHERE joined_date >= '2023-02-01';

To sort results, use ORDER BY:

SELECT id, product, quantity, order_date
FROM orders
WHERE quantity > 1
ORDER BY order_date DESC;

Limit the number of rows returned:

SELECT *
FROM orders
LIMIT 3;

Combine clauses:

SELECT username, email
FROM users
WHERE username LIKE 'a%'
ORDER BY joined_date;

The LIKE keyword here matches all names starting with an a.

2. UPDATE

Use UPDATE to modify existing rows. Always include a WHERE clause to avoid updating every row unintentionally:

-- Change Bob's email address
UPDATE users
SET email = '*Emails are not allowed*'
WHERE username = 'bob';

You can update multiple columns at once:

UPDATE users
SET email = '*Emails are not allowed*',
    joined_date = '2023-01-20'
WHERE username = 'alice';

It’s good practice to run a SELECT with the same WHERE first:

SELECT * FROM users WHERE username = 'alice';
-- Review the row, then:
UPDATE users
SET email = '*Emails are not allowed*'
WHERE username = 'alice';

3. DELETE

The DELETE statement removes rows from a table. Again, a WHERE clause is essential:

-- Delete Carol's record
DELETE FROM users
WHERE username = 'carol';

To delete all rows in a table (but keep the table structure):

DELETE FROM orders;

SQLite supports DELETE FROM table_name; without WHERE to remove every row. If you only want to remove specific rows:

DELETE FROM orders
WHERE order_date < '2023-04-01';

4. INSERT

INSERT adds new rows into a table. We already used this in the overview to populate users and orders. The basic syntax specifies columns and values:

INSERT INTO users (username, email, joined_date)
VALUES ('dave', '*Emails are not allowed*', '2023-06-01');

You can omit the column list if you supply values for every column in the exact order:

INSERT INTO orders VALUES (NULL, 4, 'Webcam', 2, '2023-06-02');
-- NULL for id since it's an AUTOINCREMENT primary key

If you want to insert from another table (a simple form of SELECT inside INSERT):

INSERT INTO orders (user_id, product, quantity, order_date)
SELECT id, 'Headphones', 1, '2023-06-05'
FROM users
WHERE username = 'bob';

Techniques

The examples above covered basic CRUD operations. In this section, we’ll focus on more advanced - but frequently used - SELECT patterns in SQLite, including implicit joins, explicit joins, Common Table Expressions (WITH), and subqueries. These techniques are particularly helpful when you need to combine data from multiple tables or derive aggregated results.

1. Implicit Join Using Multiple Tables in FROM

An implicit join (sometimes called a “comma join”) lists multiple tables in the FROM clause and specifies the join condition in WHERE. This style is concise but can be less clear for complex queries:

-- List every order along with the username of the user who placed it
SELECT u.username, o.product, o.quantity, o.order_date
FROM users u, orders o
WHERE u.id = o.user_id;

Here, u is an alias for users and o is an alias for orders. The join condition u.id = o.user_id ties rows in users to matching rows in orders.

You can add filters:

-- Only orders with quantity > 1
SELECT u.username, o.product, o.quantity
FROM users u, orders o
WHERE u.id = o.user_id
  AND o.quantity > 1
ORDER BY o.order_date;

2. Explicit Join Syntax (INNER JOIN, LEFT JOIN)

SQLite supports the standard explicit JOIN syntax, which is recommended for clarity:

-- INNER JOIN retrieves only matching rows
SELECT u.username, o.product, o.order_date
FROM users u
INNER JOIN orders o
    ON u.id = o.user_id;

For a left (or left outer) join, which returns all rows from the left table and matching rows (if any) from the right table:

-- List all users, including those who have not placed orders
SELECT u.username, o.product, o.order_date
FROM users u
LEFT JOIN orders o
    ON u.id = o.user_id;

If a user has no matching orders, the product and order_date columns will be NULL.

Multiple Joins
When you have more than two tables, chain the joins together:

-- Suppose we add a table for payment info
CREATE TABLE IF NOT EXISTS payments (
    id INTEGER PRIMARY KEY,
    order_id INTEGER NOT NULL,
    amount REAL NOT NULL,
    payment_date TEXT NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(id)
);

-- Sample data
INSERT INTO payments (order_id, amount, payment_date) VALUES
    (1, 49.98, '2023-04-02'),
    (2, 19.99, '2023-04-08'),
    (3, 149.99, '2023-04-16');

-- Query: find username, product, and payment amount for each paid order
SELECT u.username,
       o.product,
       p.amount,
       p.payment_date
FROM users u
INNER JOIN orders o
    ON u.id = o.user_id
INNER JOIN payments p
    ON o.id = p.order_id
ORDER BY p.payment_date;

3. WITH Clause (Common Table Expressions)

A Common Table Expression (CTE) defined by WITH allows you to create a temporary, named result set that you can reference in a subsequent query. This is useful for breaking complex queries into more readable pieces.

-- Example: Find users who have spent more than $50 in total
WITH user_totals AS (
    SELECT u.id AS user_id,
           u.username,
           SUM(p.amount) AS total_spent
    FROM users u
    INNER JOIN orders o
        ON u.id = o.user_id
    INNER JOIN payments p
        ON o.id = p.order_id
    GROUP BY u.id, u.username
)
SELECT username, total_spent
FROM user_totals
WHERE total_spent > 50;

In this example:

The CTE named user_totals aggregates total spending per user.
The outer SELECT filters users based on their aggregated spending.

CTEs can be recursive as well, but for a quick intro, focus on non-recursive CTEs.

4. Subqueries

Subqueries (also called inner queries or nested queries) are queries embedded inside other SQL statements. They can appear in the SELECT list, FROM clause, or WHERE clause.

4.1 Subquery in SELECT List

-- Add a column showing the number of orders each user has placed
SELECT u.username,
       u.email,
       (
           SELECT COUNT(*)
           FROM orders o
           WHERE o.user_id = u.id
       ) AS order_count
FROM users u;

The subquery (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) executes for each row in users.

4.2 Subquery in WHERE Clause

-- Find users who have never placed an order
SELECT username, email
FROM users
WHERE id NOT IN (
    SELECT DISTINCT user_id
    FROM orders
);

Alternatively, using NOT EXISTS:

SELECT username, email
FROM users u
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
);

4.3 Subquery in FROM Clause

-- Join users to a derived table that calculates order counts
SELECT t.username, t.order_count
FROM (
    SELECT u.id AS user_id,
           u.username,
           COUNT(o.id) AS order_count
    FROM users u
    LEFT JOIN orders o
        ON u.id = o.user_id
    GROUP BY u.id, u.username
) AS t
WHERE t.order_count >= 2;

Here, the subquery in the FROM clause (aliased as t) computes the number of orders per user. The outer query then filters on order_count.

5. Aggregation and GROUP BY

While technically a part of SELECT patterns, aggregation is so common that it merits a dedicated mention:

-- Total quantity ordered per product
SELECT product,
       SUM(quantity) AS total_quantity
FROM orders
GROUP BY product
ORDER BY total_quantity DESC;

HAVING

To filter on aggregated values, use HAVING rather than WHERE:

-- Only products with total quantity > 2
SELECT product,
       SUM(quantity) AS total_quantity
FROM orders
GROUP BY product
HAVING total_quantity > 2;

6. Putting It All Together

Let’s combine a few of these techniques into a more comprehensive example:

We want to list each user, their total number of orders, total quantity ordered, and their most recent order date.
Only include users who have placed at least one order.
Sort by total quantity descending.

WITH user_orders AS (
    SELECT u.id    AS user_id,
           u.username,
           COUNT(o.id)           AS order_count,
           SUM(o.quantity)       AS total_quantity,
           MAX(o.order_date)     AS last_order_date
    FROM users u
    INNER JOIN orders o
        ON u.id = o.user_id
    GROUP BY u.id, u.username
)
SELECT username,
       order_count,
       total_quantity,
       last_order_date
FROM user_orders
WHERE order_count >= 1
ORDER BY total_quantity DESC;

Explanation:

The CTE user_orders aggregates order-related metrics per user.
The outer query filters out users with zero orders and sorts the results.

Putting It into Practice

Here are a few additional examples and variations you might find useful in everyday data analysis with SQLite:

Top 3 Users by Total Spending
Combine payments and orders to rank users.

WITH spending AS (
    SELECT u.id         AS user_id,
           u.username,
           SUM(p.amount) AS total_spent
    FROM users u
    INNER JOIN orders o
        ON u.id = o.user_id
    INNER JOIN payments p
        ON o.id = p.order_id
    GROUP BY u.id, u.username
)
SELECT username, total_spent
FROM spending
ORDER BY total_spent DESC
LIMIT 3;

Find Orders with No Payment Records
Use a left join and look for NULL in the payment side.

SELECT o.id AS order_id,
       u.username,
       o.product,
       o.order_date
FROM orders o
LEFT JOIN payments p
    ON o.id = p.order_id
INNER JOIN users u
    ON o.user_id = u.id
WHERE p.id IS NULL;

Update via Subquery
Suppose we want to mark users who joined before a certain date as “legacy” in a new column. First, add a column:
```
ALTER TABLE users ADD COLUMN status TEXT DEFAULT 'active';

UPDATE users
SET status = 'legacy'
WHERE joined_date < '2023-02-01';
```
Delete Based on a Joined Condition
If you needed to delete payments for orders that were canceled (imagine a hypothetical orders.status = 'canceled' column), you could write:
```
DELETE FROM payments
WHERE order_id IN (
    SELECT id
    FROM orders
    WHERE status = 'canceled'
);
```

Nested CTEs
Chain multiple CTEs to break down a complex problem:

WITH recent_orders AS (
    SELECT *
    FROM orders
    WHERE order_date >= '2023-04-01'
),
recent_payments AS (
    SELECT o.id     AS order_id,
           o.user_id,
           p.amount,
           p.payment_date
    FROM recent_orders o
    INNER JOIN payments p
        ON o.id = p.order_id
)
SELECT u.username,
       SUM(rp.amount) AS recent_spending
FROM users u
INNER JOIN recent_payments rp
    ON u.id = rp.user_id
GROUP BY u.username
ORDER BY recent_spending DESC;

Conclusion

This article has introduced the basics of SQL using the SQLite dialect, focusing on the most common statements - SELECT, UPDATE, DELETE, and INSERT - as well as several useful SELECT techniques. You now have a schema with users, orders, and payments to experiment with, and you’ve seen how to:

Create tables and insert data.
Perform simple CRUD operations.
Join tables both implicitly and explicitly.
Use Common Table Expressions (WITH).
Write subqueries in various parts of a statement.
Aggregate data and filter with HAVING.

These examples should provide a solid foundation for everyday data analysis tasks. As you become more comfortable, you can explore advanced topics like window functions, triggers, and indexing strategies in SQLite.

Python Syntax

Tue, 05 Mar 2024 12:36:11 +0000

A. Introduction

Python syntax is the language grammar or structure of expressions or statements that are read by the Python parser before executing the full code. Python tokenizes the source code into keywords, operators, identifiers, etc to quickly determine if its syntax is correct. If there is an error, python would raise technically an exception called SyntaxError along with its equivalent error message. Through this error detection, it saves computer resources by holding the full code execution.

In subsequent sections, I will present example codes that illustrate correct syntax. Use of indentation to form a block of code, variable namings, basic data type usage, function and class definitions and others.

B. Indentation

Python uses indentations to define blocks of code. A block of code starts with indentation and ends with the first unindented line. The amount of indentation usually consists of four spaces and must be consistent throughout that block.

Bad indentation raises the IndentationError.

1. Indentation from if/else statement

country = input('Please enter your country: ')
if country == 'USA':
    print(f'Your beautiful country is {country}')
else:
    print(f'Your country is {country}')

2. Indentation from for loop

fruits.py

for fruit in [('mango', 'yellow'), ('apple', 'red'), ('avocado', 'green')]:
    print(fruit[0])
    print(f'color: {fruit[1]}')

Execute the script in the terminal

python fruits.py

output

mango
color: yellow
apple
color: red
avocado
color: green

3. Indentation from a function

Functions are used to organize code statements. All functions use an indentation. Here is an example of writing a correct syntax for functions.

def get_car_brand_names():
    cars = ['Toyota', 'Ford', 'Ferrari']
    new_car = 'Honda'
    cars.append(new_car)
    return cars

car_brands = get_car_brand_names()
print(car_brands)

4. More than one level of Indentation

Python can handle multiple levels of indentations. A good programming practice however is to limit it to two to maintain readability.

status.py

gender = 'male'
age = 24
if gender == 'male':
    if age >= 18:
        print('male adult')
    else:
        print('male teenager')
else:
    print('female')

5. Do not mix the number of spaces in indentations

This is bad.

if gender == 'male':
      if age >= 18:
        print('male adult')
    else:
        print('male teenager')
else:
      print('female')

6. Indentations from space and tab

Indentation can be created in two ways.

space - using the space bar on your keyboard
tab - using the tab key on your keyboard

Guide

To create an indentation by four spaces, just press your space bar 4 times.
For tab indentation you need to check your code editor how many spaces are set to create a single tab. In Python a tab is represented by a character \t.
Do not mix tab and space usage to avoid errors. If you are using spaces, always use it. And if you use tabs, always use it as well.
The most common and recommended way is to use a space and it should be 4 spaces.

C. Statement Termination

A statement or expression is terminated by a newline character '\n'. Or in your code editor, just use the enter key. It is non-printable.

1. Basic example

prog_lang_name = 'Python'

2. A newline character does not always mean the end of a statement

a. Parenthesis, Bracket and Brace

If there are parenthesis, bracket or brace the statement does not end there. It would continue to the next line. Line statement continuations are usually used if using a single is too long.

Note: the line that starts with # is just a comment. It does not affect the code logic.

# parenthesis
get_sum = (10 + 
    10 + 15)
print(get_sum)  # 35

# brace
city_list = ['Paris', 'Oslo', 'Bangkok', 'Beijing', 'Chicago', 'Amsterdam' ,
    'Tokyo', 'Brusells']

# bracket
sports_dict = {'basketball': 'ball game', 'cliff diving': 'diving', 'softball': 'bat-and-ball',
    'chess': 'board game'}

b. Backslash or \

If there is a backslash or \ at the end of the line, that means a continuation of the statement will continue in the next line.

get_sum = 10 + \
          10 + \
          15
print(get_sum)  # 35

D. Variables and Data Types

Variables are containers to hold data. Data types include integers, floating-point numbers, bool, strings, and more complex types like lists, dictionaries, objects, etc.

1. Variable Names

To write a statement or code expression, the variable name must be on the left-hand side of the equal sign and its intended value must be on the right-hand side of the equal sign.

num_computers = 25

Use the English alphabet to name a variable except keywords. It is a good programming practice to use the English letters in the alphabet and underscore _ characters to separate words to create a variable name.

Never use keywords as your variable names. Keywords are used internally by Python. They have special meanings in the language.

Let us generate keywords by python script.

import keyword

python_keywords = keyword.kwlist
print(python_keywords)

output

['False', 'None', 'True', 'and', 'as', 'assert', 'async', 'await',
 'break', 'class', 'continue', 'def', 'del', 'elif', 'else', 'except',
 'finally', 'for', 'from', 'global', 'if', 'import', 'in', 'is', 'lambda',
 'nonlocal', 'not', 'or', 'pass', 'raise', 'return', 'try', 'while', 'with', 'yield']

Caution: Do not use any of these keywords as a variable, function and class names.

Here are some examples of correct variable namings.

sky_color = 'blue'
planets = ['mars', 'saturn']
usd_oil_price_per_barrel = 78.5

Do not use a number as a character that starts the variable name and do not use special characters such question mark, etc. The following would result to a syntax error.

7elevel = 'good'
sun?shine = 'bright'

2. Data Types

a. Numeric and Boolean

Python has some data types such as integers, float, complex, boolean, fraction and decimal for numeric types. Here are some syntax how to use numeric types.

age = 24  # integer
price = 99.99  # float
cplx = 2 + 3j  # complex number
is_raining = False  # boolean can be either True or False

# Fraction
from fractions import Fraction
num = Fraction(75, 110)
print(num)  # 15/22

# Decimal
from decimal import Decimal
balance = Decimal(17.6)
print(balance)  # 17.60000000000000142108547152020037174224853515625

b. Sequence types

Python has some sequence types. They are list, range, tuple, binary and string data.

Do not forget to separate items inside the list, range and tuple with a comma. If you fail, it will generate a syntax error.

Correct usage to avoid syntax errors.

# list
game_stats = [15, 20, 18, 24]

# range
for r in range(1, 10, 2):
    print(r)

# tuple
population = (100, 600, 800)

For string and binary data, do not forget to enclose the value with single or double quotes.

# string
username = 'jupiter'
name = "romelo"

# binary, similar to string but with a `b` prefix.
address = b'xxx yyy zzz'

# syntax error in a string, notice the missing opening quote.
name = gina"

E. Control Flow Statements

The usual control flow statements uses if, elif, and else for conditional operations, and for and while loops for iteration.

Here are some examples of a correct syntax in control flow statements. The things to remember here are the colon or : after the if, elif, else, for and while lines; and the indentation which we already discussed in previous section.

1. The if, elif and else example

Give an award of 5000 if a team wins a game, 1000 for even and 100 for a loss.

result = 'win'
if result == 'win':
    award = 5000
elif result == 'even':
    award = 1000
else:
    award = 100
print(f'award: {award}')  # award: 1000

2. The for loop example

Loop thru the list and print each item.

for num in [5, 9, 1, 3]:
    print(num)

3. The while loop example

Print a number as long as it is above 10. Start at 20.

num = 20
while num > 10:
    print(num)
    num = num - 1

Tip: Remember to add a colon or `:` at the end of the line where there is a control flow keywords.

F. Functions and Classes

Function uses the def keyword followed by the function name and parentheses (). Python supports both procedural and object-oriented programming (OOP). Classes are defined using the class keyword.

1. A sample `add` function

# Define a function
def add(a, b):
    total = a + b
    return total

# Use it
result = add(4, 8)
print(result)  # 12

Things to remember to avoid syntax errors.

* Function starts with a def keyword.
* The word `add` is called an identifier or function name and must not be a keyword.
* The function name must be a single word or two or more words connected using the underscore `_`.
* We have two parameters in this example, `a` and `b`.
* The parameters are enclosed in parentheses.
* There is a colon `:` after the closing parenthesis.
* There is indentation.

2. A sample Country class

# Define a class
class Country:
    def __init__(self, name, capital):
        self.name = name
        self.capital = capital

    def info(self):
        print(f'The capital of {self.name} is {self.capital}.')

# Use it
country_info = Country('France', 'Paris')
country_info.info()  # The capital of France is Paris.

Things to remember to avoid syntax errors.

* A class definition starts with a class keyword followed by a name and ends with a colon `:`.
* The word Country is called the identifier or a class name.
* The rests are similar to the function definition.

G. Importing Modules

Modules can be libraries of functions, classes, or variables. You use the import statement to use a module.

Here is an example syntax for importing a module. Teachers want to calculate the students' grade average from a given list of grades. They use Python's module called statistics which has a function mean.

import statistics

grades = [85, 90, 89, 84]
average = statistics.mean(grades)
print(f'average: {average}')  # average: 87

H. Exception Handling

Python uses try-except blocks to handle exceptions. Code that might raise an exception is placed in the try block, and the handling of the exception is then implemented in the except block. when everything is done, codes in the finally block will be executed.

import random

rnum = random.randint(0, 9)
try:
    result = 5 / rnum

except ZeroDivisionError as err:
    print("Cannot divide by zero.")
    print(err)

except Exception as err:
    print("Unexpected error")
    print(err)

else:
    # without exception or error
    print("No exception occurred.")
    print(f'result: {result}')

finally:
    # This is always executed.
    print("finally block")

I. PEP 8

Python's coding style is guided by PEP 8, or Python Enhancement Proposal. It provides guidelines and best practices on how to format Python code. This will promote code consistency and readability. There is a lot that we can learn about Python's syntax as well.

J. Summary

The article provides a comprehensive guide to Python syntax, covering topics such as indentation, statement termination, variables, data types, control flow, functions, classes, module importing, exception handling, and adherence to PEP 8 coding standards.

Coder Legion - Recent posts tagged syntax

Syntaxerror invalid syntax /Needs Improvement

Table of Contents:

Causes of the Error

Solution

Conclusion

References

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Overview

Our Approach

Future Work

Conclusion

Object-Oriented Configuration: Why TOML Is the Only Choice

Configuration Languages Are Contentious

TOML Keeps Configuration Explicit

Dot Notation Without Explicit Nesting

Array of Tables: Repeatable Structures

Dot Notation as Behavior Modifiers

Inline Tables for Compact Structure

What TOML Gets Right

The Tradeoffs We Accepted

Could TOML Be Better?

Why Configuration Format Matters

The Broader Pattern

Topic 20250618: Procedural Context is More Learning (and Syntax) to Users

Overview

The Procedural Constructs

Common Constructs

Unique Constructs

Implementation Note

Caveats of States

The Two Contexts

Conclusion

References

Regular Expression - A Comprehensive Guide

1. Introduction

2. Live Tester

3. Practical Syntax

3.1 Literal Characters and Simple Matches

3.2 Character Classes ([]) and Ranges

Example 1: Matching a Four-Digit Year

Example 2: Extracting Log Levels

3.3 Quantifiers: Repetition Control

Example 3: Matching Timestamps

Example 4: Optional File Extension

3.4 Anchors: Positioning Matches

Example 5: Lines Starting with “Error”

3.5 Groups and Capturing

Example 6: Capturing Timestamps and Levels

3.6 Common Metacharacters and Escape Sequences

3.7 Practical Example: Extracting Email Addresses

Testing It

3.8 Practical Example: Validating North American Phone Numbers

3.9 Practical Example: Parsing Log Files

3.10 Testing and Debugging Regex

4. Comprehensive Reference

5. Conclusion

References

SQL - A Quick Intro

SQL - A Quick Intro

Overview

Common Syntax

1. SELECT

2. UPDATE

3. DELETE

4. INSERT

Techniques

1. Implicit Join Using Multiple Tables in FROM

2. Explicit Join Syntax (INNER JOIN, LEFT JOIN)

3. WITH Clause (Common Table Expressions)

4. Subqueries

4.1 Subquery in SELECT List

4.2 Subquery in WHERE Clause

4.3 Subquery in FROM Clause

5. Aggregation and GROUP BY

HAVING

6. Putting It All Together

Putting It into Practice

Conclusion

Python Syntax

3.2 Character Classes (`[]`) and Ranges

1. A sample `add` function