Issue 28964: AST literal_eval exceptions provide no information about line number (original) (raw)

Created on 2016-12-13 21:47 by stevemerritt, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
mywork.patch stevemerritt,2016-12-13 21:47 review
Pull Requests
URL Status Linked Edit
PR 23677 merged iritkatriel,2020-12-07 13:10
Messages (13)
msg283142 - (view) Author: Steve Merritt (stevemerritt) * Date: 2016-12-13 21:47
Without line numbers, debugging syntax errors in large documents is a tedious and painful process.
msg284419 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2017-01-01 03:28
Thanks for the patch, Steve!. This looks like a reasonable request to me, but 1) we can only make this change in 3.7 2) we need a test case for the new message 3) you can use f-strings instead of str.format()
msg284422 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-01 07:41
Usually literal_eval() is used with short one-line input. For what large documents do you use it?
msg284430 - (view) Author: Steve Merritt (stevemerritt) * Date: 2017-01-01 22:11
We're using Python dictionaries to express sizeable (read: 100-600 lines) chunks of configuration data. We previously used JSON, but we now use Jinja2 to template chunks of this configuration data, and JSON's inability to handle trailing commas creates a problem here. So we've been using ast.literal_eval, but the lack of line numbers makes debugging problems with the configurations a painful process. On Sun, Jan 1, 2017 at 2:41 AM Serhiy Storchaka <report@bugs.python.org> wrote: > > Serhiy Storchaka added the comment: > > Usually literal_eval() is used with short one-line input. For what large > documents do you use it? > > ---------- > nosy: +serhiy.storchaka > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue28964> > _______________________________________ >
msg292330 - (view) Author: Louie Lu (louielu) * Date: 2017-04-26 10:13
Steve, will you work on this patch to GitHub?
msg292381 - (view) Author: Steve Merritt (stevemerritt) * Date: 2017-04-26 17:59
I'll try to get to it this weekend. A bit swamped on another project right now. Thanks for the interest and the reminder!
msg377110 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-09-18 12:00
Steve, are you planning to work on porting this patch to github? Note: it would need a unit test, and also node is not guaranteed to have a lineno field.
msg382630 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-12-07 13:14
> Usually literal_eval() is used with short one-line input. For what large documents do you use it? I kind of agree with Serhiy on this, nearly every use case I've encountered was simple, single-line expression. Though, by seeing Irit's patch I think the implementation is reasonable enough to do.
msg382631 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-12-07 13:16
This just came up again in so I went ahead and created the PR.
msg383587 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-12-22 12:44
I'm +0 on this (even though we only had 2 users wanting this, the implementation seems very trivial). @serhiy.storchaka, @pablogsal any opinions?
msg383589 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-12-22 14:02
This is a recurring feature request (I have heard people asking for this a couple of times) and is simple enough to do, so I am fine with this. Unless Serhiy has some concern, I would go forward :)
msg383754 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-12-25 17:04
New changeset 586f3dbe15139cafb2a6ffb82cea146906561844 by Irit Katriel in branch 'master': bpo-28964: add line number of node (if available) to ast.literal_eval error messages (GH-23677) https://github.com/python/cpython/commit/586f3dbe15139cafb2a6ffb82cea146906561844
msg383854 - (view) Author: Steve Merritt (stevemerritt) * Date: 2020-12-27 17:27
Thank you! On Fri, Dec 25, 2020 at 11:05 AM Batuhan Taskaya <report@bugs.python.org> wrote: > > Change by Batuhan Taskaya <isidentical@gmail.com>: > > > ---------- > resolution: -> fixed > stage: patch review -> resolved > status: open -> closed > > _______________________________________ > Python tracker <report@bugs.python.org> > <https://bugs.python.org/issue28964> > _______________________________________ >
History
Date User Action Args
2022-04-11 14:58:40 admin set github: 73150
2020-12-27 17:27:50 stevemerritt set messages: +
2020-12-25 17:05:11 BTaskaya set status: open -> closedresolution: fixedstage: patch review -> resolved
2020-12-25 17:04:34 BTaskaya set messages: +
2020-12-22 14:02:47 pablogsal set messages: +
2020-12-22 12:44:49 BTaskaya set keywords: + patch, - gsoc
2020-12-22 12:44:30 BTaskaya set keywords: + gsoc, - patchnosy: + pablogsalmessages: +
2020-12-07 14:01:24 iritkatriel set versions: + Python 3.10, - Python 3.7
2020-12-07 13:16:04 iritkatriel set messages: +
2020-12-07 13:14:54 BTaskaya set nosy: + BTaskayamessages: +
2020-12-07 13:10:34 iritkatriel set pull_requests: + <pull%5Frequest22543>
2020-12-07 00:09:50 iritkatriel link issue42561 superseder
2020-09-18 12:00:41 iritkatriel set status: pending -> opennosy: + iritkatrielmessages: +
2019-08-31 11:26:14 serhiy.storchaka set status: open -> pending
2017-04-26 17:59:06 stevemerritt set messages: +
2017-04-26 10:13:59 louielu set nosy: + louielumessages: +
2017-03-15 06:46:47 mbdevpl set nosy: + mbdevpl
2017-01-01 22:11:46 stevemerritt set messages: +
2017-01-01 07:41:51 serhiy.storchaka set nosy: + serhiy.storchakamessages: +
2017-01-01 03:28:55 berker.peksag set versions: + Python 3.7, - Python 2.7nosy: + berker.peksagmessages: + type: behavior -> enhancementstage: patch review
2016-12-13 21:47:44 stevemerritt create