Missing builtins
print(list("ab")) # CPython ['a', 'b'] minipy NameError: name "list" is not defined
print(tuple([1, 2])) # CPython (1, 2) minipy NameError: name "tuple" is not defined
print(type(1)) # CPython <class 'int'> minipy NameError: name "type" is not defined
print(int("1f", 16)) # CPython 31 minipy TypeError: int() takes exactly 1 argument(s) (2 given)
super() likewise:
class A:
def f(self) -> int:
return 1
class B(A):
def f(self) -> int:
return super().f() + 1
print(B().f()) # CPython 2 minipy NameError: name "super" is not defined
Their absence is currently baked into docs/conformance.md's authoring rules, which forbid corpus cases from using any of them — so this blocks corpus coverage as much as it blocks user code.
Implementation shape
Each needs a callSymbol entry in builtins/builtins.go (the pow entry at :54 shows the spec / result-type / emit shape), a checker result rule, an emit or host implementation, and tests.
Two are not mechanical:
super() — minipy dispatches methods statically and precomputes class-ID intervals (computeClassIntervals, compiler/check_decl.go:161). super().m() should resolve at compile time to the base class's method, i.e. a direct funcValue + CALL, not a runtime proxy object. A first-class super object would need the dynamic object model that docs/roadmap.md puts out of scope.
type() — returning a first-class class value is out of scope for the same reason. Scope this to what is statically decidable and useful (type(x) == type(y), printing <class 'int'> for the known-type case), or document the restriction rather than shipping a half-dynamic version.
list()/tuple()/dict()/set() should cover both the empty form and the from-iterable form; dict()/set() from an iterable interact with the dict/set iteration-order divergence, so their conformance cases must sort before printing.
Verification
go test ./builtins ./compiler
go test ./conformance -run TestGoldensMatchCPython
Once these land, remove the corresponding prohibitions from docs/conformance.md's authoring rules and update docs/compatibility.md.
Part of #49 (Phase D, item 7).
Missing builtins
super()likewise:Their absence is currently baked into
docs/conformance.md's authoring rules, which forbid corpus cases from using any of them — so this blocks corpus coverage as much as it blocks user code.Implementation shape
Each needs a
callSymbolentry inbuiltins/builtins.go(thepowentry at:54shows thespec/ result-type / emit shape), a checker result rule, an emit or host implementation, and tests.Two are not mechanical:
super()— minipy dispatches methods statically and precomputes class-ID intervals (computeClassIntervals,compiler/check_decl.go:161).super().m()should resolve at compile time to the base class's method, i.e. a directfuncValue+CALL, not a runtime proxy object. A first-classsuperobject would need the dynamic object model thatdocs/roadmap.mdputs out of scope.type()— returning a first-class class value is out of scope for the same reason. Scope this to what is statically decidable and useful (type(x) == type(y), printing<class 'int'>for the known-type case), or document the restriction rather than shipping a half-dynamic version.list()/tuple()/dict()/set()should cover both the empty form and the from-iterable form;dict()/set()from an iterable interact with the dict/set iteration-order divergence, so their conformance cases must sort before printing.Verification
Once these land, remove the corresponding prohibitions from
docs/conformance.md's authoring rules and updatedocs/compatibility.md.Part of #49 (Phase D, item 7).