[issue36774] f-strings: Add a !d conversion for ease of debugging

Gregory P. Smith added the comment: hallway conversation with Eric: neither of us have immediately good thoughts on a spelling other than !d for this. !! or != seem esoteric and/or unparseable, using a capital letter like !D could be new and odd and might be useful to differentiate types

[issue36774] f-strings: Add a !d conversion for ease of debugging

Gregory P. Smith added the comment: Steven: We shouldn't block this immediately useful feature from going in for f-strings on waiting for some much broader first class access to expressions feature. !d would be practical today. -- ___ Python

[issue36774] f-strings: Add a !d conversion for ease of debugging

Gregory P. Smith added the comment: for reference, the discourse thread: https://discuss.python.org/t/f-string-debug-conversion/99/14 -- nosy: +gregory.p.smith ___ Python tracker

[issue36774] f-strings: Add a !d conversion for ease of debugging

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36774] f-strings: Add a !d conversion for ease of debugging

Change by Andy Dirnberger : -- nosy: +dirn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36774] f-strings: Add a !d conversion for ease of debugging

Eric V. Smith added the comment: I support a general mechanism. But I think that if it's much more than the 2 characters that this would take, then I don't want to use it for f-strings. The whole point here (as with all f-string features) is a concise way to get the string you're after

[issue36774] f-strings: Add a !d conversion for ease of debugging

en some discussion on discourse. > > The proposal is to add a !d "type conversion" to f-strings, to make for > simpler "print-based debugging". The idea is that !d would be like !r, etc., > except that the resulting string would be: > > - the text of

[issue36774] f-strings: Add a !d conversion for ease of debugging

New submission from Eric V. Smith : I originally propsed this here: https://mail.python.org/pipermail/python-ideas/2018-October/053956.html, and there has also been some discussion on discourse. The proposal is to add a !d "type conversion" to f-strings, to make for simpler &q

[issue36757] uuid constructor accept invalid strings (extra dash)

Windson Yang added the comment: > Maybe a line should be added in the documentation to prevent people using > this as a validator without more check? I don't expect uuid.UUID could be used as a validator myself, but I agreed we can warn users in the documentation if lots of them confuse

[issue36757] uuid constructor accept invalid strings (extra dash)

Cédric Cabessa added the comment: > Is there are reason your validator doesn't use uuid.UUID to normalize the > value? That is, whatever the customer provides, why not use the result of > stringifying the resulting UUID Yes, this is exactly what we do now However this behaviour is a bit

[issue36757] uuid constructor accept invalid strings (extra dash)

Josh Rosenberg added the comment: The documentation does describe a fairly flexible parser. Perhaps it's a little too flexible on stuff like URN prefixes, but I don't think we could start enforcing a stricter class of hyphen separations without potentially breaking existing code. Is there

[issue36757] uuid constructor accept invalid strings (extra dash)

not accept string like the one in exemple -- components: Library (Lib) messages: 341141 nosy: Cédric Cabessa priority: normal severity: normal status: open title: uuid constructor accept invalid strings (extra dash) versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Pyth

[issue25545] email parsing docs: clarify that only ASCII strings are supported

immerrr again added the comment: Oh, wow, confusing indeed, but in historical context it makes slightly more sense. Thank you for the explanation! -- ___ Python tracker ___

[issue25545] email parsing docs: clarify that only ASCII strings are supported

R. David Murray added the comment: This is one of the infelicities of the translation of the old API to python3: 'get_payload(decode=True)' actually means 'give me the bytes version of this payload", which in this case is the utf-8, which is what you got. get_payload() means "give me the

[issue25545] email parsing docs: clarify that only ASCII strings are supported

immerrr again added the comment: Hi everyone, It's the first time I'm using this bugtracker, so apologies in advance if I manage to break something from the first go. Not sure if it's the right place to report this, but I have the following repro that involves email.message_from_bytes: In

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

Stefan Krah added the comment: Since Terry added me: Yes, this is clearly a bug, but it is a ctypes issue and not a memoryview issue. ctypes issues unfortunately tend to take some time until someone reviews. -- ___ Python tracker

[issue36628] Enhancement: i-Strings

Change by Aditya Shankar : -- resolution: postponed -> duplicate ___ Python tracker ___ ___ Python-bugs-list mailing list

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

Terry J. Reedy added the comment: Fixing one case is better than fixing no cases. -- nosy: +skrah, terry.reedy ___ Python tracker ___

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

Change by Terry J. Reedy : -- versions: -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36628] Enhancement: i-Strings

Karthikeyan Singaravelan added the comment: Some discussions in the past and the common suggestion/idiom is to use textwrap.dedent. I agree with @SilentGhost that it should be first brought up in python-ideas and also addressing the concerns for similar proposal in the past if they are

[issue36628] Enhancement: i-Strings

SilentGhost added the comment: This type of enhancements should be in the first place discussed on python-ideas mailing list and a PEP would probably be needed at the second stage. Not that I think it's likely this suggestion has much chance. What you're desiring can already be implemented

[issue36628] Enhancement: i-Strings

New submission from Aditya Shankar : Problem: multiline strings are a pain to represent (other than of-course in docstrings), representing a multiline string inside a function looks something like this - def foo(): # some code ... ... # some code text = """

[issue17068] peephole optimization for constant strings

Change by Inada Naoki : -- nosy: +inada.naoki ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

Stefan Krah added the comment: gcc warns with -pedantic: ptr.c: In function ‘main’: ptr.c:5:13: warning: format ‘%p’ expects argument of type ‘void *’, but argument 2 has type ‘int *’ [-Wformat=] printf ("%p", ); It is pedantic indeed, I wonder if machines with different pointer sizes

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

Serhiy Storchaka added the comment: Are not all pointer types (except pointers to functions) automatically converted to/from void*. -- ___ Python tracker ___

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

Change by Serhiy Storchaka : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

Change by Karthikeyan Singaravelan : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

Change by Zackery Spytz : -- keywords: +patch pull_requests: +12698 stage: -> patch review ___ Python tracker ___ ___

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

New submission from Zackery Spytz : The attached PR fixes incorrect usages of %p in format strings. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36594] Undefined behavior due to incorrect usage of %p in format strings

Change by Zackery Spytz : -- components: Extension Modules, Interpreter Core nosy: ZackerySpytz priority: normal severity: normal status: open title: Undefined behavior due to incorrect usage of %p in format strings versions: Python 2.7, Python 3.7, Python 3.8

[issue28626] Tutorial: rearrange discussion of output formatting to encourage f-strings

Change by Cheryl Sabella : -- keywords: -needs review, patch resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue28937] str.split(): remove empty strings when sep is not None

Emanuel Barry added the comment: Unfortunately not. I no longer have the time or means to work on this, sorry. I hope someone else can pick it up. -- ___ Python tracker ___

[issue28937] str.split(): remove empty strings when sep is not None

Change by Emanuel Barry : -- nosy: -ebarry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28937] str.split(): remove empty strings when sep is not None

Barry A. Warsaw added the comment: @veky - Thank you for pointing out splitlines(keepends=True). If we wanted consistency, then we'd change the sense and use something like .split(keepempty=True), however: * I don't like run-on names, so I would suggest keep_empty * Maybe just `keep` is

[issue28937] str.split(): remove empty strings when sep is not None

Cheryl Sabella added the comment: @ebarry, any interest in converting your patch to a GitHub pull request? Thanks! -- nosy: +cheryl.sabella versions: +Python 3.8 -Python 3.7 ___ Python tracker

[issue19415] test_gdb fails when using --without-doc-strings on Fedora 19

Stéphane Wirtel added the comment: @Nick, I have tested with the last 3.8 and 3.7 and Fedora 29. ./configure --without-doc-strings > /dev/null ;and make -j 4 > /dev/null ;and ./python -m test -W test_gdb Run tests sequentially 0:00:00 load avg: 1.49 [1/1] test_gdb test_gdb passed in

[issue19415] test_gdb fails when using --without-doc-strings on Fedora 19

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36254] Fix invalid uses of %d in format strings in C

Serhiy Storchaka added the comment: New changeset 783bed4c8daf65a2893d94761ea44af4e3718f4f by Serhiy Storchaka in branch '3.7': [3.7] bpo-36254: Fix invalid uses of %d in format strings in C. (GH-12264). (GH-12322) https://github.com/python/cpython/commit

[issue36254] Fix invalid uses of %d in format strings in C

Change by Serhiy Storchaka : -- pull_requests: +12296 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36254] Fix invalid uses of %d in format strings in C

Serhiy Storchaka added the comment: New changeset 2c0d3f454705bb5ccf5f6189f3cf77bbae4f056b by Serhiy Storchaka in branch 'master': bpo-36254: Fix yet one invalid use of %d in format string in C. (GH-12318) https://github.com/python/cpython/commit/2c0d3f454705bb5ccf5f6189f3cf77bbae4f056b

[issue36254] Fix invalid uses of %d in format strings in C

Change by Serhiy Storchaka : -- pull_requests: +12294 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36254] Fix invalid uses of %d in format strings in C

Change by Serhiy Storchaka : -- pull_requests: +12292 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36254] Fix invalid uses of %d in format strings in C

Serhiy Storchaka added the comment: New changeset d53fe5f407ff4b529628b01a1bcbf21a6aad5c3a by Serhiy Storchaka in branch 'master': bpo-36254: Fix invalid uses of %d in format strings in C. (GH-12264) https://github.com/python/cpython/commit/d53fe5f407ff4b529628b01a1bcbf21a6aad5c3a

[issue32846] Deletion of large sets of strings is extra slow

Inada Naoki added the comment: I thought compact set implementation similar to dict sicne Python 3.6 may fix this issue. But as discussion with Raymond on Python-Dev ML, I conclude the merits of compact implementation is not significant enough. I abandoned compact set branch. Now I don't

[issue36254] Fix invalid uses of %d in format strings in C

Serhiy Storchaka added the comment: See also issue36251. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36254] Fix invalid uses of %d in format strings in C

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +12249 stage: -> patch review ___ Python tracker ___ ___

[issue36254] Fix invalid uses of %d in format strings in C

New submission from Serhiy Storchaka : The proposed patch fixes invalid uses of %d in format strings in C (mostly when the argument has type Py_ssize_t or size_t). -- components: Extension Modules, Interpreter Core messages: 337606 nosy: serhiy.storchaka, vstinner priority: normal

[issue36072] str.translate() behaves differently for ASCII-only and other strings

Terry J. Reedy added the comment: I agree. The fact the CPython attempts to optimize all_ascii.translate(table) is a CPython implementation detail, not a language feature. -- assignee: -> docs@python components: +Documentation nosy: +docs@python, terry.reedy resolution: -> not a

[issue36072] str.translate() behaves differently for ASCII-only and other strings

Serhiy Storchaka added the comment: You are using a mapping that returns different values for the same key. You should not expect a stable result for it. I do not think this needs a special mentioning in the documentation. Garbage in -- garbage out. -- nosy: +serhiy.storchaka

[issue36072] str.translate() behaves differently for ASCII-only and other strings

Change by Sergey Fedoseev : -- title: str.translate() behave differently for ASCII-only and other strings -> str.translate() behaves differently for ASCII-only and other strings ___ Python tracker <https://bugs.python.org/issu

[issue36072] str.translate() behave differently for ASCII-only and other strings

: 336279 nosy: sir-sigurd priority: normal severity: normal status: open title: str.translate() behave differently for ASCII-only and other strings ___ Python tracker <https://bugs.python.org/issue36

[issue31136] raw strings cannot end with a backslash character r'\'

Graham Wideman added the comment: Demonstration: print("x" + r' \' ' + "x") produces x \' x Where is this behavior _ever_ useful? Or if there is some use case for this, how frequent is it compared to the frequency of users expecting either that backslash does nothing special, or that it

[issue31136] raw strings cannot end with a backslash character r'\'

the name of this feature, "raw string", which is patently misleading and in violation of the principle of least surprise. This is a feature (as the FAQ explains) provided explicitly for developers of regular expression parsers. So at best, these r-strings should be called "regex-

[issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings

Vinay Sajip added the comment: If the arguments are retrieved from a byte source, why can't they be converted to strings before passing to logging? This may be an issue for OpenStack. It's not logging's job to convert bytes passed to APIs that expect strings

[issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings

Karthikeyan Singaravelan added the comment: Sorry, I don't get the report. Can you please add a short reproducer script with a description of the current behavior and the expected behavior? -- nosy: +xtreak ___ Python tracker

[issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings

Change by SilentGhost : -- components: +Library (Lib) nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36032] Wrong output in tutorial (3.1.2. Strings)

INADA Naoki added the comment: Uh! You meant Python 2.7!! It doesn't make sense to improve Python 2.7 tutorial. If you're reading Python 2 tutorial, please read 3.7 tutorial instead!!! -- ___ Python tracker

[issue36032] Wrong output in tutorial (3.1.2. Strings)

INADA Naoki added the comment: @Amit Please confirm docs.python.org before submitting issue. #33460 fixed it already. -- nosy: +inada.naoki ___ Python tracker ___

[issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings

New submission from Rodolfo Alonso : When using Pycharm to execute unit/functional tests (OpenStack development), oslo_privsep.daemon._ClientChannel.out_of_band retrieves the record from the input arguments. Pycharm arguments are stored in a dictionary using bytes instead of strings. When

[issue36032] Wrong output in tutorial (3.1.2. Strings)

Stéphane Wirtel added the comment: and when you execute the examples, the REPL does not generate the triple points. For me, the examples of the tuto are correct and we don't need to add '...' in the examples. -- ___ Python tracker

[issue36032] Wrong output in tutorial (3.1.2. Strings)

Stéphane Wirtel added the comment: @serhiy I think Amit wants to say there is no triple point in these examples of the tutorial. -- nosy: +matrixise ___ Python tracker ___

[issue36032] Wrong output in tutorial (3.1.2. Strings)

Amit Amely added the comment: But it also contains an error message part which has nothing to do with this example (marked in dark green) This only works with two literals though, not with variables or expressions: >>> prefix = 'Py'>>> prefix 'thon' # can't concatenate a variable and a

[issue36032] Wrong output in tutorial (3.1.2. Strings)

Serhiy Storchaka added the comment: The output in tutorial is correct. "..." means omitted output (we don't want to clutter examples with insignificant details). -- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed

[issue36032] Wrong output in tutorial (3.1.2. Strings)

: Documentation messages: 335905 nosy: Amit Amely, docs@python priority: normal severity: normal status: open title: Wrong output in tutorial (3.1.2. Strings) versions: Python 2.7

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

Jurjen N.E. Bos added the comment: Yes. That would make me happy. In the meantime I learned how to use git, so maybe I'll do the pull request myself next time. Thanks for the work. -- ___ Python tracker

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

Nasir Hussain added the comment: Hi, Should I convert patch into PR? Thanks -- nosy: +nasirhjafri ___ Python tracker ___ ___

[issue32603] Deprecation warning on strings used in re module

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

STINNER Victor added the comment: A solution to make time.strftime() more portable would be to split the format string, format each "%xxx" substring separately but don't pass substrings between "%xxx" to strftime(). There is a similar discussion about trailing "%": bpo-35066. --

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by Tal Einat : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 ___ Python tracker ___

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by Tal Einat : -- pull_requests: -11135, 11137 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by Tal Einat : -- pull_requests: -11135, 11137, 11139 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by Tal Einat : -- pull_requests: -11135 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

miss-islington added the comment: New changeset 77b80c956f39df34722bd8646cf5b83d149832c4 by Miss Islington (bot) in branch '2.7': bpo-34512: Document platform-specific strftime() behavior for non-ASCII format strings (GH-8948) https://github.com/python/cpython/commit

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

miss-islington added the comment: New changeset 678c5c07521caca809b1356d954975e6234c49ae by Miss Islington (bot) in branch '3.7': bpo-34512: Document platform-specific strftime() behavior for non-ASCII format strings (GH-8948) https://github.com/python/cpython/commit

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by miss-islington : -- pull_requests: +11135, 11136, 11137, 11138, 11139 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by miss-islington : -- pull_requests: +11135, 11136, 11137, 11139 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by miss-islington : -- pull_requests: +11134, 11135, 11136, 11137 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by miss-islington : -- pull_requests: +11134, 11135 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by miss-islington : -- pull_requests: +11134, 11135, 11136 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Change by miss-islington : -- pull_requests: +11134 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

Tal Einat added the comment: New changeset 1cffd0eed313011c0c2bb071c8affeb4a7ed05c7 by Tal Einat (Alexey Izbyshev) in branch 'master': bpo-34512: Document platform-specific strftime() behavior for non-ASCII format strings (GH-8948) https://github.com/python/cpython/commit

[issue33817] PyString_FromFormatV() fails to build empty strings

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

[issue33817] PyString_FromFormatV() fails to build empty strings

miss-islington added the comment: New changeset d39c19255910b9dce08c595f511597e98b09e91f by Miss Islington (bot) in branch '3.7': bpo-33817: Fix _PyBytes_Resize() for empty bytes object. (GH-11516) https://github.com/python/cpython/commit/d39c19255910b9dce08c595f511597e98b09e91f --

[issue33817] PyString_FromFormatV() fails to build empty strings

Serhiy Storchaka added the comment: New changeset 08a81df05004147ee174ece645679576ab867860 by Serhiy Storchaka in branch '2.7': bpo-33817: Fix _PyString_Resize() and _PyUnicode_Resize() for empty strings. (GH-11515) https://github.com/python/cpython/commit

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by miss-islington : -- pull_requests: +11129, 11130 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33817] PyString_FromFormatV() fails to build empty strings

Serhiy Storchaka added the comment: New changeset 44cc4822bb3799858201e61294c5863f93ec12e2 by Serhiy Storchaka in branch 'master': bpo-33817: Fix _PyBytes_Resize() for empty bytes object. (GH-11516) https://github.com/python/cpython/commit/44cc4822bb3799858201e61294c5863f93ec12e2

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by miss-islington : -- pull_requests: +11129 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by Serhiy Storchaka : -- pull_requests: +11082, 11083 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by Serhiy Storchaka : -- pull_requests: +11082, 11083, 11084 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by Serhiy Storchaka : -- keywords: +patch, patch, patch pull_requests: +11079, 11080, 11081 stage: -> patch review ___ Python tracker ___

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by Serhiy Storchaka : -- pull_requests: +11082 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +11079 stage: -> patch review ___ Python tracker ___ ___

[issue33817] PyString_FromFormatV() fails to build empty strings

Change by Serhiy Storchaka : -- keywords: +patch, patch pull_requests: +11079, 11080 stage: -> patch review ___ Python tracker ___

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

Change by Terry J. Reedy : -- pull_requests: -10994 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

Change by Terry J. Reedy : -- pull_requests: -10995 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

miss-islington added the comment: New changeset 6f76ef81596bbd885957b7fea3f40024ed9d6797 by Miss Islington (bot) in branch '3.7': bpo-35641: Move IDLE blurb to IDLE directory (GH-11479) https://github.com/python/cpython/commit/6f76ef81596bbd885957b7fea3f40024ed9d6797 --

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

Change by miss-islington : -- pull_requests: +10993, 10994 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

Change by miss-islington : -- pull_requests: +10993 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

Change by miss-islington : -- pull_requests: +10993, 10994, 10995 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35641] IDLE: calltips not properly formatted for functions without doc-strings

Terry J. Reedy added the comment: New changeset ee6559436797032b816dfb8c6376c9a451014962 by Terry Jan Reedy in branch 'master': bpo-35641: Move IDLE blurb to IDLE directory (#11479) https://github.com/python/cpython/commit/ee6559436797032b816dfb8c6376c9a451014962 --

<    7   8   9   10   11   12   13   14   15   16   >