I'm a french teacher and I would like to use Python with young child but
I've a big problem. All the keyword are in english. So I would like to know
if there is a way to hack the AST tools such as to use french keywords and
then translate a list of french keywords to their english regular version.
Where should I start ? My idea is not to build a new language but simply
translate words using an hacked version of the AST tools.
Hoping to be clear and I do not pollute the message in this list.
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*French math teacher in a "Lycée" **and **Python **amateur developer*
Just wanted to share some documentation I’ve put together (and a snapshot of the code) on the effort to improve the appearance and behaviour of IDLE:
(There’s also currently a post on Hacker News about this).
While Terry can better speak to plans and timelines about getting these changes integrated in, it seems a good time to get some other people to have a closer look and share any feedback.
MicroPython is a lean and efficient Python implementation for
microcontrollers, embedded, and mobile systems (which also runs just as
fine on desktops of course).
Recent 1.5 release is an important milestone for the project, major
1. Advanced REPL support with smart auto-indent and auto-completion for
comfortable interactive typing pf Python code, easily switchable to
paste mode to copy pre-made code snippets.
2. Support for client SSL connections.
3. upip, MicroPython builtin package manager, is now fully standalone
thanks to SSL support.
4. There's new, elaborated API to access hardware features ("machine"
5. There're now 2 well-supported microcontroller boards for
MicroPython, and dozen(s) community-supported ones.
6. MicroPython was selected as one of the languages supported for BBC
7. There's work on native efficient JNI bridge, inspired by Kivy's
PyJNIus module, included into growing Android port.
More detailed changelog for this version is at
MicroPython supports growing subset of Python3 standard library
(including simplified asyncio package) - not included by default with
an executable, but easily installable per-module using builtin "upip"
> I'm not suggesting restarting at the top (I've elsewhere suggested that
> many such methods would be better as an *iterable* that can be restarted
> at the top by calling iter() multiple times, but that's not the same
> thing). I'm suggesting raising an exception other than StopIteration, so
> that this situation can be detected. If you are writing code that tries
> to resume iterating after the iterator has been exhausted, I have to
> ask: why?
The most obvious case for me would be tailing a file. Loop over the lines
in the file, sleep, then do it again. There are many tasks analogous to
that scenario -- anything querying a shared resource.
While working on the FAT Python project to try to optimize CPython, I
have an issue with the cached .pyc files. I would like to have one
.pyc without optimization when the FAT mode is disabled (default) and
one .pyc with optimization when the FAT mode is enabled (-F command
line option). Currently, I'm using this filenames:
- Lib/__pycache__/os.cpython-36.pyc: default mode
- Lib/__pycache__/os.cpython-36.fat-0.pyc: FAT mode
- Lib/__pycache__/os.cpython-36.opt-1.pyc: default mode
- Lib/__pycache__/os.cpython-36.fat-1.pyc: FAT mode
- Lib/__pycache__/os.cpython-36.opt-2.pyc: default mode
- Lib/__pycache__/os.cpython-36.fat-2.pyc: FAT mode
Is it the "correct" way to name .pyc files? I had to modify unit tests
which expected an exact filename.
An alternative would be to add a new dot:
Or should I add a flag to the cache tag ("cpython-36")?
CPython adds the "d" suffix to the cache tag in debug build, but in my
case the flag would be added dynamically at Python startup. The FAT
mode is enabled by the -F command line option, not by a compilation
I'm writing a new "FAT Python" project to try to implement optimizations in
CPython (inlining, constant folding, move invariants out of loops, etc.)
using a "static" optimizer (not a JIT). For the background, see the thread
See also the documentation:
I implemented the most basic optimization to test my code: replace calls to
builtin functions (with constant arguments) with the result. For example,
len("abc") is replaced with 3. I reached the second milestone: it's now
possible to run the full Python test suite with these optimizations
enabled. It confirms that the optimizations don't break the Python semantic.
>>> def func():
... return len("abc")
>>> import dis
2 0 LOAD_GLOBAL 0 (len)
3 LOAD_CONST 1 ('abc')
6 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
2 0 LOAD_CONST 1 (3)
>>> len=lambda obj: "mock"
The function func() has specialized bytecode which returns directly 3
instead of calling len("abc"). The specialized bytecode has two guards
dictionary keys: builtins.__dict__['len'] and globals()['len']. If one of
these keys is modified, the specialized bytecode is simply removed (when
the function is called) and the original bytecode is executed.
You cannot expect any speedup at this milestone, it's just to validate the
implementation. You can only get speedup if you implement *manually*
optimizations. See for example posixpath.isabs() which inlines manually the
call to the _get_sep() function. More optimizations will be implemented in
the third milestone. I don't know yet if I will be able to implement
constant folding, function inlining and/or moving invariants out of loops.
Download, compile and test FAT Python with:
hg clone http://hg.python.org/sandbox/fatpython
./configure && make && ./python -m test test_astoptimizer test_fat
Currently, only 24 functions are specialized in the standard library.
Calling a builtin function with constant arguments in not common (it was
expected, it's only the first step for my optimizer). But 161 functions are
specialized in tests.
To be honest, I had to modify some tests to make them pass in FAT mode. But
most changes are related to the .pyc filename, or to the exact size in
bytes of dictionary objects.
FAT Python is still experimental. Currently, the main bug is that the AST
optimizer can optimize a call to a function which is not the expected
builtin function. I already started to implement code to understand
namespaces (detect global and local variables), but it's not enough yet to
detect when a builtin is overriden. See TODO.rst for known bugs and