[issue226619] Dict methods have no __doc__ strings

[admin]

Change by admin :


--
github: None -> 33627

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue223634] Pickle broken on Unicode strings

[admin]

Change by admin :


--
github: None -> 33516

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue229000] struct should handle terminated strings

[admin]

Change by admin :


--
github: None -> 33735

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue403247] Strings: '\012' -> '\n'

[admin]

Change by admin :


--
github: None -> 33725

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue216388] cStringIO rejects Unicode strings

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue221207] % operator on strings not documented

[admin]

Change by admin :


--
github: None -> 33443

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue222162] split is broken for unicode strings

[admin]

Change by admin :


--
github: None -> 33462

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue213786] copy.py doesn't support unicode strings

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue213829] hasattr() doesn't accept Unicode strings

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401320] Translate doc strings

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401264] Attribute Doc-Strings (PEP 224)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210643] compiling long strings crashes (PR#32)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400638] Doc strings added by Nils Fischbeck

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400706] minidom __repr__ returns Unicode strings

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue223634] Pickle broken on Unicode strings

[admin]

Change by admin :


--
github: None -> 33516

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue222162] split is broken for unicode strings

[admin]

Change by admin :


--
github: None -> 33462

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue217004] Tools/compiler does not create doc strings

[admin]

Change by admin :


--
github: None -> 33353

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue216388] cStringIO rejects Unicode strings

[admin]

Change by admin :


--
github: None -> 33313

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue213786] copy.py doesn't support unicode strings

[admin]

Change by admin :


--
github: None -> 33059

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue213829] hasattr() doesn't accept Unicode strings

[admin]

Change by admin :


--
github: None -> 33072

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401309] Specialization of dictionaries for strings.

[admin]

Change by admin :


--
github: None -> 32989

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401264] Attribute Doc-Strings (PEP 224)

[admin]

Change by admin :


--
github: None -> 32973

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401320] Translate doc strings

[admin]

Change by admin :


--
github: None -> 32995

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401299] add missing test for strings in file_writelines

[admin]

Change by admin :


--
github: None -> 32986

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210643] compiling long strings crashes (PR#32)

[admin]

Change by admin :


--
github: None -> 32714

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210661] cgi parsing of query strings (PR#356)

[admin]

Change by admin :


--
github: None -> 32731

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400912] modified \x behaviour for unicode strings

[admin]

Change by admin :


--
github: None -> 32630

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400706] minidom __repr__ returns Unicode strings

[admin]

Change by admin :


--
github: None -> 32506

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400638] Doc strings added by Nils Fischbeck

[admin]

Change by admin :


--
github: None -> 32458

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27132] New assert method that checks an error message for a list of strings

[Irit Katriel]

Irit Katriel  added the comment:

> Personally I'd write multiple asserts rather than regex permutations.

I would too, because then when one of them fails it's clear which of the 
strings is missing.

--
nosy: +iritkatriel

___
Python tracker 
<https://bugs.python.org/issue27132>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37789] Update doc strings for test.bytecode_helper

[Irit Katriel]

Irit Katriel  added the comment:

This has been fixed by now.

--
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35212] Expressions with format specifiers in f-strings give wrong code position in AST

[Eric V. Smith]

Change by Eric V. Smith :


--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Incorrect exception highlighting for fstring format

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35212] Expressions with format specifiers in f-strings give wrong code position in AST

[Daniël van Noord]

Daniël van Noord  added the comment:

This was fixed by https://github.com/python/cpython/pull/27729.

On 3.10:
```console
>>> ast.parse("f'{a}'").body[0].value.values[0].value.col_offset
3
>>> ast.parse("f'{a:b}'").body[0].value.values[0].value.col_offset
3
```

The other issue also no longer reproduces.

--
message_count: 3.0 -> 4.0
nosy: +danielnoord
nosy_count: 5.0 -> 6.0
pull_requests: +30022
pull_request: https://github.com/python/cpython/pull/27729

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46978] Doc strings for built-in, in-place operators are misleading

[Nicko van Someren]

Change by Nicko van Someren :


--
keywords: +patch
pull_requests: +29903
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31802

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46978] Doc strings for built-in, in-place operators are misleading

[Nicko van Someren]

New submission from Nicko van Someren :

Objects/typeobject.c uses slots to implement various operators and the IBSLOT 
macro is used to define slot entries for in-place binary operators. This macro 
creates a __doc__ string for the operators of the form "Return selfvalue."

This doc string is misleading since an in-place operator statement can not be 
used as an L-value, so nothing is "returned".

To fix this, the macro definition for IBSLOT should be updated to use a 
different word or phrase, such as "Compute selfvalue."

--
components: Interpreter Core
messages: 414876
nosy: nickovs
priority: normal
severity: normal
status: open
title: Doc strings for built-in, in-place operators are misleading
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue46978>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46962] Fix docstrings that do not honor --without-doc-strings

[Oleg Iarygin]

Change by Oleg Iarygin :


--
keywords: +patch
pull_requests: +29877
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31769

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46962] Fix docstrings that do not honor --without-doc-strings

[Oleg Iarygin]

New submission from Oleg Iarygin :

To support `--without-doc-strings`, all docstrings must be wrapped into 
`PyDoc_STRVAR` or `PyDoc_STR` (PEP 7). However, there are 18 occurrences in 
code and 10 in C API documentation that do not follow this rule. The 
documentation is important too because it should not teach people the wrong 
things.

To find the occurrences I searched for `(?:^\s*.tp_doc = "|" \/\* tp_doc 
\*\/$)` and`^(?:static\s+)?const\s+char\s+[^=]+=\s*"`.

--
assignee: docs@python
components: Documentation, Extension Modules, Interpreter Core
messages: 414768
nosy: arhadthedev, docs@python
priority: normal
severity: normal
status: open
title: Fix docstrings that do not honor --without-doc-strings
type: behavior
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46962>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests:  -29803

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +29803
pull_request: https://github.com/python/cpython/pull/31683

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

> PEP 587 introduced PyStatus to Python startup code which let the 
> Py_Initialize() caller to decide how to handle errors ;-) For example, you 
> can open a graphical popup rather than killing the process with SIGABRT 
> (Py_FatalError() behavior) which might be more user friendly :-D Or just log 
> the error.

That's up to pycore_interp_init() in pylifecycle.c now. Kumar called 
_PyStatus_ERR() there, so I think nothing more needs to be done.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> The other functions you are calling *do* return errors. You should not ignore 
> those. If any errors are reported the caller can decide what to do (e.g. call 
> Py_FatalError().

PEP 587 introduced PyStatus to Python startup code which let the 
Py_Initialize() caller to decide how to handle errors ;-) For example, you can 
open a graphical popup rather than killing the process with SIGABRT 
(Py_FatalError() behavior) which might be more user friendly :-D Or just log 
the error.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

commit 0d9b565e62a5fc8c3e9b8c64cce764fe084ccb2b
Author: Kumar Aditya <59607654+kumaraditya...@users.noreply.github.com>
Date:   Sat Feb 26 22:05:03 2022 +0530

Propagate errors (however unlikely) from _Py_Deepfreeze_Init() (GH-31596)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Change by Guido van Rossum :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Change by Kumar Aditya :


--
pull_requests: +29719
pull_request: https://github.com/python/cpython/pull/31596

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

> How it should be handled? Currently PyUnicode_InternInPlace ignores any 
> errors and does not return it. It would be backwards-incompatible to change 
> that, moreover as I explained in 
> https://github.com/python/cpython/pull/30683#discussion_r800648477 
> intern_strings only check if all the items are strings which will be always 
> true in case of deep-freeze so I don't think anything needs to be changed 
> here. I would be interested to know if I am missing something though.

The other functions you are calling *do* return errors. You should not ignore 
those. If any errors are reported the caller can decide what to do (e.g. call 
Py_FatalError().

--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

I wrote https://github.com/python/cpython/pull/31555 to make sure that Python 
doesn't leak at Python exit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +29678
pull_request: https://github.com/python/cpython/pull/31556

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4dc746310bd37ad6b381f9176acd167d445f4385 by Kumar Aditya in 
branch 'main':
bpo-46430: Fix memory leak in interned strings of deep-frozen modules (GH-31549)
https://github.com/python/cpython/commit/4dc746310bd37ad6b381f9176acd167d445f4385


--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Kumar Aditya  added the comment:

> Okay, let's change the error handling. @Kumar, can you handle that?

How it should be handled? Currently PyUnicode_InternInPlace ignores any errors 
and does not return it. It would be backwards-incompatible to change that, 
moreover as I explained in 
https://github.com/python/cpython/pull/30683#discussion_r800648477 
intern_strings only check if all the items are strings which will be always 
true in case of deep-freeze so I don't think anything needs to be changed here. 
I would be interested to know if I am missing something though.

--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Kumar Aditya  added the comment:

I have created a PR to fix the memory leak, See 
https://github.com/python/cpython/pull/31549

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Change by Kumar Aditya :


--
pull_requests: +29670
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31549

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

I tried to hack _PyStaticCode_Dealloc() to free strings, but since immortal 
objects are half-baken today, calling Py_DECREF() does crash.

Py_SETREF() should increase _Py_RefTotal if the old object is immortal and he 
new object is not.

Maybe this change should be reverted until Eric's PEP 683 "Immortal Objects, 
Using a Fixed Refcount" is implemented.

--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

PyUnicode_InternInPlace() in intern_strings() can convert an immortal string to 
a regular Python strong reference, whereas _PyStaticCode_Dealloc() doesn't 
bother with clearing co_names, co_consts and co_localsplusnames.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

That's pretty mysterious. The deep-freeze code isn't on the stack for either of 
those, but allocation of new unicode string objects is. I'm guessing these are 
somehow leaked by the interning, but I don't follow yet how.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the 
> deep-frozen memory -- the solution must be to update the accounting somewhere.

Python allocates memory (ex: with PyObject_Malloc()) which is not released at 
exit. Two examples from Valgrind:

==196803== 50 bytes in 1 blocks are still reachable in loss record 1 of 87
==196803==at 0x484486F: malloc (vg_replace_malloc.c:381)
==196803==by 0x544E29: _PyMem_RawMalloc (obmalloc.c:101)
==196803==by 0x545E0E: PyObject_Malloc (obmalloc.c:700)
==196803==by 0x587159: PyUnicode_New (unicodeobject.c:1448)
==196803==by 0x58C4CF: get_latin1_char (unicodeobject.c:2148)
==196803==by 0x58D7F7: _PyUnicode_FromUCS1 (unicodeobject.c:2450)
==196803==by 0x58E374: PyUnicode_FromKindAndData (unicodeobject.c:2525)
==196803==by 0x69402B: r_object (marshal.c:1150)
==196803==by 0x694295: r_object (marshal.c:1212)
==196803==by 0x694AE0: r_object (marshal.c:1393)
==196803==by 0x694295: r_object (marshal.c:1212)
==196803==by 0x694AA4: r_object (marshal.c:1387)
==196803==by 0x6950F3: read_object (marshal.c:1524)
==196803==by 0x6953E7: PyMarshal_ReadObjectFromString (marshal.c:1641)
==196803==by 0x763223: _Py_Get_Getpath_CodeObject (getpath.c:792)
==196803==by 0x76337F: _PyConfig_InitPathConfig (getpath.c:847)
==196803==by 0x68CD04: config_init_import (initconfig.c:1967)
==196803==by 0x68CE4E: _PyConfig_InitImportConfig (initconfig.c:2000)
==196803==by 0x69E594: init_interp_main (pylifecycle.c:1103)
==196803==by 0x69EBF8: pyinit_main (pylifecycle.c:1216)
==196803==by 0x69EDCE: Py_InitializeFromConfig (pylifecycle.c:1247)
==196803==by 0x6D5346: pymain_init (main.c:67)
==196803==by 0x6D64F8: pymain_main (main.c:692)
==196803==by 0x6D65A1: Py_BytesMain (main.c:725)
==196803==by 0x41D7B5: main (python.c:15)

and

==196803== 3,336 bytes in 60 blocks are still reachable in loss record 87 of 87
==196803==at 0x484486F: malloc (vg_replace_malloc.c:381)
==196803==by 0x544E29: _PyMem_RawMalloc (obmalloc.c:101)
==196803==by 0x545E0E: PyObject_Malloc (obmalloc.c:700)
==196803==by 0x587159: PyUnicode_New (unicodeobject.c:1448)
==196803==by 0x59AEB9: unicode_decode_utf8 (unicodeobject.c:5162)
==196803==by 0x59B5B0: PyUnicode_DecodeUTF8Stateful (unicodeobject.c:5292)
==196803==by 0x58D296: PyUnicode_FromString (unicodeobject.c:2322)
==196803==by 0x5CFFAE: PyUnicode_InternFromString (unicodeobject.c:15650)
==196803==by 0x4E8B61: descr_new (descrobject.c:885)
==196803==by 0x4E8C9B: PyDescr_NewMethod (descrobject.c:934)
==196803==by 0x56694C: type_add_method (typeobject.c:5643)
==196803==by 0x566A92: type_add_methods (typeobject.c:5689)
==196803==by 0x569166: type_ready_fill_dict (typeobject.c:6165)
==196803==by 0x569A02: type_ready (typeobject.c:6421)
==196803==by 0x569B59: PyType_Ready (typeobject.c:6457)
==196803==by 0x544363: _PyTypes_InitTypes (object.c:1952)
==196803==by 0x69D12D: pycore_init_types (pylifecycle.c:704)
==196803==by 0x69D8FC: pycore_interp_init (pylifecycle.c:831)
==196803==by 0x69DC31: pyinit_config (pylifecycle.c:887)
==196803==by 0x69E355: pyinit_core (pylifecycle.c:1050)
==196803==by 0x69ED32: Py_InitializeFromConfig (pylifecycle.c:1240)
==196803==by 0x6D5346: pymain_init (main.c:67)
==196803==by 0x6D64F8: pymain_main (main.c:692)
==196803==by 0x6D65A1: Py_BytesMain (main.c:725)
==196803==by 0x41D7B5: main (python.c:15)

Before the commit c0a5ebeb1239020f2ecc199053bb1a70d78841a1, Python didn't leak 
this memory.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

> Not leaking memory at exit matters when Python is embedded
> in an application.

Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the 
deep-frozen memory -- the solution must be to update the accounting somewhere.

Where is the existence of Py_None accounted for (since it's statically 
allocated, or at least used to be)? That's likely where we'd have to do 
something about the deep-frozen objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> Presumably the leak is imaginary

Well, you can check with your favorite memory debugger like Valgrind if you 
don't trust Python internal memory debugger :-)

Not leaking memory at exit matters when Python is embedded in an application.

I don't think that it's related to the error handling which is stripped in 
release mode.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

Okay, let's change the error handling. @Kumar, can you handle that?

@Victor, the refleak is unrelated to the error handling right? Presumably the 
leak is imaginary -- the deep-frozen interned strings should be accounted for 
somehow. @Kumar do you need help investigating this?

--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

_PyStaticCode_InternStrings() error handling is based on assert(): that's 
really bad. It can crash Python (exit with abort()) at the first memory 
allocation failure. Why not returning -1 on error?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> This change introduced a memory leak at Python exit.

It's regression related to bpo-1635741 which I fixed recently:
https://mail.python.org/archives/list/python-...@python.org/thread/E4C6TDNVDPDNNP73HTGHN5W42LGAE22F/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset c0a5ebeb1239020f2ecc199053bb1a70d78841a1 by Kumar Aditya in 
> branch 'main':
> bpo-46430: Intern strings in deep-frozen modules  (GH-30683)

This change introduced a memory leak at Python exit.

Before:

$ ./python -X showrefcount -c pass
[0 refs, 0 blocks]

After:

$ ./python -X showrefcount -c pass
[0 refs, 344 blocks]

--
nosy: +vstinner

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

[Eric Snow]

Change by Eric Snow :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

[Eric Snow]

Eric Snow  added the comment:


New changeset 1f455361ecfb1892e375bdbee813cdf095b6cfb8 by Eric Snow in branch 
'main':
bpo-46765: Replace Locally Cached Strings with Statically Initialized Objects 
(gh-31366)
https://github.com/python/cpython/commit/1f455361ecfb1892e375bdbee813cdf095b6cfb8


--

___
Python tracker 
<https://bugs.python.org/issue46765>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Arie Bovenberg]

Arie Bovenberg  added the comment:

Thanks @gregory.p.smith! I didn't know about discuss.python.org. I created a 
new topic there: 
https://discuss.python.org/t/safer-logging-methods-for-f-strings-and-new-style-formatting/13802

--

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Gregory P. Smith]

Gregory P. Smith  added the comment:

A new system of logging APIs has been on several of our (core dev and 
otherwise) minds ever since f-strings were introduced.  For this specific 
issue, agreed that documentation is key.

The old logging APIs cannot change.  And practically preventing passing 
non-literal constant values in as the first parameter within their 
implementation while there are theoretical ways to _maybe_ do that, I expect 
none would be maintainable or performant.

For https://www.python.org/dev/peps/pep-0675/#logging-format-string-injection, 
my gut feeling is you want logging functions annotated as is a duality using 
overload.

```
@overload
def info(str) -> None:
...

@overload
def info(msg: LiteralString, *args: object) -> None:
```

As that prevents the untrusted template in msg so you could use a lone f-str.

This larger conversation is better turned into a python-dev or 
discuss.python.org thread than done in our poor bug tracker as anything more 
than the doc update and musing around the annotations turns into an evolved 
logging system design discussion.  (a nice thread internally at work just 
restarted about this and linked here... people want f-logging!)

--
nosy: +gregory.p.smith

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

[Eric Snow]

Change by Eric Snow :


--
keywords: +patch
pull_requests: +29516
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31366

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

[Eric Snow]

New submission from Eric Snow :

This removes a number of static variables and is a little more efficient.

--
assignee: eric.snow
components: Interpreter Core
messages: 413313
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Replace Locally Cached Strings with Statically Initialized Objects
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46765>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Christian Heimes]

Christian Heimes  added the comment:

Please leave the ticket open until we have an agreement how to handle the 
missing error checks.

--
resolution: fixed -> 
stage: resolved -> 
status: closed -> open
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Kumar Aditya  added the comment:

I consider this done so closing it as improving the error handling of interning 
it out of scope of this issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[miss-islington]

miss-islington  added the comment:


New changeset dee020a6f5bf29f95bec6294da9bcd577114f592 by Nikita Sobolev in 
branch 'main':
Fix sphinx-lint after #31097 and b878b3a (GH-31248)
https://github.com/python/cpython/commit/dee020a6f5bf29f95bec6294da9bcd577114f592


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Nikita Sobolev]

Change by Nikita Sobolev :


--
nosy: +sobolevn
nosy_count: 3.0 -> 4.0
pull_requests: +29417
pull_request: https://github.com/python/cpython/pull/31248

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

We discussed that and found that a lot of errors are ignored during interning 
anyway.

But it's not too late to change if you want to (sending a PR would probably be 
quicker than arguing :-).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Christian Heimes]

Christian Heimes  added the comment:

I noticed that the new interning code lacks proper error reporting. There are 
only asserts. _PyCode_New() checks the return value of intern_strings.

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset c0a5ebeb1239020f2ecc199053bb1a70d78841a1 by Kumar Aditya in 
branch 'main':
bpo-46430: Intern strings in deep-frozen modules  (GH-30683)
https://github.com/python/cpython/commit/c0a5ebeb1239020f2ecc199053bb1a70d78841a1


--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Tin Tvrtković]

Tin Tvrtković  added the comment:

I mean, I agree with your point about being able to accidentally format twice 
when using the standard library logger.

I'm not a core dev but I think getting new APIs in will be challenging. And if 
by some fluke of chance you did get the approval to introduce new logging APIs, 
there are better APIs out there (look at the structlog library). Also the old 
APIs would have to stay for a *long* time since everybody's using them.

Adding clever typing overloads seems actually realistic and useful to me. But 
that depends on the LiteralString PEP being accepted and people actually 
running MyPy. That's probably the best we can do, apart from some documentation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy:  -erlendaasland

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Arie Bovenberg]

Arie Bovenberg  added the comment:

@rhettinger @tinchester I definitely see now that f-strings should have a place 
in logging. 
But do you agree that f-strings don't mix 100% safely with the current logger 
API?
What are your thoughts on a safer set of logger functions (see my comments 
above, https://bugs.python.org/issue46200#msg409505)

Just throwing an additional alternative out there: instead of the @overload 
approach, one could have 2 logger function families:

debugs(s: str)  # s-prefix indicates simply logging a 
string (no formatting done by logger!)
debugf(s: LiteralStr, *args, **kwargs)  # f prefix indicates logger does the 
formatting. (no formatting done by user!)

@vinay.sajip what are your thoughts on the discussion above?

--

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Raymond Hettinger]

Raymond Hettinger  added the comment:

In a favor of deferred substitution, the cookbook should have a recipe where 
substituted messages are logged to a file and the unsubstituted message stored 
in SQLite3 database with the parameters stored as JSON.This gives both 
human readable output and queryable, preparsed data for automated analysis.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Eric is absolutely right, due to function calls being 
> somewhat slow in Python the performance argument in
> practice falls in favor of f-strings.

Also f-strings can evaluate expressions in the template which is also a big win:

   f('Pending {len(req)} requests: {req[0]!r} ... {req[-1]!r}')

--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Tin Tvrtković]

Tin Tvrtković  added the comment:

Eric is absolutely right, due to function calls being somewhat slow in Python 
the performance argument in practice falls in favor of f-strings.

So if they're faster, more readable, and more convenient to write, no wonder 
people prefer them (including me).

The overload approach is intriguing.

--
nosy: +tinchester

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39854] f-strings with format specifiers have wrong col_offset

[Irit Katriel]

Irit Katriel  added the comment:

Closing as 3.8 is only getting security fixes now.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39854] f-strings with format specifiers have wrong col_offset

[Stéphane Blondon]

Stéphane Blondon  added the comment:

I can reproduce it on python 3.8.
I can't reproduce it on python 3.9 or 3.10.

--
nosy: +sblondon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF

[Georg Brandl]

Change by Georg Brandl :


--
nosy:  -georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF

[Irit Katriel]

Change by Irit Katriel :


--
type: behavior -> enhancement
versions: +Python 3.11 -Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Kumar Aditya  added the comment:

This speeds up comparison of strings by just comparing their pointers so it is 
much faster.

--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

New submission from Kumar Aditya :

Interns strings in deep-frozen modules.

See https://github.com/faster-cpython/ideas/issues/218

--

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Change by Kumar Aditya :


--
keywords: +patch
pull_requests: +28882
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30683

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46430] intern strings in deepfrozen modules

[Kumar Aditya]

Change by Kumar Aditya :


--
nosy: gvanrossum, kumaraditya303
priority: normal
severity: normal
status: open
title: intern strings in deepfrozen modules
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46430>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39854] f-strings with format specifiers have wrong col_offset

[Irit Katriel]

Irit Katriel  added the comment:

I am unable to reproduce this on 3.11:

>>> ast.parse('f"{x}"').body[0].value.values[0].value.col_offset
3
>>> ast.parse('f"{x!r}"').body[0].value.values[0].value.col_offset
3

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46283] [subinterpreters] Unicode interned strings must not be shared between interpreters

[Petr Viktorin]

Petr Viktorin  added the comment:

Another proposed alternative is to make these immortal, and share them.

There were some discussions about this, but no PEP to capture the pros/cons of 
the alternatives and the decision.

--
nosy: +petr.viktorin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46275] caret location for syntax error pointing with f-strings

[William Navaraj]

William Navaraj  added the comment:

The variation in the caret position was also due to the trailing spaces. This 
is now sorted in this solution with a factored out function to find out the 
correct offset.
https://github.com/python/cpython/compare/main...williamnavaraj:fix-issue-46275?expand=1

Tested against all of the following cases and it works great:

temp=f"blank ({foo()}"+f"blank ({foo(}"+f"blank ({foo()}"
temp=f"blank*{foo(*blank*foo()*blank*foo()}"+f"({foo(}"+f"blank ({foo(}"
a=foo)+foo()+foo()  
f"blank ({foo(blank ({foo()}) blank foo()})"   
temp=f"blank ({foo)foo2" 
temp=f"blank {foo)"
temp=f"blank {foo)"
temp=f"blank ({foo)blank ({foo()}) blank foo()})"  yetAnotherBlah
temp=f"blank ({foo)blank ({foo()}) blank foo()})"  
yetAnotherBlahWithFurtherSpacesAfter

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46283] [subinterpreters] Unicode interned strings must not be shared between interpreters

[STINNER Victor]

New submission from STINNER Victor :

My commit ea251806b8d11b30d2182af1e589caf88acf made Unicode interned 
strings per interpreter to avoid accessing the same Python object from two 
different interpreters, to avoid race conditions on its reference count.

Problem: the change introduced the bpo-46006 regression in 
_PyUnicode_EqualToASCIIId() and type update_slot() functions which make the 
assumption that if two strings are interned and their pointers are not equal: 
these strings are not equal.

I proposed PR 30123 to fix these two functions, but then questions have been 
asked about the overall goal, running multiple Python interpreters in parallel 
in the same process (bpo-40512):
https://bugs.python.org/issue46006#msg408002

bpo-46006 was blocking the Python 3.11.0a4 release, Python 3.10 was affected 
and there were more and more affected projects:

* jep: https://github.com/ninia/jep/issues/358
* mod_wsgi: https://github.com/GrahamDumpleton/mod_wsgi/issues/729
* weechat-matrix: https://github.com/poljar/weechat-matrix/issues/293
* Fedora issue about mod_wsgi and weechat-matrix: 
https://bugzilla.redhat.com/show_bug.cgi?id=2030621

So I decided to just revert the change on interned strings:

* main branch: commit 35d6540c904ef07b8602ff014e520603f84b5886
* 3.10 branch: commit 72c260cf0c71eb01eb13100b751e9d5007d00b70 (with changes to 
keep the ABI backward compatibility)

These interned strings are preventing again to run multiple interpreters in 
parallel, two subinterpreters must not access the same Python object: see 
bpo-40533.

I suggest to write a PEP to explain the rationale, and reapply my commit 
ea251806b8d11b30d2182af1e589caf88acf with PR 30123.

--
components: Subinterpreters
messages: 409860
nosy: vstinner
priority: normal
severity: normal
status: open
title: [subinterpreters] Unicode interned strings must not be shared between 
interpreters
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46283>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46283] [subinterpreters] Unicode interned strings must not be shared between interpreters

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46275] caret location for syntax error pointing with f-strings

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46275] caret location for syntax error pointing with f-strings

[William Navaraj]

William Navaraj  added the comment:

A potential solution or in that direction

https://github.com/williamnavaraj/cpython/tree/fix-issue-46275

Example 1:

```
temp=f"blank {foo)" 

```
temp=f"blank {foo)" 
 ^
SyntaxError: f-string: unmatched ')'


Example 2:

```
temp=f"blank ({foo)foo2" 

```
temp=f"blank ({foo)foo2" 
  ^
SyntaxError: f-string: unmatched ')'


Example 3:

```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"

```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
 ^
SyntaxError: f-string: unmatched ')'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46275] caret location for syntax error pointing with f-strings

[William Navaraj]

New submission from William Navaraj :

Currently for non-f-string syntax errors, 
the caret points to the correct location of the syntax errors

Example 1:

```
a=foo)+foo()+foo()

```
a=foo)+foo()+foo()
 ^
SyntaxError: unmatched ')'


For f-string syntax errors, 
the caret points two locations after the f-string (almost correct location of 
the f-strings as a whole but will be more helpful as much as possible to point 
where exactly the syntax error is)

Example 2:

```
temp=f"blank ({foo(}" 

```
temp=f"blank ({foo(}" 
  ^
SyntaxError: f-string: closing parenthesis '}' does not match opening 
parenthesis '('


Example 3:

```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"

```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
 ^
SyntaxError: f-string: unmatched ')'

--
components: Parser
messages: 409813
nosy: lys.nikolaou, pablogsal, williamnavaraj
priority: normal
severity: normal
status: open
title: caret location for syntax error pointing with f-strings
versions: Python 3.11, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue46275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Arie Bovenberg]

Arie Bovenberg  added the comment:

Indeed the `__format__` style offers a lot more options (see 
https://pyformat.info/).

Regarding performance you make an interesting point.

One possible solution is to allow f-strings _only_ if there are no args/kwargs.
In that one case formatting would explicitly be skipped. 
This could be represented at type-level with an overload:

# case: Logger does formatting. Only literal string template allowed.
@overload
def debugf(msg: Literal[str], *args, exc_info: bool = False, **kwargs):
# wrap

# case: User does formatting. No args/kwargs allowed.
@overload
def debugf(msg: str, *, exc_info: bool = False):
# wrap `msg` in something that will not allow further formatting.

--

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Eric V. Smith]

Eric V. Smith  added the comment:

I think there's definitely room for improvement here, and at face value I like 
the debugf() functions. __format__ style formatting solves a big problem for 
me: being able to provide format strings for timestamps.

One thing: I'd be careful about saying that delayed formatting is always a 
performance win. f-strings are so much faster, that if I'm reasonable sure a 
message is always going to get logged, I'll use an f-string. In my case, I 
never log any user-supplied data, although it's obviously a risk that should be 
warned against.

--

___
Python tracker 
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46200] Discourage logging f-strings due to security considerations

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy: +erlendaasland

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com