-
Notifications
You must be signed in to change notification settings - Fork 25
Created a Python 3 version of scratch.py #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Very cool, thanks for the pull request. Do you know if your changes are compatible with Python 2.x? It would be nice to have the scratchpy module work in both Python 2 and 3 without a separate file. If you could make your changes to |
|
That's a good point. To be honest I'd just kind of assumed it wouldn't work with python 2, but I didn't try. There are some simple changes (consistency between tabs and spaces) which will still work in python 2, one change should work with a bit of reduced functionality (I had to drop the use of long for variables as python 3 only has int which is the equivalent of long on most systems), but the biggest change was from using strings to sequences of bytes. I'll take a look when I get a bit of spare time. I think it's unlikely but it would be a big plus if that was possible. |
|
I've done some testing and actually it does appear to work mostly with both Python 2 and Python 3. One restriction I mentioned earlier is the difference between how Python 3 handles integers versus Python 2. In the case of Python 2 the size of an integer depends upon the operating system integer size and scratchpy included long variable type for any numbers that were too large for an integer. Python 3 automatically handles any size of integer so it's not possible to have the long type included in the code. One thing that may be a problem, and which prevents the parsing.py tests from running, is that the error handling is also changed in Python 3. I've found some references which may suggest workarounds to allow these to be included in the same package. I'll take a look and let you know how I get on. |
|
Sounds like it's coming along well. When you get a chance, could you apply your changes to the |
|
Sorry it's been a while since my last update. I'm studying for an MSc and I've been heavily involved with workload especially C programming. I've now had a chance to update the code so that the same module can be used for both Scratch 2 and Scratch 3. I haven't sent a new PR, but it's a new commit 544dfe7. To compare using diff you will need to use --ignore-all-space (or similar option) as many of the lines have changed between tabs and spaces as python 3 requires consistency. I have done some basic testing so far, but if you have some more comprehensive tests that can be run then that would be useful. There are a few differences in how the module works - the main thing is a change in encoding and decoding the strings. Python 2 uses ASCII whereas Python 3 uses Unicode. I've left it that the module returns unicode (eg. from a broadcast from Scratch) and I believe that most code should handle that fine, although I am not sure if that could cause a problem. It should be possible to update the parsing code to return ASCII for Scratch 2 only if it is an issue, although if it works as Unicode I think that may be better. Another change is in the exception handling. The Python 2 provides the same traceback output as your current version, but on Python 3 both exceptions are included in the Traceback. This is a feature of Python 3 and if the exception is handled in the user code then it works correctly. There will still need to be some changes in the setup.py etc., but if you want to test the code to see if it still works with any Scratch 2 code you have I can then look at updating that as well. Stewart |
Thanks for creating ScratchPy.
I have a project that requires libraries only available in Python 3 so I have converted your code to a module that can be used in Python 3. I have named the file scratchpy3.py so that it doesn't conflict with the current version, but I have not updated the setup.py file which will also be needed to allow automatic install using pip3 if you are interested in merging this into your code.
Functionality is essentially the same as your version, although due to the way that python 3 interprets iter objects I have changed the detection of iter objects to instead look for tuple, list and set. Otherwise a broadcast string was split into each character.