[{"data":1,"prerenderedAt":1674},["ShallowReactive",2],{"page-\u002Fpython\u002F01-introduction-and-setup":3},{"id":4,"title":5,"body":6,"description":143,"extension":1668,"meta":1669,"navigation":34,"path":1670,"seo":1671,"stem":1672,"__hash__":1673},"content\u002Fpython\u002F01-introduction-and-setup.md","01 — Introduction & Setup",{"type":7,"value":8,"toc":1635},"minimark",[9,13,76,123,234,362,419,506,557,674,735,819,898,970,1071,1186,1236,1317,1377,1426,1542,1631],[10,11,5],"h1",{"id":12},"_01-introduction-setup",[14,15,16,21,55],"question-wrapper",{},[17,18,20],"h3",{"id":19},"q1-what-is-cpython","Q1. What is CPython?",[22,23,26,37,43,49],"ul",{"className":24},[25],"contains-task-list",[27,28,31,36],"li",{"className":29},[30],"task-list-item",[32,33],"input",{"disabled":34,"type":35},true,"checkbox"," It is a third-party JIT-compiled alternative to Python",[27,38,40,42],{"className":39},[30],[32,41],{"disabled":34,"type":35}," It is the reference implementation of Python, written primarily in C",[27,44,46,48],{"className":45},[30],[32,47],{"disabled":34,"type":35}," It is a tool that transpiles Python source into C++ for compilation",[27,50,52,54],{"className":51},[30],[32,53],{"disabled":34,"type":35}," It is the deprecated Python 2 interpreter, superseded by Python 3",[56,57,58,62,70],"details",{},[59,60,61],"summary",{},"Show Answer",[63,64,65,69],"p",{},[66,67,68],"strong",{},"Answer:"," B — It is the reference implementation of Python, written primarily in C",[63,71,72,75],{},[66,73,74],{},"Explanation:"," CPython is the original and most widely used Python interpreter, implemented in C, and it is what most people mean when they say \"Python.\" Option A describes PyPy, a different implementation. Option C misdescribes CPython — it compiles Python source to bytecode executed by a virtual machine, not to C++. Option D is wrong because CPython supports both historical Python 2 releases and current Python 3 releases; it isn't tied to one language version.",[14,77,78,82,109],{},[17,79,81],{"id":80},"q2-a-team-runs-a-long-lived-cpu-bound-pure-python-service-and-wants-a-drop-in-interpreter-swap-for-better-throughput-which-alternative-implementation-is-specifically-known-for-using-a-jit-compiler-to-speed-up-such-workloads","Q2. A team runs a long-lived, CPU-bound pure-Python service and wants a drop-in interpreter swap for better throughput. Which alternative implementation is specifically known for using a JIT compiler to speed up such workloads?",[22,83,85,91,97,103],{"className":84},[25],[27,86,88,90],{"className":87},[30],[32,89],{"disabled":34,"type":35}," Jython",[27,92,94,96],{"className":93},[30],[32,95],{"disabled":34,"type":35}," PyPy",[27,98,100,102],{"className":99},[30],[32,101],{"disabled":34,"type":35}," IronPython",[27,104,106,108],{"className":105},[30],[32,107],{"disabled":34,"type":35}," MicroPython",[56,110,111,113,118],{},[59,112,61],{},[63,114,115,117],{},[66,116,68],{}," B — PyPy",[63,119,120,122],{},[66,121,74],{}," PyPy includes a just-in-time compiler that can dramatically speed up long-running pure-Python code by compiling hot code paths to machine code at runtime. Jython (A) targets the JVM and IronPython (C) targets .NET — both let Python interoperate with those platforms but neither is primarily a JIT speed play for pure-Python workloads. MicroPython (D) is a lean reimplementation for microcontrollers, prioritizing footprint over raw throughput.",[14,124,126,135,165,205],{"language":125},"python",[17,127,129,130,134],{"id":128},"q3-in-python-3-how-must-print-be-used","Q3. In Python 3, how must ",[131,132,133],"code",{},"print"," be used?",[136,137,138],"code-wrapper",{"language":125},[139,140,144],"pre",{"className":141,"code":142,"language":125,"meta":143,"style":143},"language-python shiki shiki-themes github-light github-dark","print(\"deployment finished\")\n","",[131,145,146],{"__ignoreMap":143},[147,148,151,154,158,162],"span",{"class":149,"line":150},"line",1,[147,152,133],{"class":153},"snvgF",[147,155,157],{"class":156},"ssxIu","(",[147,159,161],{"class":160},"sJ6F3","\"deployment finished\"",[147,163,164],{"class":156},")\n",[22,166,168,177,186,199],{"className":167},[25],[27,169,171,173,174],{"className":170},[30],[32,172],{"disabled":34,"type":35}," As a statement, without parentheses: ",[131,175,176],{},"print \"deployment finished\"",[27,178,180,182,183],{"className":179},[30],[32,181],{"disabled":34,"type":35}," As a function call, with parentheses: ",[131,184,185],{},"print(\"deployment finished\")",[27,187,189,191,192,195,196,198],{"className":188},[30],[32,190],{"disabled":34,"type":35}," Only via ",[131,193,194],{},"sys.stdout.write",", since ",[131,197,133],{}," was removed in Python 3",[27,200,202,204],{"className":201},[30],[32,203],{"disabled":34,"type":35}," Either form works interchangeably in Python 3",[56,206,207,209,216],{},[59,208,61],{},[63,210,211,213,214],{},[66,212,68],{}," B — As a function call, with parentheses: ",[131,215,185],{},[63,217,218,220,221,223,224,227,228,230,231,233],{},[66,219,74],{}," Python 3 turned ",[131,222,133],{}," into a regular builtin function, so it must be called with parentheses. Option A is the Python 2 statement form and raises a ",[131,225,226],{},"SyntaxError"," under Python 3. Option C is false — ",[131,229,133],{}," still exists as a convenient wrapper; you are not forced onto ",[131,232,194],{},". Option D is wrong because the statement form is not valid Python 3 syntax at all.",[14,235,236,244,269,317],{"language":125},[17,237,239,240,243],{"id":238},"q4-what-does-true-division-return-in-python-3-when-dividing-two-integers","Q4. What does ",[131,241,242],{},"\u002F"," (true division) return in Python 3 when dividing two integers?",[136,245,246],{"language":125},[139,247,249],{"className":141,"code":248,"language":125,"meta":143,"style":143},"result = 7 \u002F 2\n",[131,250,251],{"__ignoreMap":143},[147,252,253,256,260,263,266],{"class":149,"line":150},[147,254,255],{"class":156},"result ",[147,257,259],{"class":258},"svdQ7","=",[147,261,262],{"class":153}," 7",[147,264,265],{"class":258}," \u002F",[147,267,268],{"class":153}," 2\n",[22,270,272,284,296,309],{"className":271},[25],[27,273,275,277,278,281,282],{"className":274},[30],[32,276],{"disabled":34,"type":35}," ",[131,279,280],{},"3",", an integer truncated toward zero, matching Python 2's ",[131,283,242],{},[27,285,287,277,289,292,293,295],{"className":286},[30],[32,288],{"disabled":34,"type":35},[131,290,291],{},"3.5",", a float — Python 3's ",[131,294,242],{}," always performs true division",[27,297,299,301,302,305,306,308],{"className":298},[30],[32,300],{"disabled":34,"type":35}," A ",[131,303,304],{},"TypeError",", because ",[131,307,242],{}," requires float operands explicitly",[27,310,312,277,314,316],{"className":311},[30],[32,313],{"disabled":34,"type":35},[131,315,280],{},", an integer floored toward negative infinity",[56,318,319,321,330],{},[59,320,61],{},[63,322,323,325,326,292,328,295],{},[66,324,68],{}," B — ",[131,327,291],{},[131,329,242],{},[63,331,332,334,335,337,338,341,342,345,346,348,349,352,353,355,356,358,359,361],{},[66,333,74],{}," In Python 3, ",[131,336,242],{}," always performs true division and returns a ",[131,339,340],{},"float",", even when both operands are ",[131,343,344],{},"int",". This is a deliberate change from Python 2, where ",[131,347,242],{}," between two ints performed floor division by default. Option A describes the old Python 2 behavior. Option D describes what ",[131,350,351],{},"\u002F\u002F"," (floor division) does, not ",[131,354,242],{},". Option C is wrong — ",[131,357,242],{}," works fine on ints and simply promotes the result to ",[131,360,340],{},".",[14,363,364,372,403],{},[17,365,367,368,371],{"id":366},"q5-what-does-a-pyc-file-contain","Q5. What does a ",[131,369,370],{},".pyc"," file contain?",[22,373,375,381,387,397],{"className":374},[25],[27,376,378,380],{"className":377},[30],[32,379],{"disabled":34,"type":35}," Native machine code compiled for the host CPU",[27,382,384,386],{"className":383},[30],[32,385],{"disabled":34,"type":35}," Compiled Python bytecode, cached to speed up future imports of that module",[27,388,390,392,393,396],{"className":389},[30],[32,391],{"disabled":34,"type":35}," A minified copy of the original ",[131,394,395],{},".py"," source text",[27,398,400,402],{"className":399},[30],[32,401],{"disabled":34,"type":35}," An encrypted, obfuscated version of the source code",[56,404,405,407,412],{},[59,406,61],{},[63,408,409,411],{},[66,410,68],{}," B — Compiled Python bytecode, cached to speed up future imports of that module",[63,413,414,277,416,418],{},[66,415,74],{},[131,417,370],{}," files hold the compiled bytecode for a module so that CPython can skip re-parsing and re-compiling the source text on subsequent imports, speeding up startup. It is not native machine code (A) — CPython's bytecode still runs on the interpreter's virtual machine. It is not a text-based minified copy (C), and it provides no meaningful security or obfuscation (D); bytecode can be decompiled fairly easily.",[14,420,421,429,474],{},[17,422,424,425,428],{"id":423},"q6-where-does-cpython-3-store-cached-bytecode-for-an-imported-module-named-utilspy-by-default","Q6. Where does CPython 3 store cached bytecode for an imported module named ",[131,426,427],{},"utils.py",", by default?",[22,430,432,445,458,464],{"className":431},[25],[27,433,435,437,438,441,442],{"className":434},[30],[32,436],{"disabled":34,"type":35}," Inside a ",[131,439,440],{},"__pycache__\u002F"," directory next to the source, e.g. ",[131,443,444],{},"__pycache__\u002Futils.cpython-311.pyc",[27,446,448,450,451,454,455,457],{"className":447},[30],[32,449],{"disabled":34,"type":35}," As ",[131,452,453],{},"utils.pyc",", directly replacing ",[131,456,427],{}," in place",[27,459,461,463],{"className":460},[30],[32,462],{"disabled":34,"type":35}," In the interpreter's installation directory, keyed by project name",[27,465,467,469,470,473],{"className":466},[30],[32,468],{"disabled":34,"type":35}," In a single, project-wide ",[131,471,472],{},"compiled.pyc"," bundle",[56,475,476,478,487],{},[59,477,61],{},[63,479,480,482,483,441,485],{},[66,481,68],{}," A — Inside a ",[131,484,440],{},[131,486,444],{},[63,488,489,491,492,495,496,499,500,502,503,505],{},[66,490,74],{}," Since Python 3.2 (PEP 3147), cached bytecode lives in a ",[131,493,494],{},"__pycache__"," subdirectory alongside the source, with a filename tagged by interpreter implementation and version (e.g., ",[131,497,498],{},"cpython-311","). Option B describes the old Python 2 layout, where ",[131,501,370],{}," sat next to ",[131,504,395],{}," with no subfolder. Options C and D describe caching schemes CPython does not use.",[14,507,508,512,539],{},[17,509,511],{"id":510},"q7-per-pep-8-how-many-spaces-should-be-used-for-each-indentation-level","Q7. Per PEP 8, how many spaces should be used for each indentation level?",[22,513,515,521,527,533],{"className":514},[25],[27,516,518,520],{"className":517},[30],[32,519],{"disabled":34,"type":35}," 2 spaces",[27,522,524,526],{"className":523},[30],[32,525],{"disabled":34,"type":35}," 4 spaces",[27,528,530,532],{"className":529},[30],[32,531],{"disabled":34,"type":35}," A single hard tab character",[27,534,536,538],{"className":535},[30],[32,537],{"disabled":34,"type":35}," 8 spaces",[56,540,541,543,548],{},[59,542,61],{},[63,544,545,547],{},[66,546,68],{}," B — 4 spaces",[63,549,550,552,553,556],{},[66,551,74],{}," PEP 8 recommends 4 spaces per indentation level and explicitly recommends spaces over tabs. Options A and D are used by some other languages\u002Fstyle guides but are not the PEP 8 recommendation for Python. Option C is discouraged: PEP 8 says tabs and spaces should not be mixed, and spaces are preferred; Python 3 even raises a ",[131,554,555],{},"TabError"," if a file inconsistently mixes tabs and spaces in a way that changes meaning.",[14,558,560,568,604,639],{"language":559},"bash",[17,561,563,564,567],{"id":562},"q8-at-the-interactive-repl-what-does-the-special-name-_-refer-to-immediately-after-evaluating-an-expression","Q8. At the interactive REPL, what does the special name ",[131,565,566],{},"_"," refer to immediately after evaluating an expression?",[136,569,570],{"language":559},[139,571,574],{"className":572,"code":573,"language":559,"meta":143,"style":143},"language-bash shiki shiki-themes github-light github-dark",">>> 40 + 2\n42\n>>> _\n",[131,575,576,590,596],{"__ignoreMap":143},[147,577,578,581,585,588],{"class":149,"line":150},[147,579,580],{"class":156},">>> ",[147,582,584],{"class":583},"sIsaT","40",[147,586,587],{"class":160}," +",[147,589,268],{"class":153},[147,591,593],{"class":149,"line":592},2,[147,594,595],{"class":583},"42\n",[147,597,599,601],{"class":149,"line":598},3,[147,600,580],{"class":156},[147,602,603],{"class":583},"_\n",[22,605,607,617,627,633],{"className":606},[25],[27,608,610,612,613,616],{"className":609},[30],[32,611],{"disabled":34,"type":35}," The value of the last expression evaluated at the prompt (here, ",[131,614,615],{},"42",")",[27,618,620,301,622,195,624,626],{"className":619},[30],[32,621],{"disabled":34,"type":35},[131,623,226],{},[131,625,566],{}," has no special meaning in Python",[27,628,630,632],{"className":629},[30],[32,631],{"disabled":34,"type":35}," The current line number in the session",[27,634,636,638],{"className":635},[30],[32,637],{"disabled":34,"type":35}," The name of the most recently called function",[56,640,641,643,650],{},[59,642,61],{},[63,644,645,647,648,616],{},[66,646,68],{}," A — The value of the last expression evaluated at the prompt (here, ",[131,649,615],{},[63,651,652,277,654,657,658,660,661,663,664,666,667,670,671,673],{},[66,653,74],{},[66,655,656],{},"Debug"," — the interactive interpreter automatically binds ",[131,659,566],{}," to the result of the last statement that produced a displayed value, which is convenient for chaining exploratory work at the prompt. This behavior is unique to the interactive REPL; it does not happen when running a ",[131,662,395],{}," file as a script, which is the trap — code relying on ",[131,665,566],{}," outside the REPL will raise a ",[131,668,669],{},"NameError"," (unless ",[131,672,566],{}," was assigned some other way, e.g. as the conventional \"throwaway\" variable name).",[14,675,676,683,713],{},[17,677,679,680,682],{"id":678},"q9-what-determines-whether-cpython-recompiles-a-module-instead-of-reusing-its-cached-pyc-under-the-default-non-hash-based-invalidation-mode","Q9. What determines whether CPython recompiles a module instead of reusing its cached ",[131,681,370],{},", under the default (non hash-based) invalidation mode?",[22,684,686,695,701,707],{"className":685},[25],[27,687,689,691,692,694],{"className":688},[30],[32,690],{"disabled":34,"type":35}," CPython compares the source file's modification time and size, embedded in the ",[131,693,370],{}," header, against the current source file",[27,696,698,700],{"className":697},[30],[32,699],{"disabled":34,"type":35}," CPython recompiles on every run regardless of any cache, since caching is opt-in and off by default",[27,702,704,706],{"className":703},[30],[32,705],{"disabled":34,"type":35}," CPython caches bytecode permanently and never re-checks the source afterward",[27,708,710,712],{"className":709},[30],[32,711],{"disabled":34,"type":35}," CPython computes a SHA-256 hash of the full source on every import and compares it, ignoring timestamps entirely",[56,714,715,717,724],{},[59,716,61],{},[63,718,719,721,722,694],{},[66,720,68],{}," A — CPython compares the source file's modification time and size, embedded in the ",[131,723,370],{},[63,725,726,728,729,731,732,734],{},[66,727,74],{}," By default, CPython uses timestamp-based invalidation: the ",[131,730,370],{}," header stores the source's mtime and size, and a mismatch triggers recompilation. Option D describes hash-based ",[131,733,370],{}," invalidation, a real but opt-in mode added in PEP 552 (Python 3.7+) — it exists, but it is not the default, which is the gotcha. Option B is wrong because caching is on by default for imported modules. Option C is wrong because stale caches are actively detected, not blindly trusted forever.",[14,736,737,751,786],{},[17,738,740,741,744,745,747,748,750],{"id":739},"q10-does-the-script-you-run-directly-eg-python-apppy-get-its-own-pyc-written-to-__pycache__","Q10. Does the script you run directly (e.g., ",[131,742,743],{},"python app.py",") get its own ",[131,746,370],{}," written to ",[131,749,494],{},"?",[22,752,754,760,770,780],{"className":753},[25],[27,755,757,759],{"className":756},[30],[32,758],{"disabled":34,"type":35}," Yes — every executed file is cached identically, including the entry-point script",[27,761,763,765,766,769],{"className":762},[30],[32,764],{"disabled":34,"type":35}," No — only imported modules are cached; the file run directly as ",[131,767,768],{},"__main__"," is compiled fresh each run and not cached",[27,771,773,775,776,779],{"className":772},[30],[32,774],{"disabled":34,"type":35}," Yes, but only when the ",[131,777,778],{},"-O"," flag is passed",[27,781,783,785],{"className":782},[30],[32,784],{"disabled":34,"type":35}," No — CPython never caches bytecode for any file, despite common belief",[56,787,788,790,797],{},[59,789,61],{},[63,791,792,794,795,769],{},[66,793,68],{}," B — No — only imported modules are cached; the file run directly as ",[131,796,768],{},[63,798,799,277,801,804,805,807,808,811,812,815,816,818],{},[66,800,74],{},[66,802,803],{},"Performance"," — CPython caches bytecode for modules reached via the import system, but the top-level script executed as ",[131,806,768],{}," is recompiled every invocation, since there's no stable cache-invalidation target the way there is for an importable module. This surprises developers who expect a ",[131,809,810],{},"__pycache__\u002Fapp.cpython-311.pyc"," to appear next to ",[131,813,814],{},"app.py"," after running it directly — it won't, though any modules ",[131,817,814],{}," imports will get cached.",[14,820,821,831,870],{},[17,822,824,825,827,828,830],{"id":823},"q11-two-different-python-versions-39-and-311-both-import-the-same-utilspy-from-a-shared-__pycache__-directory-what-happens","Q11. Two different Python versions, 3.9 and 3.11, both import the same ",[131,826,427],{}," from a shared ",[131,829,494],{}," directory. What happens?",[22,832,834,844,858,864],{"className":833},[25],[27,835,837,839,840,843],{"className":836},[30],[32,838],{"disabled":34,"type":35}," A version-conflict ",[131,841,842],{},"ImportError"," is raised immediately",[27,845,847,849,850,853,854,857],{"className":846},[30],[32,848],{"disabled":34,"type":35}," Each interpreter reads and writes its own version-tagged file (",[131,851,852],{},"utils.cpython-39.pyc"," and ",[131,855,856],{},"utils.cpython-311.pyc","), so both coexist safely",[27,859,861,863],{"className":860},[30],[32,862],{"disabled":34,"type":35}," The second interpreter to run overwrites and corrupts the first interpreter's cache entry",[27,865,867,869],{"className":866},[30],[32,868],{"disabled":34,"type":35}," Only one Python version may be installed on a machine at a time, so this scenario cannot occur",[56,871,872,874,883],{},[59,873,61],{},[63,875,876,878,879,853,881,857],{},[66,877,68],{}," B — Each interpreter reads and writes its own version-tagged file (",[131,880,852],{},[131,882,856],{},[63,884,885,277,887,890,891,893,894,897],{},[66,886,74],{},[66,888,889],{},"Portability"," — the PEP 3147 naming scheme embeds the implementation and version tag in the cache filename specifically so multiple interpreters can safely share one ",[131,892,494],{}," directory without clobbering each other's bytecode. Options A, C, and D describe conflicts that the tagging scheme was designed to prevent; multiple Python versions coexisting on one machine (e.g., via ",[131,895,896],{},"pyenv"," or system packages) is routine.",[14,899,900,907,947],{},[17,901,903,904,906],{"id":902},"q12-a-developer-deletes-a-stray-__pycache__-directory-before-committing-a-project-to-git-is-this-safe","Q12. A developer deletes a stray ",[131,905,494],{}," directory before committing a project to git. Is this safe?",[22,908,910,922,935,941],{"className":909},[25],[27,911,913,915,916,918,919,921],{"className":912},[30],[32,914],{"disabled":34,"type":35}," No — ",[131,917,370],{}," files sometimes contain unique logic not present in the ",[131,920,395],{}," source, so deleting them causes data loss",[27,923,925,927,928,930,931,934],{"className":924},[30],[32,926],{"disabled":34,"type":35}," Yes — ",[131,929,494],{}," is a disposable, regeneratable cache; it is generally recommended to ",[131,932,933],{},".gitignore"," it rather than commit it",[27,936,938,940],{"className":937},[30],[32,939],{"disabled":34,"type":35}," No — deleting it forces a full reinstall of the Python interpreter",[27,942,944,946],{"className":943},[30],[32,945],{"disabled":34,"type":35}," Yes, but only because the interpreter falls back to Python 2 mode without a valid cache",[56,948,949,951,960],{},[59,950,61],{},[63,952,953,955,956,930,958,934],{},[66,954,68],{}," B — Yes — ",[131,957,494],{},[131,959,933],{},[63,961,962,277,964,966,967,969],{},[66,963,74],{},[131,965,370],{}," files are purely derived artifacts recompiled automatically from ",[131,968,395],{}," source as needed, so removing them is always safe and they are conventionally excluded from version control. Option A is a myth — bytecode caches never contain logic absent from the source they were compiled from. Options C and D describe consequences that simply do not occur; deleting a cache directory has zero effect on the interpreter installation itself.",[14,971,972,980,1029],{},[17,973,975,976,979],{"id":974},"q13-which-statement-correctly-contrasts-str-between-python-2-and-python-3","Q13. Which statement correctly contrasts ",[131,977,978],{},"str"," between Python 2 and Python 3?",[22,981,983,995,1014,1023],{"className":982},[25],[27,984,986,988,989,991,992,994],{"className":985},[30],[32,987],{"disabled":34,"type":35}," In Python 2, ",[131,990,978],{}," held Unicode code points by default; Python 3's ",[131,993,978],{}," became raw bytes",[27,996,998,988,1000,1002,1003,1006,1007,1009,1010,1013],{"className":997},[30],[32,999],{"disabled":34,"type":35},[131,1001,978],{}," was a byte sequence by default (with a separate ",[131,1004,1005],{},"unicode"," type for text); in Python 3, ",[131,1008,978],{}," became a sequence of Unicode code points, and raw bytes moved to the distinct ",[131,1011,1012],{},"bytes"," type",[27,1015,1017,1019,1020,1022],{"className":1016},[30],[32,1018],{"disabled":34,"type":35}," Both versions treat ",[131,1021,978],{}," identically as raw, undecoded bytes",[27,1024,1026,1028],{"className":1025},[30],[32,1027],{"disabled":34,"type":35}," Python 3 removed the text\u002Fbytes distinction entirely, merging both into one type",[56,1030,1031,1033,1046],{},[59,1032,61],{},[63,1034,1035,1037,1038,1002,1040,1006,1042,1009,1044,1013],{},[66,1036,68],{}," B — In Python 2, ",[131,1039,978],{},[131,1041,1005],{},[131,1043,978],{},[131,1045,1012],{},[63,1047,1048,1050,1051,1053,1054,1056,1057,1059,1060,1062,1063,853,1065,1067,1068,1070],{},[66,1049,74],{}," This is one of the largest Python 2 → 3 breaking changes: Python 2's ",[131,1052,978],{}," was really a byte string (with ",[131,1055,1005],{}," as the separate text type), while Python 3 flips this so ",[131,1058,978],{}," is text (Unicode) and ",[131,1061,1012],{}," is the explicit binary type, with no implicit coercion between them. Option A states the reverse of the truth. Options C and D understate a distinction that Python 3 in fact made stricter, not looser — mixing ",[131,1064,978],{},[131,1066,1012],{}," in Python 3 raises a ",[131,1069,304],{}," rather than silently coercing.",[14,1072,1073,1083,1100,1138],{"language":559},[17,1074,1076,1077,1079,1080,750],{"id":1075},"q14-what-is-the-effect-of-invoking-the-interpreter-with-the-o-flag-eg-python-o-apppy","Q14. What is the effect of invoking the interpreter with the ",[131,1078,778],{}," flag, e.g. ",[131,1081,1082],{},"python -O app.py",[136,1084,1085],{"language":559},[139,1086,1088],{"className":572,"code":1087,"language":559,"meta":143,"style":143},"python -O app.py\n",[131,1089,1090],{"__ignoreMap":143},[147,1091,1092,1094,1097],{"class":149,"line":150},[147,1093,125],{"class":583},[147,1095,1096],{"class":153}," -O",[147,1098,1099],{"class":160}," app.py\n",[22,1101,1103,1120,1126,1132],{"className":1102},[25],[27,1104,1106,1108,1109,1112,1113,1116,1117],{"className":1105},[30],[32,1107],{"disabled":34,"type":35}," It enables basic optimizations — ",[131,1110,1111],{},"assert"," statements and code guarded by ",[131,1114,1115],{},"if __debug__:"," are stripped, and cache files are tagged ",[131,1118,1119],{},"opt-1.pyc",[27,1121,1123,1125],{"className":1122},[30],[32,1124],{"disabled":34,"type":35}," It automatically reformats the source file to comply with PEP 8",[27,1127,1129,1131],{"className":1128},[30],[32,1130],{"disabled":34,"type":35}," It runs the script inside an online, network-sandboxed mode",[27,1133,1135,1137],{"className":1134},[30],[32,1136],{"disabled":34,"type":35}," It has no effect under CPython and is only meaningful under Jython",[56,1139,1140,1142,1153],{},[59,1141,61],{},[63,1143,1144,1146,1147,1112,1149,1116,1151],{},[66,1145,68],{}," A — It enables basic optimizations — ",[131,1148,1111],{},[131,1150,1115],{},[131,1152,1119],{},[63,1154,1155,277,1157,1159,1160,1162,1163,1166,1167,1170,1171,1173,1174,1176,1177,1179,1180,1182,1183,1185],{},[66,1156,74],{},[66,1158,656],{}," — ",[131,1161,778],{}," sets ",[131,1164,1165],{},"__debug__"," to ",[131,1168,1169],{},"False",", causing ",[131,1172,1111],{}," statements (and any ",[131,1175,1115],{}," blocks) to be compiled out entirely — a common trap because assertions silently stop firing in ",[131,1178,778],{}," mode, so they must never be relied on for input validation or security checks in production. Options B and C describe behavior ",[131,1181,778],{}," does not have. Option D is wrong — ",[131,1184,778],{}," is a genuine, commonly used CPython flag.",[14,1187,1188,1192,1219],{},[17,1189,1191],{"id":1190},"q15-per-pep-8-what-is-the-recommended-maximum-line-length-for-code","Q15. Per PEP 8, what is the recommended maximum line length for code?",[22,1193,1195,1201,1207,1213],{"className":1194},[25],[27,1196,1198,1200],{"className":1197},[30],[32,1199],{"disabled":34,"type":35}," 79 characters, with slightly more latitude (up to ~72) suggested for flowing text like docstrings and comments",[27,1202,1204,1206],{"className":1203},[30],[32,1205],{"disabled":34,"type":35}," 120 characters, strictly enforced by the interpreter",[27,1208,1210,1212],{"className":1209},[30],[32,1211],{"disabled":34,"type":35}," There is no guidance at all; PEP 8 leaves line length entirely to team preference",[27,1214,1216,1218],{"className":1215},[30],[32,1217],{"disabled":34,"type":35}," 40 characters",[56,1220,1221,1223,1228],{},[59,1222,61],{},[63,1224,1225,1227],{},[66,1226,68],{}," A — 79 characters, with slightly more latitude (up to ~72) suggested for flowing text like docstrings and comments",[63,1229,1230,277,1232,1235],{},[66,1231,74],{},[66,1233,1234],{},"Idiom"," — PEP 8 recommends limiting lines to 79 characters (with long, flowing text such as comments\u002Fdocstrings recommended to wrap around 72), specifically to support side-by-side diffs and multiple open files. Option B is a common team override but not the PEP 8 default. Option C understates PEP 8, which does give a concrete number even though many real-world projects relax it. Option D is far stricter than PEP 8 actually recommends.",[14,1237,1238,1242,1260,1298],{"language":125},[17,1239,1241],{"id":1240},"q16-per-pep-8-naming-conventions-how-should-a-module-level-constant-be-named","Q16. Per PEP 8 naming conventions, how should a module-level constant be named?",[136,1243,1244],{"language":125},[139,1245,1247],{"className":141,"code":1246,"language":125,"meta":143,"style":143},"MAX_RETRIES = 3\n",[131,1248,1249],{"__ignoreMap":143},[147,1250,1251,1254,1257],{"class":149,"line":150},[147,1252,1253],{"class":153},"MAX_RETRIES",[147,1255,1256],{"class":258}," =",[147,1258,1259],{"class":153}," 3\n",[22,1261,1263,1272,1280,1289],{"className":1262},[25],[27,1264,1266,1268,1269],{"className":1265},[30],[32,1267],{"disabled":34,"type":35}," camelCase, e.g. ",[131,1270,1271],{},"maxRetries",[27,1273,1275,1277,1278],{"className":1274},[30],[32,1276],{"disabled":34,"type":35}," UPPER_SNAKE_CASE, e.g. ",[131,1279,1253],{},[27,1281,1283,1285,1286],{"className":1282},[30],[32,1284],{"disabled":34,"type":35}," PascalCase, e.g. ",[131,1287,1288],{},"MaxRetries",[27,1290,1292,1294,1295],{"className":1291},[30],[32,1293],{"disabled":34,"type":35}," Always underscore-prefixed, e.g. ",[131,1296,1297],{},"_maxretries",[56,1299,1300,1302,1309],{},[59,1301,61],{},[63,1303,1304,1306,1307],{},[66,1305,68],{}," B — UPPER_SNAKE_CASE, e.g. ",[131,1308,1253],{},[63,1310,1311,1313,1314,1316],{},[66,1312,74],{}," PEP 8 reserves UPPER_SNAKE_CASE for constants, snake_case for functions\u002Fvariables, and PascalCase (CapWords) for classes, so ",[131,1315,1253],{}," correctly signals \"constant\" to readers. Option A is the JavaScript convention, not Python's. Option C (PascalCase) is PEP 8's convention for class names, not constants. Option D's leading underscore signals \"internal\u002Fnon-public,\" an orthogonal concern to constant-ness.",[14,1318,1319,1323,1350],{},[17,1320,1322],{"id":1321},"q17-a-team-is-starting-a-brand-new-production-codebase-in-2026-which-major-version-should-they-target","Q17. A team is starting a brand-new production codebase in 2026. Which major version should they target?",[22,1324,1326,1332,1338,1344],{"className":1325},[25],[27,1327,1329,1331],{"className":1328},[30],[32,1330],{"disabled":34,"type":35}," Python 2, since it has been stable and unchanged for years",[27,1333,1335,1337],{"className":1334},[30],[32,1336],{"disabled":34,"type":35}," Python 3 — Python 2 reached official end-of-life in January 2020 and no longer receives security patches",[27,1339,1341,1343],{"className":1340},[30],[32,1342],{"disabled":34,"type":35}," Either is fine, since Python 2 and 3 source is fully interchangeable",[27,1345,1347,1349],{"className":1346},[30],[32,1348],{"disabled":34,"type":35}," It's irrelevant — CPython auto-detects and transparently runs either syntax",[56,1351,1352,1354,1359],{},[59,1353,61],{},[63,1355,1356,1358],{},[66,1357,68],{}," B — Python 3 — Python 2 reached official end-of-life in January 2020 and no longer receives security patches",[63,1360,1361,277,1363,1366,1367,1370,1371,1373,1374,1376],{},[66,1362,74],{},[66,1364,1365],{},"Safety"," — Python 2's \"stability\" in option A is really abandonment: it stopped receiving even security fixes after January 1, 2020, making it a liability for new production work. Option C is a myth; Python 2 and 3 have real syntactic and semantic differences (print, integer division, string types, etc.) that require porting, not blind compatibility. Option D is false — a ",[131,1368,1369],{},"python2","-only script (e.g., using the ",[131,1372,133],{}," statement) is a ",[131,1375,226],{}," under a Python 3 interpreter.",[14,1378,1379,1383,1410],{},[17,1380,1382],{"id":1381},"q18-when-is-it-appropriate-to-consider-pypy-instead-of-cpython-in-production","Q18. When is it appropriate to consider PyPy instead of CPython in production?",[22,1384,1386,1392,1398,1404],{"className":1385},[25],[27,1387,1389,1391],{"className":1388},[30],[32,1390],{"disabled":34,"type":35}," For a long-running, CPU-bound, pure-Python workload where JIT warm-up time is acceptable and speed matters — PyPy can substantially outperform CPython there",[27,1393,1395,1397],{"className":1394},[30],[32,1396],{"disabled":34,"type":35}," Always — PyPy is a strict superset of CPython with zero compatibility trade-offs, including every C-extension module",[27,1399,1401,1403],{"className":1400},[30],[32,1402],{"disabled":34,"type":35}," Never — PyPy cannot execute real-world Python code",[27,1405,1407,1409],{"className":1406},[30],[32,1408],{"disabled":34,"type":35}," Only for short-lived CLI scripts, since PyPy has effectively no startup cost",[56,1411,1412,1414,1419],{},[59,1413,61],{},[63,1415,1416,1418],{},[66,1417,68],{}," A — For a long-running, CPU-bound, pure-Python workload where JIT warm-up time is acceptable and speed matters — PyPy can substantially outperform CPython there",[63,1420,1421,277,1423,1425],{},[66,1422,74],{},[66,1424,803],{}," — PyPy's JIT needs time to warm up and profile hot paths before it pays off, so it shines on long-lived processes, not brief scripts (making option D backwards). Option B is the tempting-but-wrong choice: historically PyPy has had incomplete or slower support for CPython's C-extension API, so libraries with heavy C extensions (some numeric\u002Fscientific packages) are not automatically a free win — compatibility must be checked. Option C is simply false; PyPy runs the vast majority of pure-Python code correctly.",[14,1427,1428,1432,1454,1505],{"language":559},[17,1429,1431],{"id":1430},"q19-what-is-the-recommended-way-to-confirm-exactly-which-python-interpreter-and-version-will-run-a-project-especially-with-multiple-installs-or-virtual-environments-present","Q19. What is the recommended way to confirm exactly which Python interpreter and version will run a project, especially with multiple installs or virtual environments present?",[136,1433,1434],{"language":559},[139,1435,1437],{"className":572,"code":1436,"language":559,"meta":143,"style":143},"python --version\nwhich python\n",[131,1438,1439,1446],{"__ignoreMap":143},[147,1440,1441,1443],{"class":149,"line":150},[147,1442,125],{"class":583},[147,1444,1445],{"class":153}," --version\n",[147,1447,1448,1451],{"class":149,"line":592},[147,1449,1450],{"class":153},"which",[147,1452,1453],{"class":160}," python\n",[22,1455,1457,1474,1483,1492],{"className":1456},[25],[27,1458,1460,1462,1463,853,1466,1469,1470,1473],{"className":1459},[30],[32,1461],{"disabled":34,"type":35}," Run ",[131,1464,1465],{},"python --version",[131,1467,1468],{},"which python"," (or ",[131,1471,1472],{},"where python"," on Windows) to check both the version and the exact executable path in use",[27,1475,1477,1479,1480,1482],{"className":1476},[30],[32,1478],{"disabled":34,"type":35}," Assume the system ",[131,1481,125],{}," command always resolves to Python 3, since Python 2 was removed from every OS by 2021",[27,1484,1486,1488,1489,1491],{"className":1485},[30],[32,1487],{"disabled":34,"type":35}," Open a ",[131,1490,370],{}," file in a text editor and read the version header",[27,1493,1495,1497,1498,1500,1501,1504],{"className":1494},[30],[32,1496],{"disabled":34,"type":35}," Check the script's file extension — ",[131,1499,395],{}," always means Python 3, ",[131,1502,1503],{},".py2"," means Python 2",[56,1506,1507,1509,1520],{},[59,1508,61],{},[63,1510,1511,1513,1514,853,1516,1469,1518,1473],{},[66,1512,68],{}," A — Run ",[131,1515,1465],{},[131,1517,1468],{},[131,1519,1472],{},[63,1521,1522,277,1524,1526,1527,1529,1530,1532,1533,1535,1536,1538,1539,1541],{},[66,1523,74],{},[66,1525,1234],{}," — on many systems ",[131,1528,125],{}," may still resolve to Python 2, to a ",[131,1531,896],{}," shim, or to a virtual environment's interpreter, so checking both the reported version and the resolved binary path avoids running against the wrong interpreter. Option B is a real-world trap — some Linux distributions and older macOS installs kept ",[131,1534,125],{}," pointing at Python 2 well past its EOL. Options C and D describe checks that don't actually work; ",[131,1537,1503],{}," is not a recognized extension and ",[131,1540,370],{}," is binary, not readable version metadata.",[14,1543,1544,1548,1565,1603],{"language":559},[17,1545,1547],{"id":1546},"q20-what-is-the-idiomatic-way-to-explore-a-scripts-own-functionsclasses-interactively-without-retyping-all-of-its-definitions-at-the-prompt","Q20. What is the idiomatic way to explore a script's own functions\u002Fclasses interactively without retyping all of its definitions at the prompt?",[136,1549,1550],{"language":559},[139,1551,1553],{"className":572,"code":1552,"language":559,"meta":143,"style":143},"python -i script.py\n",[131,1554,1555],{"__ignoreMap":143},[147,1556,1557,1559,1562],{"class":149,"line":150},[147,1558,125],{"class":583},[147,1560,1561],{"class":153}," -i",[147,1563,1564],{"class":160}," script.py\n",[22,1566,1568,1578,1588,1594],{"className":1567},[25],[27,1569,1571,1573,1574,1577],{"className":1570},[30],[32,1572],{"disabled":34,"type":35}," Manually retype every class and function definition at the ",[131,1575,1576],{},">>>"," prompt each session",[27,1579,1581,1583,1584,1587],{"className":1580},[30],[32,1582],{"disabled":34,"type":35}," Use ",[131,1585,1586],{},"python -i script.py"," (or an enhanced shell like IPython) to run the script and then drop into an interactive session with its namespace already loaded",[27,1589,1591,1593],{"className":1590},[30],[32,1592],{"disabled":34,"type":35}," There is no way to combine a script with the REPL — they are mutually exclusive execution modes",[27,1595,1597,1599,1600,1602],{"className":1596},[30],[32,1598],{"disabled":34,"type":35}," Rename the script to ",[131,1601,370],{}," and import that file directly into the REPL",[56,1604,1605,1607,1614],{},[59,1606,61],{},[63,1608,1609,1611,1612,1587],{},[66,1610,68],{}," B — Use ",[131,1613,1586],{},[63,1615,1616,277,1618,1620,1621,1624,1625,1627,1628,1630],{},[66,1617,74],{},[66,1619,1234],{}," — the ",[131,1622,1623],{},"-i"," flag executes the given script and then hands control to an interactive prompt with all of that script's top-level names already bound, which is the standard way to poke at real project state without retyping code. Option A works but wastes effort and invites transcription errors. Option C is simply false. Option D doesn't work as described — you don't \"import\" a ",[131,1626,370],{}," by renaming a ",[131,1629,395],{},"; the cache format is an implementation detail, not a user-facing import mechanism.",[1632,1633,1634],"style",{},"html pre.shiki code .snvgF, html code.shiki .snvgF{--shiki-default:#005CC5;--shiki-github-dark:#79B8FF}html pre.shiki code .ssxIu, html code.shiki .ssxIu{--shiki-default:#24292E;--shiki-github-dark:#E1E4E8}html pre.shiki code .sJ6F3, html code.shiki .sJ6F3{--shiki-default:#032F62;--shiki-github-dark:#9ECBFF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .github-dark .shiki span {color: var(--shiki-github-dark);background: var(--shiki-github-dark-bg);font-style: var(--shiki-github-dark-font-style);font-weight: var(--shiki-github-dark-font-weight);text-decoration: var(--shiki-github-dark-text-decoration);}html.github-dark .shiki span {color: var(--shiki-github-dark);background: var(--shiki-github-dark-bg);font-style: var(--shiki-github-dark-font-style);font-weight: var(--shiki-github-dark-font-weight);text-decoration: var(--shiki-github-dark-text-decoration);}html pre.shiki code .svdQ7, html code.shiki .svdQ7{--shiki-default:#D73A49;--shiki-github-dark:#F97583}html pre.shiki code .sIsaT, html code.shiki .sIsaT{--shiki-default:#6F42C1;--shiki-github-dark:#B392F0}",{"title":143,"searchDepth":592,"depth":592,"links":1636},[1637,1638,1639,1641,1643,1645,1647,1648,1650,1652,1654,1656,1658,1660,1662,1663,1664,1665,1666,1667],{"id":19,"depth":598,"text":20},{"id":80,"depth":598,"text":81},{"id":128,"depth":598,"text":1640},"Q3. In Python 3, how must print be used?",{"id":238,"depth":598,"text":1642},"Q4. What does \u002F (true division) return in Python 3 when dividing two integers?",{"id":366,"depth":598,"text":1644},"Q5. What does a .pyc file contain?",{"id":423,"depth":598,"text":1646},"Q6. Where does CPython 3 store cached bytecode for an imported module named utils.py, by default?",{"id":510,"depth":598,"text":511},{"id":562,"depth":598,"text":1649},"Q8. At the interactive REPL, what does the special name _ refer to immediately after evaluating an expression?",{"id":678,"depth":598,"text":1651},"Q9. What determines whether CPython recompiles a module instead of reusing its cached .pyc, under the default (non hash-based) invalidation mode?",{"id":739,"depth":598,"text":1653},"Q10. Does the script you run directly (e.g., python app.py) get its own .pyc written to __pycache__?",{"id":823,"depth":598,"text":1655},"Q11. Two different Python versions, 3.9 and 3.11, both import the same utils.py from a shared __pycache__ directory. What happens?",{"id":902,"depth":598,"text":1657},"Q12. A developer deletes a stray __pycache__ directory before committing a project to git. Is this safe?",{"id":974,"depth":598,"text":1659},"Q13. Which statement correctly contrasts str between Python 2 and Python 3?",{"id":1075,"depth":598,"text":1661},"Q14. What is the effect of invoking the interpreter with the -O flag, e.g. python -O app.py?",{"id":1190,"depth":598,"text":1191},{"id":1240,"depth":598,"text":1241},{"id":1321,"depth":598,"text":1322},{"id":1381,"depth":598,"text":1382},{"id":1430,"depth":598,"text":1431},{"id":1546,"depth":598,"text":1547},"md",{},"\u002Fpython\u002F01-introduction-and-setup",{"title":5,"description":143},"python\u002F01-introduction-and-setup","yMQ8Hor4P5NFEEZ0_C9RQOFJ204AULep8Zd8rbOpUB0",1787335397338]