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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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> > _______________________________________ > |
|
|