Your scheme may call it Introduction to Programming using Python (BCA01010T).
GNDU's BCA scheme for the 2025 batch starts programming with Python rather than C, which is a better decision than it looks. You spend the first semester learning to think about a problem instead of fighting a compiler, and the things that used to take a month — getting a string to reverse, getting input to work — take an afternoon.
The paper is BCA01010T with its lab as BCA01011L, and the lab is the part worth taking seriously. The scheme spells out how it is examined: you write the answer on the answer sheet, then implement the same thing on the computer, both halves are marked, and a viva runs one-to-one beside you about the code you are writing at that moment. That format is unforgiving of memorised programs and generous to anybody who has actually typed things in and broken them.
So the honest advice for this paper is the least glamorous: do the exercises. All of them, on a machine, with the interpreter open. There are about ten areas in the lab list and each is an evening's work. Ten evenings across a semester is not a heavy ask, and it is the difference between a viva that goes well and one that does not.
We teach this
This is not only a page about Python. It is a subject we teach in a classroom on Majitha Road, and a good share of every batch is college students taking it alongside their own semester. Bring your scheme and we cover what is on it.
What that means in practice: the whole syllabus gets covered rather than the parts that make a good demo, you write code on a machine instead of copying it into a file, and the lab work gets done here rather than the night before submission.
What we will not say is that this guarantees you marks or a job. We do not run placements and we do not promise results. Come and sit in a class, decide for yourself.
What each unit actually contains, and whether it is there because it matters or because it is on the paper. Unit order and numbering vary between GNDU, PTU and your batch’s scheme — check your own before you plan a revision week.
Using the Python interactive interpreter, getting familiar with an IDE, running a script from a file, and the difference between the two.
Trivial to learn and explicitly in the lab list, so it will come up. Know how to do the same thing in the shell and in a file.
Variables and dynamic typing, int, float, str and bool, type conversion, arithmetic, relational, logical, assignment, membership and identity operators, and input and output.
The base for everything else. The identity operator — is versus == — is a favourite viva question and catches most people.
if, else and elif; the while statement; for loops over a sequence and over range; loop patterns such as accumulation, search and counting; break, continue and the loop-else clause.
Loop patterns are named in the scheme, which means the examiner has them in mind. Be able to write a running total, a search and a counter without thinking.
Creating and indexing each, slicing, mutability, the list methods, tuple packing and unpacking, dictionary keys, values and items, nesting, and comprehensions.
The single biggest unit in the lab list and the most useful thing in the paper. Dictionaries in particular are what make Python worth using.
Defining functions, parameters and arguments, default and keyword arguments, return values including multiple returns, scope and the global statement, and lambda.
Passing parameters and returning values are called out by name in the scheme. Expect to be asked to write one and then explain what happens to a list passed into it.
Importing a module, the from-import form, aliasing, writing your own module and importing it, and the standard library modules math, random and datetime.
Writing your own module is the part people skip. It is two files and five minutes, and it is in the exercise list.
try and except, catching specific exception types, else and finally, raising an exception, and the common built-in exceptions.
Short unit, reliably examined, and genuinely useful the first time a program meets input it did not expect.
Opening files and the modes, reading whole files and line by line, writing and appending, the with statement, and organising data into and out of a file.
The scheme says 'reading, writing and organizing files', so expect a question that reads a file, does something with the contents and writes a result.
Creating an array, array operations against a plain list, creating a DataFrame, reading a CSV, selecting rows and columns, and simple aggregation.
The last item in the lab list and the one that opens a career rather than a paper. Do not treat it as an afterthought.
Revise all of it — the marks are the marks. But it is worth knowing which half of this paper you will still be using in two years, and which half exists because it is on the paper.
Not a guess paper, and not a promise about what will be set. These are the questions this subject keeps asking because they are the ones that test whether you understood it.
From teaching this paper, not from a list somewhere. Each of these costs marks every year.
Wrong — Preparing for this paper the way you would prepare for a theory paper.
Right — The scheme says you write the answer and then implement it on a computer, with a viva about the code you are writing. Reading prepares you for half of that. Type the exercises in — it is the only preparation that covers both halves.
Wrong — Using a mutable default argument, such as def add(item, items=[]).
Right — That list is created once and shared by every call, so the second call sees the first call's data. Use None as the default and create the list inside. This is a standard viva question because it catches people who learned the syntax without the model behind it.
Wrong — Assuming a list passed into a function is copied.
Right — It is not. The function receives a reference, so appending inside the function changes the caller's list. Integers and strings behave differently because they are immutable — which is the real answer to 'is Python call by value or call by reference'.
Wrong — Comparing strings or small numbers with is because it happened to work.
Right — == compares values, is compares identity. Small integers and short strings are cached by the interpreter, so is appears to work and then fails on larger values. Use == for values, is only for None.
These compile and run as written — type them in, break them, and fix them. Copying a program into a file you never ran is how a practical viva goes badly.
Covers files, dictionaries, string methods and sorting in one program — four items from the lab list at once.
def word_frequency(path):
counts = {}
with open(path, "r", encoding="utf-8") as f:
for line in f:
for word in line.lower().split():
word = word.strip(".,!?;:'\"()")
if word:
counts[word] = counts.get(word, 0) + 1
return counts
if __name__ == "__main__":
try:
counts = word_frequency("sample.txt")
except FileNotFoundError:
print("sample.txt not found - create it first")
else:
# Sort by count, highest first, then alphabetically for ties
for word, n in sorted(counts.items(), key=lambda kv: (-kv[1], kv[0]))[:10]:
print(f"{word:15} {n}")The exercise the scheme names directly, including the mutable-default trap the viva asks about.
def statistics(numbers):
"""Returns several values at once - a tuple, unpacked by the caller."""
total = sum(numbers)
return total, total / len(numbers), min(numbers), max(numbers)
def add_mark(mark, marks=None):
"""The correct pattern. A default of [] would be shared by every call."""
if marks is None:
marks = []
marks.append(mark)
return marks
def apply_bonus(marks, bonus=5):
"""A list argument is a reference: this changes the caller's list."""
for i in range(len(marks)):
marks[i] = min(marks[i] + bonus, 100)
marks = [78, 85, 61, 92]
total, average, lowest, highest = statistics(marks)
print(f"total={total} average={average:.2f} low={lowest} high={highest}")
apply_bonus(marks)
print("after bonus:", marks) # the original list has changed
print(add_mark(70)) # [70]
print(add_mark(80)) # [80], not [70, 80]The last item in the lab list. Creates data rather than needing a file, so it runs anywhere.
import numpy as np
import pandas as pd
# NumPy: an array does arithmetic on every element at once
marks = np.array([78, 85, 61, 92, 55])
print("raw :", marks)
print("scaled :", marks * 1.1)
print("mean :", marks.mean(), " max:", marks.max())
# pandas: a DataFrame is a table with named columns
df = pd.DataFrame({
"roll_no": [101, 102, 103, 104, 105],
"name": ["Simran", "Harjot", "Navdeep", "Gurleen", "Arshdeep"],
"city": ["Amritsar", "Tarn Taran", "Amritsar", "Batala", "Amritsar"],
"marks": [78, 85, 61, 92, 55],
})
print("\nFirst three rows:")
print(df.head(3))
print("\nStudents who scored above 70:")
print(df[df["marks"] > 70][["name", "marks"]])
print("\nAverage marks per city:")
print(df.groupby("city")["marks"].mean().round(1))
# Writing it back out, which is the other half of 'organizing files'
df.to_csv("students.csv", index=False)
print("\nWritten to students.csv")Not model answers to reproduce. What the examiner is checking for, and where the marks actually sit in each one.
A list is an ordered, mutable sequence written in square brackets and indexed by position. A tuple is ordered and immutable, written in round brackets, which makes it usable as a dictionary key and safe to pass around. A dictionary is a mapping from keys to values in curly brackets, looked up by key rather than by position, and its keys must be immutable. Give one line of code creating each and one operation on each — the examiner is checking you have used them, not that you can recite three definitions. Add why immutability matters, and the answer is complete.
== asks whether two objects have the same value; is asks whether they are the same object in memory. For small integers and short strings the interpreter caches objects, so is appears to give the same answer as == and then stops doing so for larger values — which is exactly why the question is set. The rule to state: use == for comparing values, and is only for None. Demonstrating it with two lists holding identical contents makes the point in three lines.
try holds the code that may fail; except catches a specific exception type and handles it; else runs only if nothing was raised; finally runs either way and is where cleanup goes. Catch specific exceptions rather than a bare except, which would also swallow a keyboard interrupt. Use a file that may not exist or an int() on bad input as the example, and show all four clauses in one program — an answer with try and except alone usually loses the marks for else and finally.
Neither, strictly — it passes a reference to the object, and what you observe depends on whether the object is mutable. Pass a list and append inside the function and the caller sees the change. Pass an integer or a string and reassign it inside the function and the caller sees nothing, because reassignment binds the local name to a new object rather than altering the old one. The phrase for it is call by object reference. Show both cases in one short program; that is what turns a memorised phrase into a full answer.
Your paper stops somewhere, and a job interview does not. If you want the version of this subject that goes further than the scheme asks for, there is a full course for it.