[issue226619] Dict methods have no __doc__ strings

Change by admin : -- github: None -> 33627 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue223634] Pickle broken on Unicode strings

Change by admin : -- github: None -> 33516 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue229000] struct should handle terminated strings

Change by admin : -- github: None -> 33735 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : -- github: None -> 33725 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue216388] cStringIO rejects Unicode strings

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue221207] % operator on strings not documented

Change by admin : -- github: None -> 33443 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue222162] split is broken for unicode strings

Change by admin : -- github: None -> 33462 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401320] Translate doc strings

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401264] Attribute Doc-Strings (PEP 224)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400638] Doc strings added by Nils Fischbeck

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400706] minidom __repr__ returns Unicode strings

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue223634] Pickle broken on Unicode strings

Change by admin : -- github: None -> 33516 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue222162] split is broken for unicode strings

Change by admin : -- github: None -> 33462 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue217004] Tools/compiler does not create doc strings

Change by admin : -- github: None -> 33353 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue216388] cStringIO rejects Unicode strings

Change by admin : -- github: None -> 33313 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : -- github: None -> 33059 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : -- github: None -> 33072 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401309] Specialization of dictionaries for strings.

Change by admin : -- github: None -> 32989 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401264] Attribute Doc-Strings (PEP 224)

Change by admin : -- github: None -> 32973 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401320] Translate doc strings

Change by admin : -- github: None -> 32995 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401299] add missing test for strings in file_writelines

Change by admin : -- github: None -> 32986 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : -- github: None -> 32714 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by admin : -- github: None -> 32731 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400912] modified \x behaviour for unicode strings

Change by admin : -- github: None -> 32630 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400706] minidom __repr__ returns Unicode strings

Change by admin : -- github: None -> 32506 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400638] Doc strings added by Nils Fischbeck

Change by admin : -- github: None -> 32458 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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 <

[issue37789] Update doc strings for test.bytecode_helper

Irit Katriel added the comment: This has been fixed by now. -- nosy: +iritkatriel resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

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

Change by Eric V. Smith : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Incorrect exception highlighting for fstring format ___ Python tracker

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

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

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

Change by Nicko van Someren : -- keywords: +patch pull_requests: +29903 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31802 ___ Python tracker

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

ter 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 <h

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

Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29877 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31769 ___ Python tracker ___

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

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

[issue46430] intern strings in deepfrozen modules

Change by Dong-hee Na : -- pull_requests: -29803 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46430] intern strings in deepfrozen modules

Change by Dong-hee Na : -- pull_requests: +29803 pull_request: https://github.com/python/cpython/pull/31683 ___ Python tracker ___

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

Change by Guido van Rossum : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46430] intern strings in deepfrozen modules

Change by Kumar Aditya : -- pull_requests: +29719 pull_request: https://github.com/python/cpython/pull/31596 ___ Python tracker ___

[issue46430] intern strings in deepfrozen modules

n_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* retu

[issue46430] intern strings in deepfrozen modules

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 ___

[issue46430] intern strings in deepfrozen modules

Change by Dong-hee Na : -- pull_requests: +29678 pull_request: https://github.com/python/cpython/pull/31556 ___ Python tracker ___

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

tps://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 tho

[issue46430] intern strings in deepfrozen modules

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 ___

[issue46430] intern strings in deepfrozen modules

Change by Kumar Aditya : -- pull_requests: +29670 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31549 ___ Python tracker ___

[issue46430] intern strings in deepfrozen modules

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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. --

[issue46430] intern strings in deepfrozen modules

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. --

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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/ --

[issue46430] intern strings in deepfrozen modules

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 -

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

Change by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

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

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

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

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

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

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

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

[issue46765] Replace Locally Cached Strings with Statically Initialized Objects

Strings with Statically Initialized Objects versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46765> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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:

[issue46430] intern strings in deepfrozen modules

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 ___

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

[issue46430] intern strings in deepfrozen modules

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

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

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

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

Change by Erlend E. Aasland : -- nosy: -erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

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

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

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

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

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

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

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

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

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 ___

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

Change by Georg Brandl : -- nosy: -georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Irit Katriel : -- type: behavior -> enhancement versions: +Python 3.11 -Python 2.7, Python 3.3 ___ Python tracker ___ ___

[issue46430] intern strings in deepfrozen modules

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/issue46

[issue46430] intern strings in deepfrozen modules

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/issue46

[issue46430] intern strings in deepfrozen modules

Change by Kumar Aditya : -- keywords: +patch pull_requests: +28882 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30683 ___ Python tracker ___

[issue46430] intern strings in deepfrozen modules

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/issue46

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

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

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

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 ___

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

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.

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

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

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

Change by STINNER Victor : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Pablo Galindo Salgado : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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: ```

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

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(}" ^ S

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

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

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

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

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

Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

<    1   2   3   4   5   6   7   8   9   10   >