This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pfalcon
Recipients BTaskaya, lys.nikolaou, pablogsal, pfalcon, serhiy.storchaka
Date 2020-12-24.13:30:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1608816634.37.0.266647739513.issue42729@roundup.psfhosted.org>
In-reply-to
Content
> There is a considerable tension on exposed parts of the compiler pipeline for introspection and other capabilities and our ability to do optimizations. Given how painful it has been in the past to deal with this, my view is to avoid exposing as much as possible anything in the compiler pipeline, so we don't shoot ourselves in the foot in the future if we need to change stuff around.

That's somewhat extreme outcome when a problem is known and understood, but the best solution is deemed not doing anything.

But the problem of "doing it wrong" definitely known and exists. One known way to address it is to design generic interfaces and implement them. This ticket is exactly about that - defining a missing interface for a parser in Python. It's not about *the* CPython's C parser and its peculiarities. (But even it fits with the generic interface proposed.)
History
Date User Action Args
2020-12-24 13:30:34pfalconsetrecipients: + pfalcon, serhiy.storchaka, lys.nikolaou, pablogsal, BTaskaya
2020-12-24 13:30:34pfalconsetmessageid: <1608816634.37.0.266647739513.issue42729@roundup.psfhosted.org>
2020-12-24 13:30:34pfalconlinkissue42729 messages
2020-12-24 13:30:33pfalconcreate