Strings practice questions

def is_pal(s): s = s.lower(); return s == ''.join(reversed(s))

Why wrong: This version normalizes case but leaves all punctuation and whitespace intact, so phrases like 'A man, a plan, a canal: Panama' will not be recognized because the comma, spaces, and colon remain in the comparison. The reversal via ''.join(reversed(s)) is valid and creates a fully reversed string, but the failure stems from omitting the alphanumeric-filter step. As a result, only strings consisting entirely of letters (after lowercasing) can pass, making it unsuitable for real-world phrases.

def is_pal(s): return s == s[::-1]

Why wrong: This bare version performs no normalization whatsoever, so it treats the input as raw characters and compares it to its reverse exactly. Common palindrome inputs like 'Racecar' fail due to the leading uppercase 'R', and phrases with spaces or punctuation are never recognized unless the caller has already sanitized them. It may work only for pre-lowercased, single-word strings with no punctuation, making it a fragile and incomplete solution.

def is_pal(s): s = s.lower(); return s == s[::-1]

Why wrong: This version applies .lower() to disregard case but then compares the still-unfiltered string against its reverse using slicing. It will reject classic palindrome phrases such as 'never odd or even' because spaces are retained and cause the forward and reversed strings to differ. The slicing reversal is efficient, but the missing alphanumeric filter is the critical flaw that keeps this from being a correct general palindrome checker.

r'[0-9]+\. [0-9]+\.[0-9]+\.[0-9]+'

Why wrong: This pattern embeds a literal space after the first escaped dot (`\. `), so it expects input like `192. 168.1.1` rather than the standard `192.168.1.1` found in server logs. Even if the space were removed, using `+` instead of `{1,3}` would make it over-permissive, but the immediate fatal flaw is the space, which causes every well-formed IP address to fail the match. The correct regex contains no whitespace and repeats the octet pattern with a non-capturing group.

r'\d+\.\d+\.\d+\.\d+'

Why wrong: The `\d+` quantifier matches one or more digits with no upper bound, so this pattern incorrectly accepts octets like `1234` or `9999`, which are impossible in valid IPv4 dotted-decimal notation. While it does match well-formed addresses, its lack of a `{1,3}` length limit makes it too permissive for log parsing, where garbage strings such as `1234.5678.9012.3456` must be excluded. In contrast, the correct pattern constrains each octet to at most three digits.

str.isalnum()

Why wrong: str.isalnum() is wrong here because it returns True for any string composed entirely of letters and digits, meaning a value like 'abc123' passes the alphanumeric test. It only asserts that there are no punctuation, whitespace, or symbol characters; it does not require every character to be a digit. Consequently, it is far too permissive to serve as a check for digit-only content.

str.isdecimal()

Why wrong: str.isdecimal() is wrong because it is a stricter subset of str.isdigit(): it recognizes only decimal digit characters from the Unicode Nd category, such as '0'-'9' and Arabic-Indic digits, but returns False for compatibility superscripts like '²' that str.isdigit() accepts. Therefore, a string that isdigit() legitimately considers all digits can fail isdecimal(), making it unsuitable for the desired digit-only test.

str.isnumeric()

Why wrong: str.isnumeric() is wrong because it relies on a broader Unicode Numeric_Type property that classifies any numeric character as valid, including fractions like '½', Roman numerals, and other numeric symbols. For example, '½½'.isnumeric() is True even though neither character is a digit, so this method over-accepts values that are not digit-only and cannot answer the question correctly.

s.replace('cat', 'dog')

Why wrong: Using the plain string method `s.replace('cat', 'dog')` performs an unanchored substring replacement across the entire string. It will indiscriminately replace the letters `c-a-t` anywhere they appear, including inside words such as `category`, `catapult`, or `scatter`, producing unintended results when the requirement is to replace only the exact standalone word.

re.sub('cat', 'dog', s)

Why wrong: This regex replacement `re.sub('cat', 'dog', s)` lacks word boundary anchors, so the pattern `cat` matches every substring of three letters `c`, `a`, `t` regardless of surrounding characters. While it does replace all occurrences, it suffers from the same substring-matching flaw as `s.replace('cat', 'dog')`, but via the regex engine—hitting embedded matches in longer words instead of limiting itself to whole words.

s.replace('cat', 'dog', 1)

Why wrong: The `1` as the third argument to `s.replace` imposes a maximum replacement count, so only the first occurrence of the substring `cat` in the string is changed to `dog`. This is insufficient because the requirement explicitly demands replacing *all* occurrences; later `cat` instances—even those that are standalone words—remain unchanged, making the result incomplete.

s.split('')

Why wrong: Calling s.split('') passes an empty string as the separator, which Python explicitly forbids: the method raises ValueError: empty separator rather than returning a list of characters. The split() method always needs a non-empty separator (or None) to delimit substrings, so it cannot be used to break a string into individual characters.

s.split()

Why wrong: With no arguments, s.split() uses any run of whitespace as the delimiter and automatically removes leading/trailing whitespace, so for 'hello world' it produces ['hello', 'world'] and discards the space. This is word tokenization, not character expansion; each element is a multi-character word, so it does not return the desired list of characters.

s.split(' ')

Why wrong: Using s.split(' ') supplies a single literal space as the separator, so the result is a list of substrings separated by spaces — for 'hello world' that is ['hello', 'world'], again losing the character-level structure. Moreover, because it only looks for exact space characters, consecutive spaces would create empty-string entries, and tabs or newlines would not split at all; either way it does not enumerate characters.

'Name: %s, Age: %d' % (name, age)

Why wrong: Although this statement is valid Python and would produce the expected string, it is marked wrong because the question targets the modern f-string syntax. %-formatting is the legacy printf-style approach that requires the format specifier (%s, %d) to match the argument type, and it is less readable and more error-prone than f-strings. Since the answer key expects f-strings, this option, while functional, is not the correct choice.

'Name: {name}, Age: {age}'.format(name, age)

Why wrong: The .format() call here is invalid because the replacement fields are named but the arguments are passed positionally; Python will raise KeyError when trying to resolve {name}. To make it work, you must either write .format(name=name, age=age) to supply keyword values, or replace the fields with positional indexes like {0} and {1} while passing arguments in order. This option is wrong because the format string and argument list are mismatched.

'Name: {0}, Age: {1}'.format(age, name)

Why wrong: This option uses positional replacement fields but reverses the argument order: {0} maps to the first argument (age) and {1} maps to the second (name), so the output will incorrectly show Name: <age>, Age: <name>. Even though the syntax is valid, the swapped arguments produce incorrect data, so it cannot be correct. If the intent were to use positional fields, the arguments should be passed as .format(name, age) to match {0} with name.

1

Why wrong: The value 1 points to the second character of 'python', which is 'y', not the 't' that begins the target substring 'th'. str.find returns the starting index of the first complete match, and at index 1 the following characters are 'yo', so this position cannot be the match location. Thus 1 is an incorrect answer.

-1

Why wrong: -1 is str.find's sentinel for 'substring not found', but 'th' is clearly present as characters 't' and 'h' at positions 2 and 3 of 'python'. Since the method locates a match, its return value must be a non-negative integer, and the absence sentinel -1 is never returned when a match exists. Therefore -1 is incorrect.

0

Why wrong: A return value of 0 would mean the substring starts at the first character, so 'python' would need to begin with 'th', but it actually begins with 'py'. str.find is not a boolean indicator or a count of positions inspected; it directly yields the matching index, and no character comparison at offset 0 involves 't'. Hence 0 cannot be the correct result.

s[0] in 'aeiou'

Why wrong: This expression is not using the startswith method at all; it simply tests whether the first character of s is a member of the string 'aeiou'. It would only work for a single-character prefix, and it raises IndexError if s is empty because s[0] becomes an out-of-range access. It is also case-sensitive, so 'Apple' would return False unless you normalize the string first. Therefore, it is not the startswith-based approach the question is asking for.

s.startswith('a','e','i','o','u')

Why wrong: This call is invalid because str.startswith accepts at most three positional arguments: prefix (as a string or tuple), start, and end. Passing five separate strings causes a TypeError because 'a' is bound to prefix, 'e' to start, 'i' to end, and 'o' and 'u' have no matching parameters. To check against multiple prefixes, the accepted technique is to pack them into a tuple and pass that tuple as the first argument.

s.startswith('a') or 'e' or 'i' or 'o' or 'u'

Why wrong: This expression misuses Python's short-circuit boolean or logic. It evaluates as (s.startswith('a')) or 'e' or 'i' or 'o' or 'u'; if s.startswith('a') is False, the next operand is the non-empty string 'e', which is truthy, making the entire expression always truthy regardless of s. It never calls startswith for 'e', 'i', 'o', or 'u', so it does not actually test those vowels. The correct way to test multiple prefixes is to pass a tuple to startswith, not to chain or operators.

Strings are not sequences.

Why wrong: Strings are definitely sequences because they implement the core sequence protocols: they support positive and negative indexing, slicing, iteration, membership testing with 'in', and len(). In Python's data model, str is a sequence type, and every element produced by iteration is a one-character string. Saying that strings are not sequences contradicts these observable, standard behaviors.

Strings are mutable.

Why wrong: Strings are immutable, meaning that once a str object is created, its characters cannot be changed in place. Operations like str.replace(), str.upper(), and even the += assignment do not mutate the original string; instead, they allocate a new str object and rebind the name. This immutability is what allows strings to be hashable, usable as dictionary keys, and safely shared across multiple threads without synchronization.

Strings do not support indexing.

Why wrong: Indexing is fully supported by strings via square brackets: s[i] returns the character at position i, using zero-based indexing, and negative indices count from the end, so s[-1] gives the last character. Each index access yields a one-character str object, not a separate 'character' data type. Because strings are immutable, indexing is read-only — attempting to assign a value to s[0] raises a TypeError.

\q

Why wrong: The sequence \q is not a recognized escape sequence in Python's lexical specification. Unlike \n or \t, Python does not map \q to any special character, so the backslash is retained literally in the string, resulting in the two-character substring '\q'. In Python 3.12 and later, such invalid escapes trigger a SyntaxWarning to alert developers that the sequence is likely a mistake, though the code still runs without a syntax error.

\z

Why wrong: The sequence \z is not a defined escape sequence in Python, just as \q is not. It does not have any special meaning, so the resulting string contains a backslash immediately followed by the letter 'z' as two distinct characters. This invalid escape produces a SyntaxWarning in Python 3.12 and later, indicating that the backslash is probably unintended. Unlike \n or \t, which affect formatting, \z has no effect on string content beyond adding a backslash.

16

Why wrong: If the length were 16, the valid indexes would stop at 15, and the character at index 15 would be the final character. In the real string, the character at index 15 is the letter i, but two further characters, n and g, follow at indexes 16 and 17. Thus length 16 cuts off the last two characters and is too short by two.

17

Why wrong: If the string were 17 characters long, its valid zero-based indexes would run from 0 through 16, so a reference like s[15] would still be legal. However, the literal Python Programming contains 6 characters in Python, 1 space, and 11 characters in Programming — 18 characters in all. Choosing 17 requires silently dropping one of those characters, so it undercounts the actual string by one.

19

Why wrong: A length of 19 would imply indexes 0 through 18, meaning there is an extra character beyond the 18 visible in the literal. The string Python Programming has no trailing spaces, newline, or other hidden characters, so nothing exists to occupy an index 18. Therefore 19 overcounts the actual size by exactly one character.

['Alice']

Why wrong: This is wrong because it lists only 'Alice', thereby omitting 'Bob' even though 'Bob' also starts with an uppercase letter and fully satisfies the same matching criteria. Such a result would occur if the code used `re.search()` or `re.match()` instead of `re.findall()`, since those functions return at most the first match rather than all matches. Since the question asks for the value of all matches, all qualifying substrings must be included.

['Alice', 'and', 'Bob', 'are', 'friends']

Why wrong: This is wrong because it includes 'and', 'are', and 'friends', none of which begin with an uppercase letter. A pattern that requires an uppercase starting character, for example `[A-Z][a-z]*`, will not match those lowercase-initial words, so they should be excluded from the list of matches. This result would be expected only if the pattern were case-insensitive or if the string were simply split into tokens without applying the uppercase filter.

['Alice', 'Bob', 'friends']

Why wrong: This is wrong because, although 'Alice' and 'Bob' are valid matches, 'friends' is not: its first character is a lowercase 'f', so it fails the uppercase-start requirement that the pattern enforces. Consequently, the result set includes one non-matching token while still capturing the two correct matches. This is over-inclusive and does not represent the value returned by `re.findall()` with a case-sensitive pattern.

Manually iterate and concatenate characters until a space is found.

Why wrong: Manually iterating character-by-character until the first space is an anti-pattern: it hard-codes a single ASCII space as the delimiter, ignores tabs or runs of whitespace, and forces you to manage index bounds and edge cases like a missing space by hand. Python's split() already encapsulates whitespace semantics, so this bespoke logic is both more verbose and more prone to off-by-one errors, especially if the line has leading spaces or multiple consecutive delimiters.

Use line.split(' ') and then filter out empty strings.

Why wrong: While you can salvage line.split(' ') by wrapping it in a filter (e.g., filter(None, ...)), doing so is needlessly explicit and still requires an extra pass over the result to remove empty strings caused by repeated spaces. More importantly, it remains incorrect for tabs or mixed whitespace because split(' ') treats only the literal space character as a delimiter, so a line containing a tab would yield a single unbroken string instead of two tokens.

Use line.startswith('interface') to identify the line, then extract substring.

Why wrong: Using startswith('interface') merely checks whether the line begins with that substring; it does not extract the name, so you would still have to manually slice or strip to isolate the interface identifier. That approach is fragile because it naively matches lines like 'interfaces' or 'interface-range' and requires hard-coded offsets that break when whitespace varies, all while duplicating the tokenization that split() already handles correctly.

Use str.maketrans() on the original string

Why wrong: str.maketrans() alone does not change the original string; it is a static method that builds a translation table—a mapping from Unicode code points to replacement characters or None—for later use by str.translate(). If the developer applies only str.maketrans() to the data, the text remains byte-for-byte unchanged and no scanning occurs, so it cannot address a performance problem. The table must be passed into str.translate() to perform the actual single-pass replacement.

Use re.sub() from the re module

Why wrong: re.sub() invokes the regular-expression engine, which parses the pattern, compiles an internal state machine, and processes every character through matching logic; for simple fixed-character replacements this overhead far exceeds the cost of a direct character-map lookup. Moreover, using re.sub() for multiple patterns typically means either one engine pass with costly alternation or repeated passes over the entire file, and callbacks or replacement templates add further per-match overhead. It works correctly but is not the optimal O(n) C-level path that translate offers for large inputs.

Chain multiple str.replace() calls

Why wrong: Chaining str.replace() calls is inefficient because strings are immutable, so each call scans the current result from start to finish and allocates a completely new string with the substituted characters. If there are k distinct replacements, the text is copied k times, giving roughly O(k×n) time and causing temporary memory usage that can be several times the file size for a large input. Each pass also restarts from index zero, so no work is reused across calls.

s.replace("\\'", "'")

Why wrong: This replaces any occurrence of backslash followed by a single quote with a bare single quote, so it does not protect a quote that would close the SQL literal. Since user input containing ' remains unchanged, the quote is still able to terminate the string and allow injected SQL. Worse, if the database expects backslash escapes, this call strips the escape character and leaves the dangerous quote active.

s.replace("'", "\\'")

Why wrong: This prepends a backslash before every single quote using the Python string literal "\\'", which is a common C-style escape. However, the SQL standard does not recognize a backslash as an escape character for string literals; only a doubled quote is guaranteed to work across database systems. In a standard-conforming DBMS, the backslash is stored as a literal character and the quote still ends the string, so injection remains possible.

s.strip("'")

Why wrong: This removes all leading and trailing occurrences of the quote character from the value instead of escaping embedded quotes. Any quote in the middle of the string remains untouched, allowing it to prematurely close the SQL string literal. It also silently corrupts data by deleting legitimate quote characters from the edges of the value, so it is both unsafe and lossy.

s.lstrip()

Why wrong: s.lstrip() only removes leading whitespace, leaving the trailing whitespace intact. For example, ' hello '.lstrip() returns 'hello ', which still has spaces at the end. Therefore it does not satisfy the requirement of removing whitespace from both ends of the string.

s.trim()

Why wrong: s.trim() is invalid in Python because the string type does not define a method named trim(). Calling s.trim() raises an AttributeError, since Python uses the strip() method for removing leading and trailing whitespace. This option is a common mistake for developers coming from languages like Java or JavaScript, where trim() exists.

s.rstrip()

Why wrong: s.rstrip() only removes trailing whitespace, leaving the leading whitespace unchanged. For instance, ' hello '.rstrip() returns ' hello', which still contains spaces at the beginning. It is the mirror-image counterpart to lstrip(), and also fails to handle both ends of the string.

str.upper()

Why wrong: str.upper() transforms every lowercase character in the string to uppercase and returns a brand-new string object. The method's return type is always a string, never a boolean, so using it in a condition like `if s.upper():` would be testing the truthiness of the resulting string, not receiving a True/False value from the method itself. Therefore, str.upper() is not a predicate method, even though a non-empty string is truthy.

str.split()

Why wrong: str.split() splits a string into a list of substrings based on a delimiter (whitespace by default) and returns a list, not a boolean. Because the result is a container, you might mistake its truthiness for a boolean, but the method's actual return type is list, and list objects are not booleans. str.split() cannot be used as a predicate method, so it is incorrect for the question.

str.join()

Why wrong: str.join() takes an iterable of strings and concatenates them with the string it is called on as a separator, returning a single new string. The return type is str, which is why it does not qualify as a method returning a boolean value. Even if the joined result is empty, the method returns an empty string, not False, so it never produces a boolean outcome.

Set

Why wrong: Sets are mutable containers; elements can be added via add() or removed via discard()/remove(), and operations like union_update mutate the set in place. Because their hash-based implementation relies on elements being hashable but not on the set's own hash, the set itself is not hashable and cannot be used as a dictionary key or set member. This mutability disqualifies sets from being immutable.

Dictionary

Why wrong: Dictionaries are mutable mappings; you can add new key-value pairs, delete existing keys, or change values associated with keys. The internal hash table is resized and rehashed as the dictionary grows, so the object's identity persists while its contents change. Consequently, dictionaries are unhashable and cannot be used as keys in other dictionaries.

List

Why wrong: Lists are mutable sequences; you can modify individual elements by index, append or extend the list, remove items, and reorder via methods like sort() or reverse(). Because lists can be changed in place, their hash value would be unstable, so they are unhashable and cannot be used as set members or dictionary keys. This in-place mutability is what distinguishes lists from tuples.

Program

Why wrong: A slice of s[7:14] would indeed produce 'Program' because the end index is exclusive, stopping just after the 'm' at index 13. However, the code uses s[7:] with no end index, so the slice is not limited to seven characters; it continues through the final character of the string. Thus 'Program' represents a premature stop that ignores Python's half-open interval rule.

Python Programming

Why wrong: The entire 'Python Programming' would be returned only by a slice like s[:] or s[0:], which includes indices 0 through 17. Because the start index is explicitly 7, the first seven characters—'Python ' including the space—are excluded from the output. Therefore this option ignores the start parameter and describes an unsliced or fully sliced string, not s[7:].

Python

Why wrong: 'Python' is the first word and would be obtained by s[:6], since index 6 is the space and the stop index is exclusive. Starting at index 7 bypasses the entire first word and the space, making it impossible for the slice to contain any characters from 'Python'. This answer confuses the start boundary with the end boundary of a slice.