D493 Scripting and Programming - Applications is banner number ITSW 2135, three competency units in the School of Technology, and it is the Python course. The catalog describes it as an exploration of the Python language through its syntax, development environment and real-world problem solving, so the competency being built is applied: taking a stated problem and producing a program that solves it in idiomatic Python. One warning before anything else. The legacy course C867 prints the exact same title in the catalog and teaches C++, so the shared name hides two different languages and two different codes.
Why a Python course is graded differently than it is learned
Python is easy to start and hard to be graded well in, for a reason that catches nearly everyone. The language will accept a solution written as one long script with no functions, no error handling and every value a string, and it will produce correct output. Correct output is the floor. The aspects in an applications course are usually about how the solution is built, so a working program can miss most of them.
Real-world problem solving, the phrase the catalog uses, is the hinge. It means the problems arrive as descriptions rather than as specifications, and part of the competency is turning a description into requirements you can code against. Where does the data come from, what does a valid record look like, what should happen to a record that is not valid, and what does the user actually need to see at the end. Students who write down those four answers before opening an editor finish faster.
Idiomatic Python is the second grading axis. Comprehensions where a loop was building a list, a dictionary where a parallel list pairing was being maintained by hand, a with statement for anything that opens a file, and functions that do one thing and return rather than print. None of that is required to make the program run and all of it is what a reviewer reads as competence in this language specifically.
Modules, packages and libraries are named in the catalog description directly, which tells you the course expects you to reach beyond the standard set of built-ins. Knowing what to import, and being able to explain why the standard library already solved a problem you were about to write by hand, is a scored kind of knowledge.
Turning scored aspects into functions and a word budget
Aspects are scored one at a time, a 2 in each is what passes a task, and there is no compensation between them. So before writing anything, put the aspect list in one column and the artifact that will satisfy each aspect in the next, and make the artifact specific: a named function, a module, a test case, a paragraph.
Here is the budget arithmetic on a realistic shape. Say your rubric has six scored aspects and the written portion should land near 1,500 words. Six into 1,500 is 250 each. Now weight it. Two aspects are demonstrations, meaning the code proves them and the writing only has to say where, so drop those to 120 apiece and you have released 260 words. One aspect asks for an explanation of how you handled invalid input, which is the aspect most students underwrite, so raise it to 380. One asks you to justify your choice of data structures, another argument section, so raise it to 350. The remaining two hold at 250. The total is 1,470, and the two argument sections now carry half the document, which is where the scoring weight actually sits.
Write the aspect number in a comment above the function that satisfies it while you build. Strip the comments before submission if you like, but during the build they turn the rubric into a checklist you cannot forget to finish.
Working through the Python course?
Send the aspects and the problem statement. You get a module plan, a set of test cases to build against, and a model write-up in the register evaluators expect.
How to organize the program you hand in
| Piece | Job | What a weak version looks like |
|---|---|---|
| Entry point | Reads arguments or prompts, calls the workflow, exits cleanly | Two hundred lines of logic at module level |
| Data loading | Opens the source, parses records, returns structured data | Parsing mixed into the calculation loop |
| Validation | Decides what a good record is, reports what it rejected and why | A bare try block that swallows every exception |
| Core logic | Pure functions that take values and return values | Functions that print instead of returning |
| Presentation | Formats results exactly as the requirement stated | Raw structures printed straight to the console |
| Tests or trials | Named inputs with expected outputs, including bad input | One manual run described in a sentence |
The dividing line down that table is whether a function returns or prints. Functions that return can be tested, reused and explained. Functions that print can only be run.
Docstrings, test records and where citation belongs
Python has a documentation convention and using it is free credit. A docstring on every function stating what it takes, what it returns and what it raises turns your code into something a reader can assess without tracing it. Type hints do the same work in a different register and cost one line each. Both are strong signals of competence and neither changes what the program does.
Keep a record of what you tested. A short table of input, expected result and observed result, with at least one row for empty input and one for malformed input, answers robustness aspects with evidence rather than assertion. Screenshots of the terminal are acceptable evidence when they show the command and the full output, and weak when they are cropped to the one line you wanted to show.
Citation in a Python course usually means two things. Any third party package you import should be named with its version somewhere in the documentation, because an evaluator running your code needs to install it. And any algorithm or code pattern you adapted from a published source needs attribution in a comment. Where your program requires APA, the official language documentation and package documentation cite like any organizational web source, and forum answers are the weakest form of support you can offer for a technical claim.
What earns Competent and what triggers a return
There are no letter grades and no ordinary grade point average at WGU. Each aspect reads Competent or Not Competent and a task needs a 2 everywhere to pass, with free revision and resubmission when it does not. A return is a delay rather than a mark, and delay is the expensive part inside a six month flat rate term.
Programs that pass immediately handle the ugly input. They run from a clean directory with relative paths. They produce the exact output format the requirement described, including the number of decimal places if a number of decimal places was named. Their write-ups argue for the design instead of narrating it.
Returns cluster on three defects. Exception handling written as one broad catch that hides the failure instead of reporting it. Hardcoded absolute paths to a file on the author's own machine. And an aspect about data structure choice answered by describing what a dictionary is, when the question was why a dictionary rather than the alternative for this data.
Five habits that cost D493 students time
- Coding before writing the requirements down. A described problem has ambiguities. Resolve them on paper, in writing, and your assumptions become something you can defend in the document.
- One script, no functions. It runs. It also makes every aspect about structure, testability and reuse impossible to answer.
- Catching every exception in one place. Broad exception handling turns a specific failure into a silent one and directly contradicts robustness aspects.
- Reinventing what the standard library already does. Hand-rolled date parsing and hand-rolled CSV reading are both slower to write and weaker to defend than the module that exists.
- Assuming this is the same course as C867. The titles are identical in the catalog and the languages are not. D493 is Python under ITSW 2135, C867 is C++ under ITSW 2130.
How we work on this course
D493 support is structured around the artifact you will defend. Send the scored aspects and the problem statement and you get a module plan tied to each row, a test matrix to build against, a model written portion, and a review of your own code that explains defects instead of quietly replacing them. Where any part of your course is assessed by an objective assessment, we provide preparation only: concept notes, practice items and a plain go or wait read on your preassessment score. Objective assessments are proctored, we never sit or assist during an assessment, and we never ask for or use portal credentials.
Terms run six months at a flat rate, so the number of courses you close inside one term is what decides the effective price of each. An applications course is one of the ones worth planning properly rather than improvising, because the rework loop here is longer than in a reading course.
Three questions D493 students ask
Is D493 the same as ITSW 2135?
Why do D493 and C867 have the same title?
How much Python do I need before starting?
Where D493 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.