◐ Shell
reader mode source ↗
Skip to content

bpo-32888: Improve exception message in ast.literal_eval#340

Closed
Rosuav wants to merge 4 commits into
python:masterfrom
Rosuav:literal_eval-exception
Closed

bpo-32888: Improve exception message in ast.literal_eval#340
Rosuav wants to merge 4 commits into
python:masterfrom
Rosuav:literal_eval-exception

Conversation

@Rosuav

@Rosuav Rosuav commented Feb 27, 2017

Copy link
Copy Markdown
Contributor

When a non-literal is given to literal_eval, attempt to be more
helpful with the message, rather than calling it 'malformed'.

https://bugs.python.org/issue32888

@merwok

merwok commented Feb 18, 2018

Copy link
Copy Markdown
Member

This looks good, do you mind opening a bugs.python.org ticket and adding a news entry?

@Rosuav Rosuav changed the title Improve exception message in ast.literal_eval Feb 20, 2018
When a non-literal is given to literal_eval, attempt to be more
helpful with the message, rather than calling it 'malformed'.
@Rosuav Rosuav force-pushed the literal_eval-exception branch from b9b6e9d to 26ba98e Compare February 20, 2018 17:41
@Rosuav

Rosuav commented Feb 20, 2018

Copy link
Copy Markdown
Contributor Author

Rebased onto current master, which includes shifting where the actual change happens. NEWS entry added, issue number added.

@serhiy-storchaka serhiy-storchaka left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hide comment

Please add a special test in test_ast.

@briancurtin briancurtin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hide comment

Overall this looks good, just one suggestion on the test implementation.

@bedevere-bot

Copy link
Copy Markdown

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@csabella

Copy link
Copy Markdown
Contributor

@Rosuav, please address the last change request by @briancurtin and also rebase to fix the conflict. Thanks!

@Rosuav

Rosuav commented May 13, 2019

Copy link
Copy Markdown
Contributor Author

BPO cites another couple of issues, one of which is still open, as dependencies. And it's not really a high priority - it's nothing more than a nice-to-have. There are a lot of barriers to getting patches accepted and it's often not worth the effort unless you REALLY care about the patch.

@merwok

merwok commented May 13, 2019

Copy link
Copy Markdown
Member

(Note that you can rebase or do a regular merge, which is often easier! All PRs are squash merged in the end @csabella)

@merwok

merwok commented May 13, 2019

Copy link
Copy Markdown
Member

@serhiy-storchaka Should this wait for bpo-32893 per your last message on the ticket or could it be merged soon? (when conflicts are resolved + suggestion from Brian)

@vstinner

Copy link
Copy Markdown
Member

A different approach using ast.dump(): PR #16620.

@vstinner

Copy link
Copy Markdown
Member

What's the status of this PR?

@Rosuav: Are you still working on this?


A different approach using ast.dump(): PR #16620.

Oh, I just closed it since it could produce very long error message: https://bugs.python.org/issue38396#msg354132

@Rosuav

Rosuav commented Dec 14, 2019

Copy link
Copy Markdown
Contributor Author

No, I'm not. It was a nice-to-have but between the pushback (no core dev seemed to want it to happen) and the constant need to fix merge conflicts meant that I abandoned this proposal ages ago. If someone else wants to champion this fix, then sure, but I don't have the energy to push everything, and this one wasn't worth it.

@vstinner

Copy link
Copy Markdown
Member

@isidentical: Are you interested to take over this change? I'm not the good candidate to review it. Maybe @pablogsal or @serhiy-storchaka.

@isidentical

Copy link
Copy Markdown
Member

Sure.

@csabella

Copy link
Copy Markdown
Contributor

Closing this pull request as it is now GH-17662.

@csabella csabella closed this Jan 12, 2020
jaraco pushed a commit that referenced this pull request Dec 2, 2022
Bumps [celery](https://github.com/celery/celery) from 4.4.3 to 4.4.4.
- [Release notes](https://github.com/celery/celery/releases)
- [Changelog](https://github.com/celery/celery/blob/master/Changelog.rst)
- [Commits](celery/celery@4.4.3...v4.4.4)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
SonicField added a commit to SonicField/cpython that referenced this pull request May 12, 2026
v2.1.1 single-rule extension to A10 per supervisor 01:05:42Z 2026-05-12
+ pythia python#341 independent-push-window observation. Authored under
structural escalation from pythia python#335(c) (POST-A10 empirical class-
repeat trigger): 7th feedback_fabrication_detector_verify instance
(supervisor self at 22:36Z) was the 1st POST-A10-codification instance.

A10.1: when issuing CONFIRMED-FABRICATION verdict (per A10 trigger),
verdict post MUST inline (a) verbatim git command output snippet
supporting the accusation, (b) explicit HEAD-at-claim disambiguation
distinguishing claim-time HEAD from current HEAD when they differ.
Closes the python#340(2) grep-scope-mismatch gap that produced both
POST-A10 incidents (librarian 21:26Z + supervisor 22:36Z self-violation).

Explicit non-coverage: routine verification claims (gate posts, state
reports, ABBA results, build-status, push-verify) remain governed by
feedback_no_tool_execution_citation (Alex 2026-04-29 directive). A10.1
verbatim-snippet requirement is FABRICATION-VERDICT-CLASS-ONLY, not
generic. The two rules coexist via claim-class distinction.

Adoption record updated to note v2.1.1 amendment on top of v2.1 352cc1f.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants