I find this sad. In the JavaScript community the existence of Babel is very important for the long-term evolution of the language independently from the runtime. With Babel, JavaScript programmers can utilize new language syntax while being able to deploy on dated browsers. While there's always some experimentation, I doubt our community would abuse the new syntactic freedom that the PEP provided.
Then again, maybe we should do what Babel did, e.g. release a tool like it totally separately from the runtime.
I think the trick here would be getting people more comfortable with ahead-of-time compilation and then adding the appropriate support to bytecode files to load other "optimization" levels/tags. Then you load the .pyc files and rely on co_lnotab as Victor pointed out to get your source mapping by compiling your source code explicitly instead of as a side-effect of import. And since this approach would then just be about generalizing how to specify different tags to match against in .pyc file names it's easier to get accepted.
-Brett
- Ł
> On Oct 17, 2017, at 1:23 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
>
> Hi,
>
> I rejected my own PEP 511 "API for code transformers" that I wrote in
> January 2016:
>
> https://github.com/python/peps/commit/9d8fd950014a80324791d7dae3c130b1b64fdace
>
> Rejection Notice:
>
> """
> This PEP was rejected by its author.
>
> This PEP was seen as blessing new Python-like programming languages
> which are close but incompatible with the regular Python language. It
> was decided to not promote syntaxes incompatible with Python.
>
> This PEP was also seen as a nice tool to experiment new Python features,
> but it is already possible to experiment them without the PEP, only with
> importlib hooks. If a feature becomes useful, it should be directly part
> of Python, instead of depending on an third party Python module.
>
> Finally, this PEP was driven was the FAT Python optimization project
> which was abandonned in 2016, since it was not possible to show any
> significant speedup, but also because of the lack of time to implement
> the most advanced and complex optimizations.
> """
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/lukasz%40langa.pl
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org