Fixed
This commit is contained in:
22
README.md
22
README.md
@@ -26,19 +26,19 @@ As in mames' original version, you can create such a __script__ easily:
|
||||
* __ruby_script__(YourCode) will encode it and add a "require"
|
||||
* __python_script__(YourCode) will encode it and add an "import"
|
||||
|
||||
If you have a file containing _ code, you can import it after importing
|
||||
_. Cool, huh?
|
||||
|
||||
The idea behind it is using Pythons import hooks to achieve something similar
|
||||
to mames' original script, only that it works the opposite way.
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
Issue `python setup.py install`(You might have to sudo).
|
||||
|
||||
Drawbacks
|
||||
---------
|
||||
Why is the code so ugly?
|
||||
------------------------
|
||||
|
||||
I still cope with Pythons' differences to Ruby. That means by now you have
|
||||
to keep the script as a string and give it to `_`'s `to_be_exec()` function.
|
||||
|
||||
Not cool, I know. I am working on it.
|
||||
|
||||
In case you are wondering why functions like `to_i()`and `to_s()` exist in
|
||||
the module. They are already more or less similarly implemented in Python
|
||||
itself. But I wanted to model the original modules' behaviour as far as possible,
|
||||
and for me that meant creating methods that behave similar to Rubys.
|
||||
That is due to me wanting the encoding and decoding be kept as close as possible
|
||||
to the original, even if the module has a completely different structure.
|
||||
|
Reference in New Issue
Block a user