[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

STINNER Victor added the comment: New changeset b7aa23d29fa48238dab3692d02e1f0a7e8a5af9c by Victor Stinner in branch 'master': bpo-40521: Disable list free list in subinterpreters (GH-19959) https://github.com/python/cpython/commit/b7aa23d29fa48238dab3692d02e1f0a7e8a5af9c --

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

STINNER Victor added the comment: New changeset 89fc4a34cf7a01df9dd269d32d3706c68a72d130 by Victor Stinner in branch 'master': bpo-40521: Disable method cache in subinterpreters (GH-19960) https://github.com/python/cpython/commit/89fc4a34cf7a01df9dd269d32d3706c68a72d130 --

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

Change by STINNER Victor : -- pull_requests: +19276 pull_request: https://github.com/python/cpython/pull/19960 ___ Python tracker ___

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

Change by STINNER Victor : -- pull_requests: +19275 pull_request: https://github.com/python/cpython/pull/19959 ___ Python tracker ___

[issue40511] IDLE yellow hint frame blinks when entering () in strings in functions/classes

Terry J. Reedy added the comment: 1. What OS and for Windows/Mac, version? 2. What Python release and from where and how installed? If not latest release of x.y, where x.y >= 3.7, consider upgrading. 3. Tcl/tk version (see Help => About IDLE? 4. How start IDLE? 5. What is a the minimum

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

STINNER Victor added the comment: New changeset b4b53868d7d6cd13505321d3802fd00865b25e05 by Victor Stinner in branch 'master': bpo-40521: Disable free lists in subinterpreters (GH-19937) https://github.com/python/cpython/commit/b4b53868d7d6cd13505321d3802fd00865b25e05 --

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

STINNER Victor added the comment: New changeset 607b1027fec7b4a1602aab7df57795fbcec1c51b by Victor Stinner in branch 'master': bpo-40521: Disable Unicode caches in isolated subinterpreters (GH-19933) https://github.com/python/cpython/commit/607b1027fec7b4a1602aab7df57795fbcec1c51b

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

Change by STINNER Victor : -- pull_requests: +19252 pull_request: https://github.com/python/cpython/pull/19937 ___ Python tracker ___

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

Change by STINNER Victor : -- keywords: +patch pull_requests: +19248 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19933 ___ Python tracker ___

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

New submission from STINNER Victor : tuple, dict and frame use free lists to optimize the creation of objects. Unicode uses "interned" strings to reduce the Python memory footprint and speedup dictionary lookups. Unicode also uses singletons for single letter Latin1 characters ([

[issue40511] IDLE yellow hint frame blinks when entering () in strings in functions/classes

Change by wyz23x2 : -- title: IDLE yellow hint frame blinks when entering () in strings -> IDLE yellow hint frame blinks when entering () in strings in functions/classes ___ Python tracker <https://bugs.python.org/issu

[issue40511] IDLE yellow hint frame blinks when entering () in strings

Change by wyz23x2 : -- title: Yellow hint frame blinks when entering () in strings -> IDLE yellow hint frame blinks when entering () in strings ___ Python tracker <https://bugs.python.org/issu

[issue40511] Yellow hint frame blinks when entering () in strings

wyz23x2 added the comment: OMG, request too large. I can't upload mp4 /(ㄒoㄒ)/~~ -- ___ Python tracker ___ ___ Python-bugs-list

[issue40511] Yellow hint frame blinks when entering () in strings

entering () in strings type: behavior versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40511> ___ ___ Python-bugs-list mailin

Re: =+ for strings

On Sun, 3 May 2020 19:38:06 -0700 (PDT) James Smith wrote: > I tried: > dt=+"{:02d}".format(day) > but I got: > dt=+"{:02d}".format(day) > TypeError: bad operand type for unary +: 'str' > > This works: > dt=dt+"{:02d}".format(d

Re: =+ for strings

On Mon, May 4, 2020 at 12:41 PM James Smith wrote: > > I tried: > dt=+"{:02d}".format(day) > but I got: > dt=+"{:02d}".format(day) > TypeError: bad operand type for unary +: 'str' > > This works: > dt=dt+"{:02d}".format(day)

=+ for strings

I tried: dt=+"{:02d}".format(day) but I got: dt=+"{:02d}".format(day) TypeError: bad operand type for unary +: 'str' This works: dt=dt+"{:02d}".format(day) Why can't I do the shortcut on strings? -- https://mail.python.org/mailman/listinfo/python-list

[issue40470] Make inspect.signature able to parse format strings.

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40470] Make inspect.signature able to parse format strings.

Change by Brett Cannon : -- components: +Library (Lib) ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40470] Make inspect.signature able to parse format strings.

Change by Brett Cannon : -- type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40470] Make inspect.signature able to parse format strings.

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40470] Make inspect.signature able to parse format strings.

additional arguments). Right now I believe the only way to parse format strings is string.Formatter, which is slightly less discoverable and harder to use (although it certainly also provides more info, e.g. inspect.signature wouldn't be able to tell about format specifiers, but th

[issue35113] inspect.getsource returns incorrect source for classes when class definition is part of multiline strings

Karthikeyan Singaravelan added the comment: Closing this as fixed with the enhancement to show decorator for classes too for 3.9. Thank you all for the help on this. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.6,

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- stage: patch review -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- keywords: -patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: -19105 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: +19105 pull_request: https://github.com/python/cpython/pull/19782 ___ Python tracker ___

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Batuhan Taskaya added the comment: Sorry for the noise, wrong issue (thought 344, but actually was 334) -- ___ Python tracker ___

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: -19103 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- keywords: +patch nosy: +BTaskaya nosy_count: 4.0 -> 5.0 pull_requests: +19103 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19782 ___ Python tracker

[issue40365] argparse: action "extend" with 1 parameter splits strings into characters

paul j3 added the comment: This is a consequence of Python's own definition of append vs extend In [730]: alist = [] In [731]: alist.append('astring')

[issue40365] argparse: action "extend" with 1 parameter splits strings into characters

Change by Karthikeyan Singaravelan : -- nosy: +paul.j3, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40365] argparse: action "extend" with 1 parameter splits strings into characters

ast notion in documentation would be nice, as the issue does not occure with action='append' Minimal example included. -- files: argparse_bug.py messages: 367033 nosy: strjan priority: normal severity: normal status: open title: argparse: action "extend" with 1 parameter splits strings

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Raymond Hettinger added the comment: Your contributions are welcome. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Andy Lester : -- nosy: +petdance ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

s steps without any additional comment might seem strange. More experienced users probably won't need such an example at all. In addition it might make people falsely belief that `str.join` expects a list of strings rather than any iterable, and hence the explicit const

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

. For example: blocks = [] while True: block = s.recv(4096) if not block: break blocks.append(block) page = b''.join(blocks) The problem with that example is that it shifts focus to tcp clients rather than the core topic to how to join strings

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Dominik V. added the comment: Here's the link to the relevant section: https://docs.python.org/3/faq/programming.html#what-is-the-most-efficient-way-to-concatenate-many-strings-together -- ___ Python tracker <https://bugs.python.org/issue40

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

is superfluous. If people just copy & paste from this FAQ they'll even end up with less performant code. The example could be improved by providing an example list such as: strings = ['spam', 'ham', 'eggs'] meal = ', '.join(strings) Arguably this isn't a particularly long list of str

[issue28002] ast.unparse can't roundtrip some f-strings

Change by Shantanu : -- keywords: +patch pull_requests: +18946 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19612 ___ Python tracker ___

[issue28002] ast.unparse can't roundtrip some f-strings

Simon Percivall added the comment: Any and all code from astunparse is certainly available for inclusion. Go ahead. -- nosy: +simon.percivall ___ Python tracker ___

[issue28002] ast.unparse can't roundtrip some f-strings

Batuhan Taskaya added the comment: > If that sounds good, I can submit a PR and inform the original author I can't say anything before seeing the approach but fixing the problem definitely sounds good. -- ___ Python tracker

[issue35113] inspect.getsource returns incorrect source for classes when class definition is part of multiline strings

Change by Serhiy Storchaka : -- pull_requests: +18924 pull_request: https://github.com/python/cpython/pull/19587 ___ Python tracker ___

[issue35113] inspect.getsource returns incorrect source for classes when class definition is part of multiline strings

Karthikeyan Singaravelan added the comment: New changeset 696136b993e11b37c4f34d729a0375e5ad544ade by Karthikeyan Singaravelan in branch 'master': bpo-35113: Fix inspect.getsource to return correct source for inner classes (#10307)

[issue40295] doctest handling of multiline strings is broken

Steven D'Aprano added the comment: By the way Filip, you were told on the Stackoverflow page that the output was correct and that you were not using doctest correctly. Serhiy also hinted to you that you should check the output in the REPL and you falsely claimed that it gave the expected

[issue40295] doctest handling of multiline strings is broken

Steven D'Aprano added the comment: Have you tried calling multiline_output() in the REPL? It does *not* show your expected output: # expected First line Second line but the string repr(): # actual 'First line\nSecond line\n' Change your doctest to either: >>>

[issue40295] doctest handling of multiline strings is broken

Filip Rembiałkowski added the comment: Actually, the behavior does not depend on leading spaces, and test case can be isolated even further. Sample is attached [doctest-bugs-2.py]. -- Added file: https://bugs.python.org/file49066/doctest-bugs-2.py

[issue40295] doctest handling of multiline strings is broken

Filip Rembiałkowski added the comment: @Serhiy, Thank you for feedback. Yes the "testme" function (indeed trivial) works as expected - both in interactive Python interpreter and in script file. If you go to Lib/doctest.py, search for "string-identical" and debug my example there, you will

[issue40295] doctest handling of multiline strings is broken

Serhiy Storchaka added the comment: Did you try to run the tested function in the interactive Python interpreter? Did you get what you expected? -- nosy: +serhiy.storchaka ___ Python tracker

[issue40295] doctest handling of multiline strings is broken

New submission from Filip Rembiałkowski : The doctest module does not compare multiline strings properly, as attached example proves. Tested on 2.7, 3.6 and 3.9.0a5+. (platform: Ubuntu 18.04). Related: https://stackoverflow.com/questions/60956015/unexpected-errors-while-testing-python3-code

[issue28002] ast.unparse can't roundtrip some f-strings

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

[issue28002] ast.unparse can't roundtrip some f-strings

Shantanu added the comment: Now that `ast.unparse` is being added to stdlib, I thought I'd bump this thread. The third party library `astunparse` (which attempts to support multiple Python versions while staying very close to Tools/parser/unparse.py) has an implementation that works for

[issue11395] print(s) fails on Windows with long strings

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11395] print(s) fails on Windows with long strings

Eryk Sun added the comment: > the problem (or at least with these numbers) occurs only when > the code is saved in a script, and this is run by double- > clicking the file The .py file association is probably using a different version of Python, or it's associated with the py launcher and

[issue11395] print(s) fails on Windows with long strings

Adam Bartoš added the comment: I've been hit by this issue recently. On my configuration, print("a" * 10215) fails with an infinite loop of OSErrors (WinError 8). This even cannot by interrupted with Ctrl-C nor the exception can be catched. - print("a" * 10214) is fine - print("a" * 10215)

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

Change by yang : -- keywords: +patch nosy: +fhsxfhsx nosy_count: 2.0 -> 3.0 pull_requests: +18760 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19398 ___ Python tracker

[issue28029] Replace and empty strings

Glenn Linderman added the comment: Nope: I guess for x.replace( a, b, c ) the workaround would be x.replace( a, b, c ) if x else x.replace( a, b ) -- ___ Python tracker

[issue28029] Replace and empty strings

Glenn Linderman added the comment: Thanks Stèphańe and Serhiy, I just discovered this strange behavior in 3.8, and wondered how my logic was wrong, until I pinpointed the inconsistent behaviour of str.replace with an empty first parameter and replace count of 1. Glad to see it is fixed in

[issue40054] Allow formatted strings as docstrings

Change by Serhiy Storchaka : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue40054] Allow formatted strings as docstrings

Karthikeyan Singaravelan added the comment: See also https://bugs.python.org/issue28739 -- nosy: +xtreak ___ Python tracker ___

[issue40054] Allow formatted strings as docstrings

Eric V. Smith added the comment: The problem is that __doc__ is set at compile time, not run time. The ''.format call (and f-strings) are evaluated at run time. -- nosy: +eric.smith ___ Python tracker <https://bugs.python.org/issue40

[issue40054] Allow formatted strings as docstrings

New submission from Richard Neumann : Currently only plain strings can be used as docstrings, such as: class Foo: """Spamm eggs.""" For dynamic class generation, it would be useful to allow format strings as docstrings as well: doc = 'eggs'

Re: [Python-ideas] Re: New explicit methods to trim strings

I agree with Steven D'Aprano. I never had problems with strip(), but if people find it confusing, Python can simply leave strip() and all the other function as they are and add another functions, like crop() or snip() or shear() prune() or mow(). Personally I prefer crop() or prune(). This way

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

Batuhan Taskaya added the comment: This looks like a duplicate of issue 35212 -- nosy: +BTaskaya, pablogsal ___ Python tracker ___

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

Change by Karthikeyan Singaravelan : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

).body[0].value.values[0].value.col_offset 3 >>> ast.parse('f"{x!r}"').body[0].value.values[0].value.col_offset 1 The col_offset for the variable x should be 3 in both instances. ------ messages: 363375 nosy: asmeurer priority: normal severity: normal status: open title: f-strings w

[issue39736] const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c

Benjamin Peterson added the comment: New changeset c3fa634096eedbaf477698adab666f03085a7928 by Andy Lester in branch 'master': closes bpo-39736: const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c (GH-18637) https://github.com/python/cpython/commit

[issue39736] const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c

Change by Andy Lester : -- keywords: +patch pull_requests: +18003 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18637 ___ Python tracker ___

[issue39736] const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c

nosy: petdance priority: normal severity: normal status: open title: const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c ___ Python tracker <https://bugs.python.org/issue39

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Lysandros Nikolaou added the comment: > Can I ask how pegen solved this problem? Did you move parsing of f-strings > into the grammar? No, we actually do a very similar thing to what ast.c does. I think there is only one major difference between what pegen does and what ast.c does

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Eric V. Smith added the comment: Can I ask how pegen solved this problem? Did you move parsing of f-strings into the grammar? I found my patch and I'm working on resolving merge conflicts. -- ___ Python tracker <https://bugs.python.

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Lysandros Nikolaou added the comment: Also note that for pegen this is a solved problem. If we decide to change the parser, it may not be worth it to spend too much time on a universal solution. -- ___ Python tracker

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Eric V. Smith added the comment: I'll see if I can dig up the patch today. If I can find it, I'll attach it to issue 34364. This is really the first time I've tried to write down all of the issues related to tokenizing f-strings. It does seem a little daunting, but I'm not done noodling

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Guido van Rossum added the comment: Wow. Do you still have a branch with that non-working patch? Maybe there are some ideas that can be salvaged. I'm wondering if maybe we're better leaving f-strings alone? The current code is quite voluminous, but it looks as if by the time you've

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Eric V. Smith added the comment: Yes, my approach is to use the tokenizer to produce the parts of the f-string, instead of treating it as a normal string and making a second pass to parse out the pieces. I've been discussing this for a few years, and at last PyCon I talked to many tool

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Guido van Rossum added the comment: This is indeed a duplicate of issue35212 (the second message there also shows a problem with implicit f-string concatenation). There's not much information in issue34364 (just a merged PR, and a mention of a PR of yours from 2 years ago that apparently

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Guido van Rossum added the comment: Note that this is somewhat urgent for oefen, since we strive to match the produced AST exactly. -- --Guido (mobile) -- ___ Python tracker

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Eric V. Smith added the comment: There are a number of bugs about this. See issue 35212 and issue 34364, at least. I have a stale patch that tried to fix this, but I was never able to get it completely correct. I have another approach that I hope to discuss at the language summit at PyCon.

[issue39564] Parsed expression has wrong line/col info when concatenating f-strings

New submission from Lysandros Nikolaou : When concatenating f-strings, if there is an expression in any STRING node other than the first, col_offset of the parsed expression has a wrong value. For example, parsing f"hello" f"{world}" outputs the following AST: Module(

[issue39564] Parsed expression has wrong col_offset when concatenating f-strings

Change by Lysandros Nikolaou : -- title: Parsed expression has wrong line/col info when concatenating f-strings -> Parsed expression has wrong col_offset when concatenating f-strings ___ Python tracker <https://bugs.python.org/issu

[issue28002] ast.unparse can't roundtrip some f-strings

Change by Batuhan : -- components: +Library (Lib) -Demos and Tools title: Some f-strings do not round trip through Tools/parser/test_unparse.py -> ast.unparse can't roundtrip some f-strings versions: +Python 3.9 -Python 3.7, Python 3.8 ___ Pyt

[issue28002] Some f-strings do not round trip through Tools/parser/test_unparse.py

Change by Batuhan : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39183] Text divided in two strings due to wrong formatting

Rafael Fontenelle added the comment: Fix confirmed, closing. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39183] Text divided in two strings due to wrong formatting

miss-islington added the comment: New changeset 6bf382ac9a07f42c6f91f35a7f0df4c63e35a8a7 by Miss Islington (bot) in branch '3.8': bpo-39183: Fix formatting in library/ensurepip (GH-17787) https://github.com/python/cpython/commit/6bf382ac9a07f42c6f91f35a7f0df4c63e35a8a7 --

[issue39183] Text divided in two strings due to wrong formatting

miss-islington added the comment: New changeset 3959638ba1b1e25c25a2da880aba78fd53dd947f by Miss Islington (bot) in branch '3.7': bpo-39183: Fix formatting in library/ensurepip (GH-17787) https://github.com/python/cpython/commit/3959638ba1b1e25c25a2da880aba78fd53dd947f --

[issue39183] Text divided in two strings due to wrong formatting

Change by miss-islington : -- pull_requests: +17221 pull_request: https://github.com/python/cpython/pull/17788 ___ Python tracker ___

[issue39183] Text divided in two strings due to wrong formatting

miss-islington added the comment: New changeset 149175c6dfc8455023e4335575f3fe3d606729f9 by Miss Islington (bot) (Rafael Fontenelle) in branch 'master': bpo-39183: Fix formatting in library/ensurepip (GH-17787) https://github.com/python/cpython/commit/149175c6dfc8455023e4335575f3fe3d606729f9

[issue39183] Text divided in two strings due to wrong formatting

Change by miss-islington : -- pull_requests: +17222 pull_request: https://github.com/python/cpython/pull/17789 ___ Python tracker ___

[issue39183] Text divided in two strings due to wrong formatting

Change by Roundup Robot : -- keywords: +patch pull_requests: +17219 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17787 ___ Python tracker ___

[issue39183] Text divided in two strings due to wrong formatting

New submission from Rafael Fontenelle : When translating Python docs, the 'library/ensurepip' module [1] has an bullet list where one item's text is split in two due to a simple extra whitespace character. This causes two separated translations strings "``--default-pip``: if a \"d

[issue24925] Allow doctest to find line number of __test__ strings if formatted as a triple quoted string.

Jurjen N.E. Bos added the comment: All is fixed. The PR apparently is correct. My first dent in the Python universe, however small :-) -- ___ Python tracker ___

[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs

Change by Ned Deily : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs

mattip added the comment: Is there a ctypes or PEP-3118 core-dev who could review the issue and the PR solution? -- nosy: +mattip ___ Python tracker ___

[issue32954] Lazy Literal String Interpolation (PEP-498-based fl-strings)

Change by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: Randomizing Strings In A Microservices World

On 12/10/19 12:37 PM, Chris Angelico wrote: > On Wed, Dec 11, 2019 at 5:01 AM Tim Daneliuk wrote: >> >> On 12/10/19 10:36 AM, Peter Pearson wrote: >>> Just to be sure: you *are* aware that the "Birthday Paradox" says >>> that if you pick your 10-di

Re: Randomizing Strings In A Microservices World

On Wed, Dec 11, 2019 at 5:01 AM Tim Daneliuk wrote: > > On 12/10/19 10:36 AM, Peter Pearson wrote: > > Just to be sure: you *are* aware that the "Birthday Paradox" says > > that if you pick your 10-digit strings truly randomly, you'll probably > > get a col

Re: Randomizing Strings In A Microservices World

On 12/10/19 10:36 AM, Peter Pearson wrote: > Just to be sure: you *are* aware that the "Birthday Paradox" says > that if you pick your 10-digit strings truly randomly, you'll probably > get a collision by the time of your 10**5th string . . . right? I did not consider this, but

Re: Randomizing Strings In A Microservices World

plication - the consumption > of values will be sparse over time. All I really need is a high > entropy way to select from among the billion possible values to > minimize the possibility of collisions (which require retry and time > we don't want to burn). Just to be sure: you *are* aware t

Re: Randomizing Strings In A Microservices World

Tim Daneliuk wrote: > I ran across a kind of fun problem today that I wanted to run past you > Gentle Geniuses (tm): > > - Imagine an environment in which there may be multiple instances of a > given > microservice written in Python. > > - Each of these services needs to produce a string of

Re: Randomizing Strings In A Microservices World

On 10/12/2019 03:35, Tim Daneliuk wrote: On 12/9/19 8:50 PM, Paul Rubin wrote: Tim Daneliuk writes: - Imagine an environment in which there may be multiple instances of a given microservice written in Python. Decide the maximum number of microservice instances, say 1000. Chop up the 10

<    3   4   5   6   7   8   9   10   11   12   >