Python.CodeCompared.To/C#

The two visible costs against Python are the semicolon and the capital letters. Console.WriteLine appends a newline; Console.Write does not, which is the pair to Python's print(..., end=""). Only one file in a C# project may use top-level statements — the rest still declare types — so this is a script affordance, not a change to how the language is organized.

What C# does not have is Python's multi-argument print, which inserts a space between arguments for you. Console.WriteLine(name, age) does not mean that at all — it is read as a format string plus arguments and throws at run time unless name contains {0}. Write the spaces yourself, inside the interpolation.

Python raises TypeError at run time, after the first line has already printed and whatever side effects it had are done. Uncomment the C# line and the compiler refuses to produce an executable at all, so the WriteLine above it never runs either — the failure arrives before the program exists. That is the single biggest change of habit — a whole class of bugs moves from your users find it to the build fails, and in exchange you must satisfy the compiler about things Python let you leave vague.

The indentation of the closing """ sets the left margin, and every line is de-indented by that much — so a raw string nested inside a method body stays readable without the leading spaces leaking into the value. Python has no such rule, which is why textwrap.dedent exists. C# raw strings also need no escaping of quotes or backslashes, and can be interpolated by prefixing $.

Read the C# bottom-up and it is the comprehension: numbers is the for clause, Where is the if, Select is the expression on the left. The filter comes first in C# and last in Python, which is the only reordering you have to absorb. ToList is the part with no Python counterpart, and the next row is about why it is there.

Both columns print 2, 4, 6, 8, including the element added after the query was written, because both re-read the source when they are finally consumed. The difference is that a generator is one-shot — consume it twice and the second pass is empty — while a LINQ query is a standing recipe you may enumerate as many times as you like, paying the cost each time. Calling ToList is how you say "compute it now and keep the answer".

C# chains a second key with ThenBy rather than returning a tuple from the key function, and reverses with OrderByDescending rather than reverse=True. Both sorts are stable. Note that OrderBy returns a new sequence and leaves the source alone — the equivalent of sorted(), never of list.sort(), which has no LINQ counterpart because LINQ never mutates its input.

LINQ's GroupBy groups the whole sequence regardless of order, and each group is itself an enumerable carrying a Key. It composes: .GroupBy(...).Select(group => new { group.Key, Count = group.Count() }) is a one-line histogram. This is the closest thing C# has to a language-level dictionary comprehension, and it is more powerful than one.

The argument order differs: Aggregate takes the seed first and the function second, the reverse of reduce. Sum, Min, Max and Average also take an optional selector — people.Sum(person => person.Age) saves the intermediate Select. Unlike Python's sum, Sum on an int sequence returns an int and will overflow rather than promote.

The names line up almost exactly, and next(generator, default) becomes FirstOrDefault(predicate, default). Watch the naming rule: a LINQ method ending in OrDefault returns a default instead of throwing when nothing matches, while the bare First throws InvalidOperationException — the analogue of next() without a default raising StopIteration. There is also Single, which insists the match is unique; Python has no builtin for that.

SelectMany projects each element to a sequence and concatenates the results — the second for clause of a nested comprehension, and the same operation functional languages call flatMap. Zip stops at the shorter sequence exactly as Python's does, and takes the combining function inline instead of yielding tuples, though the two-argument overload yields tuples if you prefer.

Query syntax is the closest any mainstream language comes to a comprehension as syntax, and note the clause order: the source comes first, as in Python's for, and the projection last. Most C# code uses the method syntax anyway, because only a subset of the operators have query keywords, but a query with several joins or a let is far more legible this way.

The declaration is where the difference lives. Python infers "this is a generator" from the presence of yield; C# requires you to declare the return type as IEnumerable<T> and infers the rest. Local functions like this one may be declared before or after the statement that calls them, which is why the example reads top-down like Python.

Take is itertools.islice with a friendlier name, and it lives on the sequence rather than in a separate module. C# also has tuple assignment and tuple swap, so the Fibonacci step reads the same in both columns — one of the places where C# is closer to Python than to its own C-family relatives.

A Python generator holds a position; once it reaches the end it stays there, so the second sum is 0. A LINQ query holds no position — it is a description, and every enumeration starts a new walk over the source, so the second Sum is 6 again. That is friendlier until the source is a database or a file, at which point the query silently runs twice. ToList is how you pin the answer down.

C# resolves foreach by shape, not by interface: any type with a suitable public GetEnumerator is iterable, whether or not it implements IEnumerable. That is structural typing hiding inside a nominal language, and it is the same bargain as Python's protocols — with the check done at compile time. Implementing IEnumerable<T> as well is what makes the LINQ methods available on your type.

A Python name is a label that can be re-tied to anything. A C# var is a full static type, fixed at the point of declaration by whatever is on the right — var count = 3 declares an int as firmly as int count = 3 does, and reassigning a string is a compile error. The type still exists at run time, which is why GetType() can report it; C# generics are not erased the way Java's are.

A Python annotation is metadata. It is stored in __annotations__, read by mypy or your editor if you run them, and ignored entirely by the interpreter — which is why the Python column happily prints abab. A C# parameter type is a promise the compiler enforces for every call site before the program exists. The pay-off is not that fewer bugs happen; it is that the ones that do are found without running anything.

const is compile-time: the value is baked into every use site, so it must be a literal expression and only primitives and strings qualify. readonly is the run-time version, assignable once in a constructor and useful for a field whose value is not known until then. Neither makes the pointed-at object immutable — a readonly List<int> can still gain items, exactly as a Python "constant" list can.

int.Parse throws on bad input; int.TryParse(text, out var parsed) returns a bool instead and is the idiomatic form when the input is not trusted — the closest thing C# has to Python's try/except-around-int(). In the other direction, C# is less strict than Python: "total: " + value compiles, because + with a string operand calls ToString() for you.

This is duck typing bolted onto a static language, and it costs what you would expect — no compile-time checking, no editor completion, and a slower call through the runtime binder. It exists mainly for COM interop and for consuming loosely-shaped JSON, and idiomatic C# uses it rarely. Reach for it when you genuinely have no type to name; reach for object plus a pattern match when you do.

Change struct to class in the C# column and it prints 99 instead of 1 — the Python answer. That is the whole distinction. A struct is a value type: assigning it, passing it to a method, or storing it in a list copies the bytes. A class is a reference type and behaves like every Python object you have ever used. There is nothing in Python that prepares you for this, and it is the correctness surprise that costs newcomers the most time.

The C# column prints 0, 0. Reading counters[0] hands back a copy of the struct, so the increment lands on something that is discarded at the end of the statement. The compiler blocks the two most obvious ways to do it in place — assigning to a foreach variable is error CS1654, and counters[0].Total += 1 on a List is CS1612, because an indexer returns a value rather than a storage location — so the copy escapes through a local like this one. On a plain array counters[0].Total += 1 does compile and does mutate the element, which makes the behaviour depend on the container. The rule of thumb: reach for struct only for small immutable values like a point, a colour, or a money amount.

Python's == asks the object, via __eq__, and every builtin container answers by comparing contents. C#'s == on a reference type defaults to reference identity — Python's is — unless the type overloads it, which string and the numeric types do and List<T> does not. For contents use SequenceEqual, and for your own types either override Equals or declare a record, which writes value equality for you.

That wrapping is called boxing, and it happens silently: an allocation, a copy, and a later cast to get the value back. It is invisible in the source and visible in a profiler, which is why generic collections exist — a List<int> stores raw ints with no boxing at all, whereas the pre-generics ArrayList boxed every element. This is the performance story behind C#'s reified generics, and it is the reason a numeric loop in C# runs at a speed Python cannot approach.

C# sidesteps it by construction: a default argument value must be a compile-time constant, so = new List<string>() will not compile at all. The idiom is the one shown — default to null and fill it in with ??=, which assigns only when the left side is null. The C# column prints each item alone, which is what the Python author almost certainly meant.

The C# column prints -9223372036854775808: arithmetic wraps by default, with no exception and no warning. Wrap the expression in checked { } to get an OverflowException instead, or choose BigInteger, which is Python's int in a library — arbitrary precision, and correspondingly slower. The everyday advice is to use long when a count might grow and to remember that C# arithmetic is machine arithmetic.

Two traps for a Python reader in three lines. 7 / 2 is 3, not 3.5, because both operands are int — write 7 / 2.0 or cast. And C# truncates toward zero, so -7 / 2 is -3 where Python's // gives -4. The remainders follow: C# % takes the sign of the dividend (-1), Python's takes the sign of the divisor (2).

C#'s decimal is a first-class 128-bit type with its own literal suffix m, its own arithmetic, and no import — so the exact answer is one character away. Python's Decimal needs a module and a string constructor (Decimal(0.1) would import the binary error you were trying to avoid). C#'s decimal is not a bignum: it holds roughly 28 significant digits and is slower than double, which is the usual bargain for money types.

C# uses single-letter standard formats — N for a grouped number, D for a zero-padded integer, P for a percentage, C for currency, F for fixed decimals — with an optional digit count after the letter, and a custom form (#,##0.00) when those are not enough. They are culture-aware, so N2 prints a comma or a full stop as the thousands separator depending on the current culture, which Python's , never does.

strip is Trim, upper is ToUpper, in is Contains, startswith is StartsWith, find is IndexOf, join and split keep their names. The naming convention is C#'s throughout: methods are PascalCase, and one that returns something new rather than mutating usually starts with a verb like To or Trim.

word[^1] is word[-1], and word[1..^1] drops the first and last characters. What C# ranges do not have is a step, so [::-1] has no direct spelling — reversing goes through LINQ and back into a string, as shown. Ranges work on arrays and spans too, and on an array they copy, so they are closer to a Python slice than to a memoryview.

Python calls join on the separator; C# calls the static string.Join with the separator first and the sequence second, which reads more naturally to most people and is the one place C# wins this comparison outright. The count argument differs too: Python's maxsplit=1 means "split once, giving two pieces", while C#'s second argument is the maximum number of pieces, so the same result needs 2.

Python's is a list plus join; C#'s is StringBuilder, a growable buffer with Append, AppendLine and AppendJoin. Both turn quadratic work into linear. For a handful of pieces neither is necessary — an interpolated string is clearer, and the C# compiler is smart enough to fuse adjacent concatenations into a single string.Concat call.

A char is a 16-bit UTF-16 code unit and is written with single quotes — 'a' is a char and "a" is a string, and the two are not interchangeable. That distinction also means word.Length counts UTF-16 units, not code points, so an emoji outside the Basic Multilingual Plane counts as two where Python's len says one. When that matters, enumerate with StringInfo or EnumerateRunes.

List<int> holds int and nothing else, so the heterogeneous list Python allows needs List<object> and a cast on the way out. append is Add and len is the Count property — Length belongs to arrays and strings, and mixing the two up is the most common early typo. A C# array (new[] { 1, 2, 3 }) is fixed-size, so List<T> is what you want almost always.

GetValueOrDefault is dict.get. TryGetValue has no Python counterpart at all: it returns a bool and hands the value back through an out parameter, doing the "is it there" and the "give it to me" in one lookup instead of two. Indexing a missing key throws KeyNotFoundException, the analogue of KeyError. Iteration yields KeyValuePair entries which deconstruct into a tuple, so the foreach reads like Python's .items().

Python spells the set algebra with operators; C# uses LINQ methods, which have the advantage of working on any sequence rather than only on sets. HashSet<T> also has mutating versions — UnionWith, IntersectWith, ExceptWith — which change the set in place and match Python's |= family. Neither language's set preserves order.

The names in (int Quotient, int Remainder) are part of the signature, so the caller may either deconstruct positionally or read result.Quotient — Python needs a NamedTuple class to get that. C# tuples are value types, so assigning one copies it, and they compare by contents with ==. They are meant for short-lived returns; anything that outlives a method call should be a record.

ToList, ToArray, ToHashSet and ToDictionary are the four you will use, and ToDictionary takes a key selector and a value selector, which is a dict comprehension split into two lambdas. Each of them forces the query to run, so their position in a chain is also a decision about when the work happens.

A Python tuple is a snapshot — converting copied the elements, so the later append is invisible and the tuple still holds three. The C# view reports four, because it is a window onto the same list. IReadOnlyList<T> is an interface over the same object — the holder cannot add, but anyone with the underlying List still can, and the view sees it. For a real snapshot use numbers.ToImmutableList() from System.Collections.Immutable, or [.. numbers] to copy into a new array. Returning IReadOnlyList from a property is nonetheless the everyday idiom.

The three-part for is worth knowing because it is the only form that gives you the index cheaply, but reach for foreach whenever you are walking a sequence — it is clearer and it works on anything enumerable. C# has break and continue with the same meanings, and no for...else; the usual replacement is a bool flag or a LINQ Any.

The lambda receives the element first and the index second — the reverse of the tuple enumerate yields — which is a small trap when converting code. Many C# programmers simply use a counted for loop here, and .NET 9 added colours.Index(), which yields (int Index, T Item) pairs and is the direct translation when your target framework has it.

if (items) does not compile — there is no implicit conversion from a list to a bool — so the emptiness test has to be spelled out. That verbosity buys the removal of a whole family of bugs where 0 and None and "" were treated alike by accident. The same applies to or: C#'s || demands bools, and the value-returning idiom is ??, which tests only for null, never for emptiness.

C# puts the condition first — condition ? then : else — where Python puts the value first. More consequentially, a variable declared inside a loop or an if ceases to exist at the closing brace, so the pattern of leaning on a loop variable after the loop, which Python allows, needs a declaration outside. The same rule is why you cannot reuse a name in a nested block, and why the compiler catches a use-before-assignment that Python would only find at run time.

The only syntax change is the colon instead of the equals sign at the call site. Two rules differ underneath: a default value must be a compile-time constant, and the default is baked into the caller at compile time — so changing a default in a library does not change already-compiled callers until they are rebuilt. C# has no *args/**kwargs pair either; params int[] numbers covers the first and nothing covers the second.

The two methods live in a class because local functions cannot be overloaded — one name, one local function, which is the one place C# is as restrictive as Python. Overloads are a member of a type. This is overload resolution, and it happens before the program runs: the compiler looks at the static types of the arguments and writes the chosen method into the call. That means it cannot dispatch on a runtime type — a variable declared as object holding an int selects an object overload, not the int one, which is the opposite of what singledispatch would do. When you want runtime dispatch, use a virtual method or a pattern match.

An out parameter must be assigned before the method returns, and the caller declares the variable inline with out var. A ref parameter passes the variable itself rather than its value, so the method can change the caller's variable — the one way to get Python-like reference behaviour out of a value type. Both are common in the standard library (TryParse, TryGetValue) and rare in new code, where a tuple or a nullable return is usually cleaner.

That removes the reason most Python code names a small helper, and it is why LINQ chains stay inline where the Python equivalent often does not. A lambda's type is Func<...> when it returns something and Action<...> when it does not — the last type parameter of a Func is the return type. Both are ordinary values: store them in a list, pass them around, return them.

C# needs no nonlocal: a lambda may read and assign an enclosing local without any declaration, and the compiler quietly moves that local onto the heap so it can outlive the method. That is one keyword fewer to remember and one more reason to be careful — capturing a loop variable in a for loop captures the single shared variable, so all the lambdas see the final value. C# fixed this for foreach in C# 5 but the C-style for still behaves the old way.

The this on the first parameter is the whole trick: it is still a static method, and the compiler rewrites "hello".Shout() into StringExtensions.Shout("hello"). Nothing is modified, so it is safe in a way monkey-patching is not, and it is available only where the containing namespace is in scope. LINQ is nothing but extension methods on IEnumerable<T> — that is how a sealed interface gained fifty operators without changing.

Three things have no Python counterpart. Fields are declared, so an attribute invented in some other method does not exist. public and private are enforced rather than hinted with a leading underscore — Balance { get; private set; } is readable everywhere and writable only inside the class. And override must be written explicitly when replacing an inherited method, so a typo produces an error rather than a silently unused method.

C# has a keyword-level feature rather than a decorator pair, and the setter's incoming value is always called value. When there is no logic to add, public int Radius { get; set; } is the whole declaration — an auto-property, with the backing field generated for you, which is why C# code declares properties where Python would use bare attributes. An init accessor in place of set allows assignment only in an object initializer, giving immutability after construction.

Every Python method is virtual: the object decides. In C# a method is non-virtual by default, and a subclass may only override one marked virtual or abstract. Redefining a non-virtual method silently hides it instead, so the base version runs when the variable is typed as the base — the exact bug override exists to prevent, and the compiler warns unless you write new to say you meant it. C# also has no multiple inheritance and no method resolution order; mixins are done with interfaces and default implementations.

The compiler then guarantees the method exists everywhere it is called, and the interface becomes a name you can use as a parameter type. The cost is that a type you do not own cannot be retrofitted into your interface — no equivalent of registering a class with a Protocol after the fact. The C# convention of prefixing interface names with I is universal in the standard library, so IQuacker rather than Quacker.

The declarations look alike, but a C# static member is reachable only through the type — instance.Created does not compile, where Python happily reads a class attribute through an instance and, worse, lets an assignment through an instance create a shadowing instance attribute. C# also has static class for a type that can never be instantiated, which is where free-function-style helpers live, and a static constructor that runs once before first use.

Because the C# operator is static and takes both operands, there is no __radd__ problem — one method covers both orders for a given pair of types. The set of overloadable operators is fixed and smaller than Python's dunder catalogue; notably == can be overloaded but should be done together with Equals and GetHashCode, and the compiler warns when it is not. Declaring a record gives you all three for free.

The printed form is Point { X = 1, Y = 2 }, close enough to a dataclass repr to feel familiar, and == compares by contents — the one place a C# reference type does that without being asked. The positional parameters become init-only properties, so a record is immutable unless you ask for otherwise, which is the opposite default from @dataclass.

The with expression copies the record and applies the listed assignments to the copy, leaving the original untouched. It is checked at compile time, so a misspelled property name is an error rather than the TypeError replace raises at run time. This is what makes immutable-by-default records practical to work with rather than merely virtuous.

A C# enum is an integer wearing a name. It has no methods, and — the part that surprises everyone — no validation: (Status)99 is a perfectly legal Status value, because the cast is just a reinterpretation of the number. A Python Enum member is a real object with identity, so Status(99) raises. Use Enum.IsDefined when the value came from outside, and consider a record hierarchy when you want behaviour attached.

The C# form is an expression — it produces a value, which is why the method body is a single =>. when is Python's if guard, and _ is the discard in both. The one real difference is that the compiler tracks exhaustiveness: drop the _ arm and you get a warning, and at run time an unmatched value throws SwitchExpressionException rather than falling through silently as Python's match does.

C# writes the member tests in braces and allows a bare comparison — Total: > 100 — where Python needs a capture plus a when guard. Patterns nest ({ Customer.Address.Country: "NL" }), combine with and/or/not, and can deconstruct positionally: Order(var total, true) works because a record generates a Deconstruct method.

That combination is the everyday form of pattern matching in C# and it removes the cast that used to follow every type test. Note the collision of names: C#'s is is Python's isinstance, while Python's is — identity — is C#'s ReferenceEquals. The declared variable is in scope for the rest of the enclosing block, which is what makes the early-return style read cleanly.

The C# switch has no catch-all arm and still compiles without a warning here, because the compiler can see every type deriving from Shape in this file. Marking the base sealed — abstract sealed record hierarchies, formally sealed types — makes that guarantee hold across files, so adding a variant later turns every unhandled switch into a warning. That is the check Python's match cannot perform, and the reason this pattern is worth reaching for over a virtual method when the operations change more often than the types.

With nullable reference types enabled — the default for new projects — string means "never null" and string? means "might be". Dereferencing the second without checking is a compiler warning, and the checks you write teach the compiler what it may assume afterwards. It is a warning rather than an error because the guarantee is not airtight: older libraries predate the annotations. Still, it moves the majority of null bugs to compile time, which is the closest thing C# has to a solved problem that Python has not.

?? supplies a value when the left side is null; ?. calls a member only when the receiver is not null and yields null otherwise; ??= assigns only when the target is null. The difference from Python's or matters: 0 or 5 is 5 and "" or "x" is "x", because Python tests truthiness, whereas ?? tests null alone and leaves 0 and "" intact. Chaining ?. short-circuits the whole chain, which is the idiom for a deep optional path.

It carries HasValue and Value, and unwrapping it when it is empty throws InvalidOperationException. This is the one place where C# nullability is enforced at run time rather than merely checked at compile time, because a nullable value type genuinely has a different representation. The ! is the null-forgiving operator: it tells the compiler "I have checked, stop warning", and it is the tool you will most regret overusing.

Python names the attribute and the type: 'NoneType' object has no attribute 'upper'. A NullReferenceException historically named nothing at all, though .NET 6 and later add the expression when it can work it out. Guarding an argument at the top of a method with ArgumentNullException.ThrowIfNull(name) gives a far better message and is the standard idiom for public methods.

The <T> makes the relationship explicit: the fallback must be the same type as the elements, and the return type is that type too, so the caller keeps full type information. The call sites need no annotation because C# infers the type argument from the arguments. This is the same information a TypeVar conveys to mypy, except that here it is the compiler enforcing it and the runtime preserving it.

Without the constraint the body would not compile, because T could be anything. With it, the compiler checks each call site instead — passing a type that does not implement IComparable<T> is an error at the call, not a surprise inside the loop. That is the trade for Python's optimism, where largest of a list of dictionaries type-checks fine and raises TypeError in production. Other constraints cover reference types, value types, having a parameterless constructor, and deriving from a base class.

The runtime knows this object is a List of Int32, which is why List<int> can store unboxed integers, why typeof(T) works inside a generic method, and why serialization libraries can reconstruct a strongly-typed list from JSON. If you have met Java's erasure, this is the thing C# does differently, and it is the reason C# generics carry no List<?>-style wildcards.

except is catch, and the type comes first with the variable after it. finally means the same thing in both languages. What C# lacks is Python's else clause on a try, and — importantly for anyone translating code — it has no checked exceptions, so unlike Java nothing forces you to declare or handle what a method may throw. That makes C# error handling feel much more like Python's than like Java's.

raise is throw, and super().__init__(...) is the : base(...) clause after the constructor signature. The convention is to end the name in Exception. One habit to unlearn: re-throwing inside a handler should be a bare throw;, not throw error; — the second resets the stack trace to this line, discarding where the failure actually happened.

with calls __enter__ and __exit__; using calls Dispose on anything implementing IDisposable. The differences are that __exit__ can suppress an exception by returning true and Dispose cannot, and that C# offers a declaration form — using var writer = new StringWriter(); with no block — which disposes at the end of the enclosing scope and is what most modern code uses.

The difference is not cosmetic. A when filter runs while the stack is still intact, so an unmatched exception continues on its way with its original stack and any debugger break happens at the throw site — where the Python version has already unwound to the handler before deciding to re-raise. Filters are also the clean way to log without handling: catch (Exception error) when (Log(error)), with a Log that returns false.

What they promise underneath is different. Python's coroutines run on one thread inside one event loop, so an async program is concurrent but never parallel, and a blocking call stalls everything. A C# Task resumes on the thread pool, so two awaited operations can genuinely run at the same time on different cores. Also note that a C# top-level program may await directly — the compiler generates the async entry point — so there is no asyncio.run to call.

Task.WhenAll is asyncio.gather, and it preserves order in the same way. The important semantic difference is when the work starts: a Python coroutine does nothing until it is awaited or scheduled, whereas calling a C# async method starts it immediately and hands back a Task already in flight. That is why Select(Work) above launches all five before WhenAll is even called — a hot task, not a cold coroutine.

CPython's global interpreter lock means those two threads take turns, so threading buys nothing for CPU-bound work and Python programmers reach for multiprocessing instead. The .NET threads run at the same instant on different cores, which is why the lock is not optional: remove it and the answer comes out short, because total++ is a read, an add and a write. C# spells the mutual exclusion lock (someObject), the direct analogue of with lock:.

AsParallel turns a LINQ query into a PLINQ query: the runtime partitions the source across the thread pool and merges the results. Because the GIL does not exist, this genuinely uses every core, which is the payoff for all the type declarations elsewhere on this page. Ordering is not preserved unless you ask — hence the explicit OrderBy, or AsOrdered() — and for a query this small the coordination costs more than the work, so measure before sprinkling it about.

Everything in every referenced assembly is already present; using is purely about how much of the name you have to type, so there is no import-time side effect, no circular import problem, and no cost to an unused one. There is no from x import y for a single type, though using static System.Math; imports a type's static members and using Alias = Some.Long.Type; renames. The runner supplies the common namespaces implicitly, which is why only System.Text.Json is written out here.

dotnet add package is pip install, NuGet is PyPI, and the .csproj file is requirements.txt and pyproject.toml at once — it lists dependencies with versions and is checked in. There is no virtual environment because packages are restored per project by default, which removes an entire category of Python problem. What you give up is the REPL-first workflow: dotnet run compiles first, and while dotnet-script and the C# Interactive window exist, no C# team lives in them the way a Python team lives in the REPL.