-
-
Notifications
You must be signed in to change notification settings - Fork 516
Complete implementation of Python builtins #76
Comments
See also Ouroboros, a related project to develop a standalone, pure python version of the standard library. Ideally, it should be possible to use Ouroboros to generate the builtins and standard library. |
Where should the tests for these go? I was looking at adding tests for |
I think an entirely new test module is called for - something to parallel datatypes, stdlib and structures. There's probably enough tests for each method that |
I'm trying to figure out how comprehensive the tests are meant to be, since that affects how they should be defined. I quite like how the current UnaryOperationTestCase, etc are 'generating' all the possible combinations in a compact format, without cluttering up the individual test files. It means that we humans won't accidentally miss something out when implementing, particularly a strange edge/error case. However, I'm not sure whether to do that for functions/methods - I can imagine the combinations exploding quite quickly, especially if each argument is tested with all data types, and with all possible combinations of arguments. It seems like the fraction of tests that would result in exercising some kind of error or another might be quite high. (I've hacked up a |
For functions that take a single argument, I can see this being a good idea; however, it's going to get out of control pretty quickly once you move into functions with multiple arguments - if only because the multi-argument functions all have different combinations of arguments. If you can put together a variant of UnaryOperationTestCase that can validate the simple, single argument methods (the ones like abs, bool, and so on), I think that would be worthwhile; however, for the more complex methods, I think aiming for branch coverage is more than enough. |
I've implemented This works perfectly fine for all the basic types like
Output: ### EXCEPTION ###
- TypeError: bad operand type for abs(): 'test.NotAbsLike'
? -----
+ TypeError: bad operand type for abs(): 'NotAbsLike'
test.py:4 I guess this would affect all the other methods in |
I'd be interested to take a look at |
Refs #76 -- Implement hasattr builtin
Is this issue done now? Looks like all the builtins have been implemented as I see none with |
I would be interested in taking a look at |
Many built in's are not implemented yet, reading through org.Python I've found not implemented but method for telling so exists as:
ascii() using the following functions on voc using they trow
|
I am currently taking a look at |
Is the issue still open? If so, I'd like to help. |
Hello, After reading all the comments and checking the |
I want to take up this issue as my first challenge... But Can anyone guide me as I am totally new to open source contribution? |
Is the issue still open? |
Hi. I would be interested in taking a look at open() |
org.Python
is a Java implementation of all the Python builtins - methods likeprint()
,input()
,list()
,abs()
,min()
and so on.An implementation of these builtins is required.
The text was updated successfully, but these errors were encountered: