Perl.CodeCompared.To/Python

Python needs no use v5.38; preamble and no trailing semicolon — a newline ends a statement, just as it does in Perl once the semicolon is dropped mentally. print() is the direct equivalent of Perl's say: it appends a trailing newline by default. Python has no distinct "modern mode" to opt into; the behavior Perl gates behind use v5.38 is simply how Python always works.

Both languages are interpreted with no separate compile step, so python3 hello.py and perl hello.pl feel identical to run. Python ships a full interactive REPL (the bare python3 command) for trying expressions one at a time, similar to Perl programmers reaching for a one-liner (perl -e) or the separate Devel::REPL module — Python's REPL is built in and does not require an extra install.

Both languages use # for single-line comments, and neither has a genuine multi-line comment construct. Perl's workaround is the Pod =begin/=end markers, borrowed from its documentation tooling; Python's closest workaround is an unassigned triple-quoted string, which is really a docstring convention rather than a comment. Consecutive # lines remain the idiomatic style for multi-line commentary in both languages.

Python's print() is exactly Perl's say — both append a trailing newline automatically, and both accept a bare number without any explicit stringification. Suppressing the newline in Python requires the end="" keyword argument, the mirror image of Perl's print (no newline) versus say (with newline) being two separate functions.

Python has no sigils at all: a string, a list, and a dict are all referenced with a bare, unpunctuated name — the type is determined by what the variable holds, not by a leading $, @, or %. This eliminates an entire category of Perl syntax rules (element access uses $ even on an @array, interpolation context changes the sigil, and so on): in Python the name never changes no matter how the value is used.

Perl's my creates a genuinely new lexical variable scoped to the enclosing block, so an inner my $count shadows an outer one. Python has no declaration keyword for local variables — a bare assignment either creates or reassigns a variable in the current scope, and if/while/for blocks do not introduce a new scope the way a Perl { } block does. Only def, class, and lambdas create new scopes in Python.

Both languages let a variable hold a value of any type at any time — neither requires a type declaration. The difference is uniformity: in Perl, a scalar variable can hold a number, a string, or a reference, but an @array variable can never hold a hash without going through a reference. In Python, one bare name can be reassigned freely between an integer, a string, or a list, because every value — even a list or a dict — is just an object referenced by that name.

Perl's use constant pragma actually enforces immutability — reassigning a Perl constant is a compile error. Python has no constant-declaring syntax whatsoever: SCREAMING_SNAKE_CASE is purely a naming convention that tells other programmers "please do not reassign this," but the interpreter does nothing to stop a later MAX_RETRIES = 5 from silently succeeding. This is a genuine step down in strictness from Perl's pragma-enforced constants.

Python's truthiness diverges from Perl in one sharp, easy-to-miss way: Perl treats the exact string "0" as falsy, but Python does not — any non-empty string is truthy in Python, including "0". Python instead extends falsiness to every empty collection ([], {}, (), set()), which Perl has no unified equivalent for since Perl has no single "empty collection" concept spanning arrays and hashes. A Perl programmer porting a if ($value) check that relies on "0" being falsy will get the wrong answer in Python without adjustment.

Both languages support list-style destructuring assignment and the classic temp-free swap idiom. Python's starred name *tail plays exactly the same role as Perl's @tail soaking up the remaining elements — one of the closer syntactic matches between the two languages — though Python needs no explicit parentheses around the left-hand side and no sigils to distinguish which name captures the rest.

Perl interpolates a bare $name directly inside a double-quoted string, but embedding an arbitrary expression like age + 1 requires the awkward @{[ expression ]} trick. Python's f-strings (f"...", introduced in 3.6) require an explicit f prefix — ordinary "..." strings do not interpolate at all — but once prefixed, {expression} accepts any expression directly, with no special-casing needed, much like Ruby's #{}.

Perl's string operations are mostly standalone functions — length($text), uc($text), index($text, ...) — that take the string as an argument, and there is no built-in trim function at all (trimming needs a manual regex substitution). Python's str type has built-in methods called directly on the string object: text.strip(), text.upper(). Reversing, however, has no dedicated method in Python — the idiomatic approach is slice notation [::-1], and substring membership uses the in operator rather than a method or function call.

Python has no heredoc syntax; a triple-quoted string ("""...""") is the closest equivalent, and prefixing it with f enables interpolation. Unlike Perl's squiggly heredoc (<<~LABEL), Python's triple-quoted string does not automatically strip common leading indentation — every line is taken completely literally, so the source usually cannot be indented to match the surrounding code without that indentation leaking into the string. The standard library's textwrap.dedent() is the manual workaround when indentation matters.

Python's % operator applies the same printf-style format specifiers Perl's sprintf and printf use — both languages inherited this format-string syntax from C, and the old-style syntax still works identically. Modern Python code prefers f-string format specs ({value:format_spec}) over the % operator, since the format is embedded directly at the interpolation point rather than requiring a separate positional-argument list to keep in sync.

Python's str.split(separator) and separator.join(list) map directly onto Perl's split/join, with the join target and separator swapped: Perl calls join($separator, @list) as a standalone function, while Python calls separator.join(list) as a method on the separator string itself. Python's no-argument str.split() mirrors Perl's special-cased split ' ', $string form exactly — both collapse runs of whitespace and discard leading and trailing empty fields.

Perl string scalars are always mutable — .= appends in place with no restriction. Python strings are immutable by design and always have been (this is not a new-version toggle the way Ruby 4.0's frozen-by-default strings are) — every operation that looks like mutation, including +=, actually creates a new string object and rebinds the name to it. This has real performance implications for loops that build up a string incrementally; Python's idiomatic fix is "".join(pieces) rather than repeated concatenation.

Perl has one scalar type for all numbers — integers and floats are the same underlying representation, and very large integers silently become imprecise floating-point approximations once they exceed the native integer range. Python has a real int type with arbitrary precision, just like Ruby: 2 ** 64 is computed exactly, with no float promotion and no precision loss, no matter how large the number grows. float is a genuinely separate type in Python, and mixing int and float in an expression promotes the result to float.

Perl's / always performs floating-point division regardless of operand types — getting an integer result requires int(...) to truncate toward zero. Python's / also always performs floating-point ("true") division, but Python additionally has a dedicated floor-division operator, //, which rounds toward negative infinity rather than truncating toward zero. Both languages agree that % returns a result with the same sign as the right operand, so -7 % 3 is 2 in both — this is a genuine similarity, and different from several other languages (including PHP and C) that take the left operand's sign instead.

Both languages check parity and sign with inline comparison expressions — there is no dedicated even?-style predicate method in either, unlike Ruby. abs() is a built-in free function in Python, matching Perl's standalone abs function exactly rather than Ruby's method-call style. Python's range(3) generates the counting sequence for a fixed number of iterations, the rough equivalent of Perl's 0..2 range in a for loop.

Perl coerces strings to numbers implicitly in numeric context — "42" + 0 just works, with warnings if the string is not numeric-looking. Python requires explicit conversion: "42" + 0 raises TypeError, since Python never silently mixes str and int in an operator. int(), float(), and str() are the explicit conversion functions, and int("FF", 16) takes an explicit base argument rather than Perl's dedicated hex() function — Python's own hex() instead goes the other direction, converting a number to a hex string.

This is one of the closer conceptual matches in the whole comparison. Perl arrays and Python lists are both heap-allocated, dynamically sized, and freely heterogeneous — a single Python list can mix an int, a str, and another list with no wrapper needed, exactly like a Perl @array can mix a number, a string, and an array reference. The mechanical difference is sigil consistency: Perl declares an array with @numbers but reads a single element with $numbers[0], while Python uses the same bare name numbers everywhere regardless of whether you are addressing the whole list or one element.

Both languages support negative indexing from the end of the list. Slicing is where they diverge subtly: Perl's @numbers[1..3] range slice is inclusive on both ends, so it includes index 3. Python's numbers[1:4] slice syntax is half-open — the stop index is exclusive — so getting the same three elements (indices 1 through 3) requires writing 4, not 3, as the stop value. This off-by-one difference is a common source of bugs when porting slicing logic directly.

Python renames Perl's push to append and has no dedicated unshift — inserting at the front uses the general-purpose insert(0, value). Python's pop() is more flexible than Perl's pop/shift pair: called with no argument it removes from the end (like Perl's pop), and called with an explicit index like pop(0) it removes from the front (replacing Perl's shift) or from anywhere else in the list. Both insert(0, ...) and pop(0) are O(n) operations in Python, same as Perl's array-front operations, since both are backed by a contiguous array under the hood.

Perl's sort defaults to string comparison — sorting numbers correctly requires the explicit { $a <=> $b } comparator block, a common beginner trap. Python's built-in sorted() compares numbers numerically by default, with no comparator needed, and a reverse=True keyword argument replaces a separate reverse call. Python has no built-in uniq: the idiomatic order-preserving de-duplication trick, dict.fromkeys(items), exploits the fact that Python dicts (since 3.7) preserve insertion order and automatically collapse duplicate keys — a Perl List::Util import is not needed at all, but the idiom itself is not obvious without having seen it.

Perl needs the CPAN-distributed core module List::Util to get reduce and sum0 — these are not built into arrays themselves. Python's sum() is a true built-in requiring no import at all, while reduce() — despite being just as fundamental a concept — was deliberately demoted out of the built-ins and into the functools standard-library module in Python 3, on the philosophy that an explicit loop is usually clearer than a general-purpose fold.

Just as with arrays, Perl declares a hash with the % sigil but reads an individual value with $scores{alice}, while Python uses one bare name (scores) for the whole structure and every access into it. Python dict literals use : between key and value where Perl's fat comma => plays the same visual role — and since Python 3.7, a dict's insertion order is guaranteed and preserved, unlike Perl's %hash, whose key order is intentionally unspecified.

Perl's exists checks for key presence without triggering autovivification. Python uses the general-purpose in operator for the same check, the same operator used for substring and list membership — one operator covers what Perl splits across exists, string index, and grep. Python's dict.get(key, default) mirrors Perl's // defined-or default pattern; bracket access on a missing key (config["missing"]) raises KeyError rather than returning undef/None the way Perl silently does.

Perl's keys and values functions have direct Python method equivalents (.keys(), .values()). Where Perl programmers loop with for my $key (keys %hash) and then look up $hash{$key} inside the loop, Python's .items() yields both the key and value together as a tuple in one step, unpacked directly into name, score — no separate lookup needed, closer to Ruby's each than to Perl's idiom.

Perl's autovivification lets $word_count{$_}++ spring a missing key into existence and treat undef as 0 for the increment — implicit and occasionally surprising. Python has no autovivification at all; the standard-library collections.defaultdict(int) makes the same behavior explicit by declaring the default-value factory up front, closer in spirit to Ruby's Hash.new(0) than to Perl's implicit magic. The | merge operator (Python 3.9+) is the modern equivalent of Perl's (%defaults, %overrides) list-flattening merge, with later keys winning in both.

This is the single biggest conceptual difference between the two languages, and Python has no trace of it whatsoever — the same is true when comparing Perl to almost every other mainstream language. In Perl, the same expression (@animals, or a parenthesized list) evaluates differently depending on whether it appears in a context that wants one value (scalar context) or many (list context) — assigning an array to a scalar silently gives you its length, but assigning a literal list (1, 2, 3) to a scalar gives you its last element, not its count. Python expressions always evaluate to exactly one thing, and getting a count always means calling len() explicitly. This eliminates an entire category of Perl surprises, but it also means Python cannot express Perl's occasionally-useful "give me count here, list there" idiom without writing it out explicitly.

Perl's wantarray lets a subroutine inspect the context it was called in and return a different value (or even a different shape of value) depending on whether the caller wants a list, a scalar, or nothing (void context). Python has no equivalent mechanism whatsoever — a function always returns the same value, and it is entirely up to the caller to decide what to do with it (index into it, call len(), or use the whole thing). This is simpler to reason about but means the same expressive trick Perl uses for dual-purpose subroutines must be written as two differently named functions in Python.

Perl offers several implicit ways to coerce an array into its count — numeric context, string concatenation, or the explicit scalar() function all work. Python offers none of these shortcuts: attempting to interpolate a list directly into an f-string prints its full contents ([10, 20, 30, 40]), not its length, so len(items) must always be called out explicitly, whether inside a string or anywhere else.

Python spells the middle branch elif — a further-abbreviated cousin of Perl's already-shortened elsif. The much bigger adjustment for a Perl programmer is structural, not spelling: Python has no braces at all, and indentation is not just a style convention but the actual mechanism that defines a block's extent — a misindented line is a SyntaxError or, worse, a silent change in program logic, not merely a review comment. Perl's brace-delimited blocks can be indented however the programmer likes with no effect on behavior.

This is a real loss for a Perl programmer: Python has neither an unless keyword nor a postfix statement-modifier form for if at all — Ruby borrowed both of these directly from Perl, but Python never adopted either. Every conditional guard must be written as a full if: block, even for the simplest one-line guard clause that Perl would express as statement unless condition;. Python does have a conditional expression (value_if_true if condition else value_if_false), but it produces a value for assignment rather than gating a statement, so it is not a substitute for the postfix-modifier idiom.

Perl's numeric range 1..5 corresponds to Python's range(1, 6) — note the stop value must be one past the last number wanted, since range() is exclusive of its stop argument, unlike Perl's inclusive ... Perl's character range "a".."e" has no Python equivalent at all: Python's range() only produces integers, so a character sequence must be built manually via ord() (character to code point) and chr() (code point to character) — a genuine ergonomic gap for a Perl or Ruby programmer used to ranges working uniformly over both.

Both languages have a while loop with the same semantics. Python has no until keyword at all (Ruby has one, borrowed from Perl, but Python never adopted it) — "loop while some condition is false" must always be written as a negated while. Python also has no C-style ++/-- increment operators, matching Ruby rather than Perl here: use += 1/-= 1 instead.

Perl once had an experimental given/when construct but removed it due to design problems with smart matching, leaving Perl programmers to fake it with a for ($topic) { if (...) { ...; last } } loop. Python 3.10's match statement is a clean, permanent replacement, and considerably more powerful than a simple value switch — beyond literal matching it supports full structural pattern matching against sequences, mappings, and class instance attributes in a single case clause, something neither Perl's workaround nor Ruby's case/when reaches without extra library support.

Perl subroutines receive all arguments bundled into the single array @_ and must manually unpack them with my ($number) = @_; — there is no way to name parameters in the signature itself in the widely-used, portable syntax. Python functions declare named parameters directly (def square(number):), so there is no unpacking step — a large ergonomic win for a Perl programmer, though Python still requires an explicit return statement (unlike Ruby, which implicitly returns the last expression) since Python has no implicit-return convention at all.

Perl has no default-parameter syntax in the subroutine signature — the idiomatic approach is unpacking positionally from @_ and then using //= (defined-or assignment) to fill in a default for any argument left undef. Python supports default values directly in the function signature (greeting="Hello"), evaluated once at function-definition time — a well-known Python trap when the default is a mutable object like a list, since every call sharing the un-passed default would share the same list instance.

Perl simulates keyword arguments by accepting a flat list of key-value pairs and unpacking it into a hash inside the subroutine (my (%args) = @_;) — there is no way for the signature itself to declare which keywords are required or provide defaults. Python has real keyword arguments as a language feature: any parameter can be passed positionally or by name at the call site, required parameters with no default raise TypeError if omitted, and city="Unknown" declares a default directly in the signature — no manual hash unpacking needed.

Since Perl subroutines already receive every argument in the flat list @_, "variadic" just means unpacking all of it into an array (or a hash, for key-value pairs) rather than a fixed number of named scalars. Python makes the intent explicit in the signature, and reuses almost the exact same star-prefix syntax as Perl's sibling Ruby: *items collects remaining positional arguments into a tuple, and **attributes collects keyword arguments into a dict — both visible directly in the function definition rather than inferred from how @_ happens to be unpacked.

This is the concept with no direct Perl equivalent at all — chaining map and grep is Perl's closest approach, but it builds an intermediate list and reads right-to-left (the filter happens before the transform even though map is written first). Python's list comprehension folds a transform and a filter into a single expression, read left-to-right in the natural English order "give me number * 2 for each number in numbers if it is even" — no intermediate list, no block syntax, and it is a first-class expression that can be assigned or returned directly.

Perl's closest approach to building a hash from a list is map returning key-value pairs, and Perl has no dedicated set type at all — a "set" is conventionally simulated as a hash whose values are discarded and never inspected. Python has dedicated comprehension syntax for both: a dict comprehension ({key: value for ...}) and a set comprehension ({value for ...}, note the braces with no colon) build the respective real, first-class collection types directly, with automatic de-duplication built into the set comprehension for free.

Perl's map/grep are always eager — they build the entire resulting list up front, even when the consuming code only needs the first few elements, so early termination requires falling back to a manual loop with last. Python's generator expression — the same comprehension syntax with parentheses instead of square brackets — evaluates lazily: each value is computed only when the loop asks for it, so iterating a generator built from a million-element range and stopping after three matches does only the minimal work, with no million-element list ever materialized in memory.

This is one of the friendliest surprises for a Perl programmer learning Python: Python's object model is much closer to Perl's references than to Perl's plain scalars. In Perl, a plain @numbers is a value, and getting reference semantics (needed to nest a list inside a hash, or to have two variables share the same underlying data) requires an explicit \ to take a reference and -> or @{} to dereference it. In Python, every name is already a reference to an object — assigning same_list = numbers does not copy the list, it makes two names point at the same list, exactly like Perl's my $array_ref = \@numbers;, but with none of Perl's explicit sigil-based dereference ceremony.

Because Perl arrays and hashes are plain values by default, nesting one inside another requires going through a reference — employees => [ { ... }, { ... } ] is really an array reference containing hash references, and Perl's syntax quietly allows dropping the -> arrows between consecutive subscripts as a convenience. Python needs no reference syntax to nest at all, because every list and dict is already reference-like: company["employees"][0]["name"] chains subscripts directly with no arrows, ever, since there is no distinction between "the value" and "a reference to the value" for Python to paper over.

This is a real ergonomic step down for a Perl programmer, even though the regex pattern language itself is nearly identical (Python's re syntax is heavily derived from Perl's). Perl bakes regex matching directly into the language as the =~ binding operator, with automatic capture-group variables ($1, $2) populated as a side effect of a successful match. Python has no regex operator at all — matching is always an explicit function call into the re standard-library module, which must be imported, and a successful match returns a Match object that capture groups must be pulled out of explicitly with .group(1) rather than appearing automatically in numbered variables.

Both languages support named capture groups with nearly identical syntax — Perl's (?<name>...) versus Python's (?P<name>...), the small P being the only difference, a strong sign of Python re's Perl heritage. Perl exposes named captures through the special %+ hash; Python exposes them through match.group("name") for one at a time, or match.groupdict() to get every named group back as a single dict in one call — no equivalent single-call convenience exists on the Perl side.

Perl's /g flag in list context returns every match (or every captured group, if the pattern has one), and counting matches relies on the famously cryptic "goatse" idiom, my $count = () = $text =~ /at/g;, which assigns into an empty list purely to force list context and then re-assigns the resulting count into a scalar. Python's re.findall() returns an ordinary list of matches directly with no context tricks needed, and re.finditer() is the lazy, generator-based sibling for very large inputs — counting is simply len(re.findall(...)), with nothing to explain about why it works.

This is one of Python's biggest ergonomic wins over Perl. Perl has no native class syntax at all — an "object" is conventionally just a hash reference that has been blessed into a package, associating it with that package's namespace for method lookup, and every method must manually unpack $self as the first element of @_. Python has a real class keyword, and self is an explicit but ordinary first parameter Python passes automatically at the call site — a genuine language construct rather than a manual convention built out of hash references and blessing.

Perl expresses inheritance through the package-level @ISA array (set idiomatically via the parent or base pragma) and calls the parent's overridden method with the special SUPER:: pseudo-package. Python declares a base class directly in the class header (class Dog(Animal):) and calls the overridden method with the built-in super() function — no separate pragma or package-variable manipulation needed, and Python additionally supports genuine multiple inheritance with a well-defined method resolution order, which Perl's @ISA mechanism handles far less predictably.

Perl's use overload pragma maps operators to handler subroutines using string keys like '+' and '""' (for stringification) — a somewhat indirect, string-based mapping declared once per package. Python's equivalent, "dunder" (double-underscore) methods — __add__ for +, __repr__ for the developer-facing string representation, __str__ for the user-facing one, and dozens more — are ordinary named methods defined directly on the class, with no separate registration pragma, and point_one + point_two works automatically the moment __add__ exists.

Writing a plain data-holding object in Perl means hand-writing a constructor and an accessor method for every field, with no built-in shortcut — CPAN modules like Moo or Class::Accessor exist specifically to remove this boilerplate. Python's @dataclass decorator (standard library, no install needed) generates the constructor, a readable __repr__, and value-based equality (__eq__) automatically from a short list of type-annotated field declarations — attributes are accessed directly as point.x, with no manual getter method to write.

Perl has nothing resembling decorator syntax: wrapping a subroutine to add cross-cutting behavior (timing, logging, memoization, access control) means manually writing a higher-order subroutine that takes a code reference and returns a new one, then explicitly calling the wrapped version everywhere the original would have been called. Python's @decorator syntax is pure sugar over exactly that same higher-order-function pattern, but applied once at the definition site — @timed above def slow_square rebinds the name automatically, so every future call to slow_square(...) is already wrapped, with no separate wrapped-variable name to remember to use.

Perl has no dedicated syntax to distinguish a "computed attribute" from an ordinary method, or a "class-level" method from an instance method — both are just conventions applied to a plain sub. Python ships several built-in decorators that make these distinctions explicit and change calling syntax: @property turns a method into something accessed like a plain attribute with no parentheses (circle.area, not circle.area()), and @staticmethod marks a method that receives no implicit self at all, called directly on the class.

Perl's traditional error handling wraps risky code in an eval { } block and checks the special global variable $@ afterward for a truthy (non-empty) value — an easy-to-miss check, since forgetting to look at $@ silently swallows the error. Python's try/except is structurally explicit: an exception either propagates past an except that does not match its type, or is caught and bound to a named variable (as error) directly in the clause that handles it, with no separate global-variable check required, and an else clause runs only when no exception occurred at all.

Perl can die with any blessed object, and catching a specific error type means manually checking ref($error) and calling ->isa(...) inside the eval/$@ pattern. Python's exception system is built around a real class hierarchy rooted at Exception: defining a custom exception is as simple as subclassing it (often with an empty body, as here, inheriting all the useful behavior), and except InsufficientFundsError as error: matches only that exception type (and its subclasses) automatically, with no manual type check needed inside the handler.

Perl has no dedicated cleanup-guaranteed block — ensuring code runs whether or not an error occurred means manually saving $@, running the cleanup code, and re-die-ing the saved error afterward, an easy step to get wrong or forget. Python's finally clause guarantees its body runs no matter what happens in the try block — whether it completes normally, raises a caught exception, or raises an exception that propagates all the way out — with no manual error-variable bookkeeping required.

Perl's file handling requires an explicit close() call (or relies on the filehandle going out of scope and being cleaned up by garbage collection, which is not guaranteed to happen promptly) — forgetting it is a classic resource leak. Python's with open(...) as file: context manager guarantees the file is closed the moment the block exits, whether normally or via an exception, with no separate close call to remember; this example cannot run in this browser sandbox's in-memory execution environment, which has no real filesystem, so it is shown for the API shape rather than live execution.

Perl's line-reading loop yields each line with its trailing newline still attached, so chomp must be called explicitly to strip it — a step that is easy to forget and produces subtly wrong string comparisons when skipped. Python's file iteration has the same behavior (each line keeps its newline), stripped here with rstrip("\n"), but the standard library also offers str.splitlines(), which splits a whole string into lines and discards the newlines in a single call — a convenience with no single-call Perl equivalent.

Perl's $_ is a genuinely distinctive feature: many built-in functions (say, print, chomp, pattern matching) default to operating on $_ when called with no argument, and loops set it implicitly, enabling extremely terse one-liners like say for @words;. Python has no topic variable and no functions that implicitly default to one — every loop variable must always be given an explicit name, and every function call must always be given its argument explicitly. This is more verbose but removes an entire class of "wait, which value is $_ right now?" bugs that can arise when Perl code nests loops or calls without renaming $_.

Perl's @ARGV holds only the actual command-line arguments (the script name lives separately in $0), while Python's sys.argv is a single list that includes the script name itself as element 0 — a common off-by-one trap when porting argument-counting logic directly. Perl's %ENV hash and Python's os.environ mapping serve the identical purpose of exposing environment variables, with near-identical bracket-access syntax once the import os is in place.

CPAN (the Comprehensive Perl Archive Network) predates PyPI (the Python Package Index) by roughly a decade and pioneered the idea of a language-wide package repository with mandatory documentation and test coverage standards — a high bar PyPI does not enforce as strictly. cpanm (cpanminus) and pip serve the same installation role for their respective ecosystems. One genuine Python advantage here: json, alongside many other common utility modules, ships in Python's standard library, whereas Perl's equivalent (JSON::PP or the faster JSON::XS) is a separate CPAN install — Python's "batteries included" philosophy covers more everyday needs without leaving the standard library at all.

Perl's dependency isolation is opt-in and less standardized: local::lib redirects installs to a project-local directory, and Carton (modeled explicitly on Ruby's Bundler) adds a lockfile on top of that for reproducible installs — but neither is bundled with Perl itself, and plenty of Perl projects still install dependencies system-wide. Python's venv module ships in the standard library and is the near-universal convention: every serious Python project is expected to use a virtual environment, and installing a package without one active is considered a mistake in most teams' workflows, not merely an option.