constants and functions in Python stdlib #55
Conversation
|
Will review after next Monday when my exams end. |
Good luck! |
src/stdlib.ts
Outdated
| /* | ||
| Create a map to hold built-in functions. | ||
| The keys are strings (function names) and the values are functions that can take any arguments. | ||
| */ | ||
| export const builtIns = new Map<string, (...args: any[]) => any>(); | ||
| builtIns.set('_int', _int); |
There was a problem hiding this comment.
Can you please put this into a JSON file? Called py_s1_constants.json or something like that?
That will make switching between Python S1 and Python s2 easier and also separate the code out clearer.
There was a problem hiding this comment.
Thanks for the suggestion! I’ll make the change to use a JSON file as you proposed.
src/stdlib.ts
Outdated
| expectedType = 'string'; | ||
| break; | ||
| case 'bool': | ||
| expectedType = 'bool'; |
There was a problem hiding this comment.
isinstance(True, int) is true in Python (bool is a subclass of int in CPython). Do we want to allow that?
There was a problem hiding this comment.
No... we follow Source Chapter 1
There was a problem hiding this comment.
Hmm, our current definition of "sublanguage" is like this:
A program that runs successfully using Python §1 in Source Academy should run successfully in the official Python implementation and produce the same result. (assuming that the correct sicp library is loaded that provides things like Math_sin)
By that reasoning, if we include isinstance in Python §1, any call of isinstance that succeeds in Python §1 should give the same result.
So currently, does isinstance(True, int) give an error, or does it give False in Python §1? An error would be consistent with our sublanguage notion, but False would not be.
There was a problem hiding this comment.
Hmm, our current definition of "sublanguage" is like this:
A program that runs successfully using Python §1 in Source Academy should run successfully in the official Python implementation and produce the same result. (assuming that the correct sicp library is loaded that provides things like Math_sin)
By that reasoning, if we include isinstance in Python §1, any call of isinstance that succeeds in Python §1 should give the same result.
So currently, does isinstance(True, int) give an error, or does it give False in Python §1? An error would be consistent with our sublanguage notion, but False would not be.
Thanks for the clarification. I will updated the implementation so that isinstance(True, int) now raises an error instead of returning False, to stay consistent with the sublanguage design.
src/stdlib.ts
Outdated
| export function math_acosh(args: Value[], source: string, command: ControlItem, context: Context): Value { | ||
| if (args.length < 1) { | ||
| handleRuntimeError(context, new MissingRequiredPositionalError(source, (command as es.Node), 'math_acosh', Number(1), args, false)); | ||
| } else if (args.length > 1) { | ||
| handleRuntimeError(context, new TooManyPositionalArgumentsError(source, (command as es.Node), 'math_acosh', Number(1), args, false)); | ||
| } |
There was a problem hiding this comment.
I noticed that for each of this, the argument parsing is mostly the same.
If so, can we add a decorator to do the argument parsing? Basically take a higher order function https://www.typescriptlang.org/docs/handbook/decorators.html.
Something like
@validate(1, "math_acosh") // 1 is the number of expected arguments.
export function math_acosh(...)
There was a problem hiding this comment.
Great suggestion — I’ll implement a @Validate decorator to handle the argument checking. Thanks for pointing it out!
…ct constants to py_s1_constants.json
I ran the full test suite and all tests passed, which suggests that the decorator-based validation and JSON-based constant loading didn’t introduce any regressions. This seems to validate the approach, and should also make future extension (e.g., for §2) cleaner. |
The detailed documentation for Python Chapter 1 stdlib is available at:
https://wangyuyang1013.github.io/py-slang-bak-2/docs/python/python_1/global.html
For the convenience of steps demonstration, I have temporarily pushed it to my personal GitHub repository.
Python Chapter 1 implements most of the Python
mathlibrary and some other built-in functions. Some functions were not included because their return types are not supported in Python Chapter 1 (e.g.,tuple), or because certain parameters only support keyword arguments (also not supported in Python Chapter 1).Most of the planned functions have been implemented. Only a few, such as
nextafterandulp, are still pending due to the complexity of implementing them without precision loss, andinput, as the conductor developer has not yet provided a way to read user input from the REPL.