D335 Introduction to Programming in Python is banner number ITSW 3126 and three competency units in the School of Technology. The catalog describes it as building Python scripting skills including control flow with functions and loops, and use of packages, modules and libraries. Those are two distinct competencies sitting in one course. The first is writing your own logic well. The second is knowing when not to, because a language with a large standard library rewards the developer who recognizes that the problem in front of them was solved and shipped years ago.
Your logic, and the library you did not write
The first half of this course is control flow expressed through functions and loops, and the standard that gets scored is decomposition. A script that runs top to bottom in one continuous block can be entirely correct and still fail an aspect about program structure, because nothing in it is a unit that can be named, tested or reused. Functions are the visible evidence that the problem was broken apart before it was solved.
Good decomposition has a testable definition you can apply to your own draft. Each function does one thing you could describe in a short sentence with no and in it. Each returns a value rather than printing one, so the caller decides what happens to the result. Parameters carry what the function needs instead of the function reaching out to values defined elsewhere. Apply those three tests and most structural aspects are answered before you write a word of documentation.
The second half is the ecosystem. Modules, packages and libraries appear in the catalog description because Python's power is largely borrowed, and using it well is a competency in itself. Knowing that the standard library reads structured files, handles dates, does math, generates randomness and parses arguments saves you from writing fragile versions of all five. Knowing how to install and import a third party package, and how to record which one you used so somebody else can run your code, is the practical skill underneath.
Splitting your own code into modules is the bridge between the halves. Once functions exist, grouping related ones into a module and importing them is a small step, and it is the step that turns a script into something a second person could work on.
From scored aspects to a function list and a word budget
WGU scores every rubric aspect separately and needs a 2 in each one to pass a task, so an aspect list is really a checklist of things that must exist somewhere findable. In a scripting course the productive move is to write the function you will build next to each aspect before you build anything.
Here is the budget worked. Suppose your rubric has five scored aspects and the accompanying write-up should reach about 800 words. Five into 800 is 160 each. Sort them. Two aspects are structural demonstrations, satisfied by the code, so 90 words each of pointer text naming the module and function, which is 180 and releases about 140. One aspect asks you to justify your use of a library or module rather than writing the logic yourself, which is the argument the catalog description implies, so give it 280. One asks how the script handles bad input, 220. The last is a summary at 130. That is 180 plus 280 plus 220 plus 130, or 810, which is on target with more than half the words on two argument sections.
Do the same for the imports. List every module you import and write one line saying what it does for you. If you cannot fill that line, the import is decorative and should be removed, and if two lines say the same thing, one of the imports is redundant.
Working on the D335 script?
Send the aspects and the script requirements. You get a function breakdown, a module plan and a model write-up in the register evaluators expect.
Build it yourself, or import it: a decision table
The judgment the catalog description points at is when to write logic and when to reach for what exists. This table gives the shape of that judgment for the kinds of task a first Python course sets.
| Job in your script | Reach for a module | Write it yourself |
|---|---|---|
| Reading structured text files | Yes, the standard library handles quoting and delimiters correctly | Only if the format is genuinely custom |
| Dates and time arithmetic | Always, calendars are full of exceptions | Never, this is where hand-written code fails |
| Randomness | Yes, and say whether it needs to be reproducible | No |
| Command line arguments | Yes, argument parsing gives help output for free | Only for a single positional argument |
| Business rules from the requirement | No | Yes, this is the logic being graded |
| Validation of your own data | Sometimes, for formats with a standard | Usually, since the rules come from the requirement |
| Sorting and searching | Yes for ordinary cases, with a key function | Only if an aspect asks you to implement the algorithm |
The last row is the exception that matters. If an aspect asks you to demonstrate an algorithm, importing a function that does it defeats the aspect, so read the wording before you optimize.
Docstrings, requirements files and honest attribution
Documentation in Python has a convention and following it is free credit. A docstring at the top of each module saying what it is for, and one on each function saying what it takes and returns, converts your script into something readable without tracing. Comments then handle the why: why this threshold, why this order, why this edge case is treated differently.
Record the environment. Name the Python version you developed against and list any third party packages with their versions, either in a requirements file or in your documentation. An evaluator who cannot install what your script imports cannot run your script, and that is a preventable failure with a two line fix.
On sources, cite what defines behavior. The official Python documentation is the authority for the standard library and cites in APA as an organizational web source when your program requires it. Package documentation cites the same way. Any code adapted from a published example gets a comment naming the source, and you should be able to explain it line by line, since aspects asking you to justify a choice are unanswerable about code you did not reason through.
What passes first time in this course
Work at WGU is Competent or Not Competent, with no letter grades and no ordinary grade point average behind them. Performance assessment work that misses an aspect returns with evaluator comments and can be revised and resubmitted without penalty, so the real cost of a return is days inside a six month flat rate term.
Scripts that clear the first time are decomposed into named functions, run from a clean directory with relative paths, handle the empty and malformed cases the requirement implies, and produce output in the exact format the requirement described. Their documentation names functions rather than describing the program in general terms.
Returns are consistent in a first Python course. A single top-to-bottom script with no functions. A path pointing at a folder on the author's own machine. Output that is correct in value and wrong in format because the requirement asked for two decimal places. And an aspect about libraries answered with a list of imports rather than a reason for any of them.
Six time sinks in D335
- Writing everything before running anything. Run each function as you finish it. Debugging one new function is a minute; debugging two hundred lines at once is an evening.
- Functions that print. A function that prints instead of returning cannot be tested or reused, and it makes structural aspects hard to answer.
- Reaching for a heavy package to do something the standard library does. Extra dependencies are extra reasons your code will not run on somebody else's machine.
- Ignoring indentation errors as noise. In Python, indentation is structure. A block that runs inside a loop instead of after it is a logic bug, not a formatting one.
- Mutable default arguments. A list or dictionary as a default value is shared between calls, which produces a bug that looks like magic and is documented behavior.
- Skipping the environment note. Version and package list, two lines, prevents the one failure mode you cannot fix after submission.
How we work on this course
Support for D335 is structure and argument. Send the scored aspects and the requirements and you get a function breakdown mapped to each row, a build-or-import decision for every job in the script, a test list including the ugly inputs, and a model write-up in the register WGU evaluators expect. Code review names the defect and explains it rather than replacing your file, because a justification aspect is only answerable about decisions you made. Where a section is assessed by an objective assessment, we prepare only, and objective assessments are proctored: we never sit one, never assist during one, and never ask for or touch portal credentials.
Terms are six months at a flat rate, so a scripting course closed in three weeks instead of nine leaves room for the course that turns out to be hard. Python is usually one of the ones you can move fast on with a plan.
Three questions D335 students ask
Is D335 the same as ITSW 3126?
How is D335 different from D493?
Can I use a third party package instead of writing the logic?
Where D335 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.