[issue3530] ast.NodeTransformer doc bug

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

[issue3530] ast.NodeTransformer doc bug

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

[issue39167] argparse boolean type bug

Trenton Bricken added the comment: Thanks for all of these replies. The functionality is that the user adds --flag True False and then all of the other parameters are run with True. And then again with False. I thought this was a bug because of the confusing type=bool behavior

[issue39167] argparse boolean type bug

Change by Josh Rosenberg : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> ArgumentParser should support bool type according to truth values ___ Python tracker

[issue39167] argparse boolean type bug

Change by Mark Dickinson : -- Removed message: https://bugs.python.org/msg359060 ___ Python tracker ___ ___ Python-bugs-list

[issue39167] argparse boolean type bug

Mark Dickinson added the comment: This looks like a duplicate of #37564. -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue39167] argparse boolean type bug

paul j3 added the comment: The rejected boolean type proposal: https://bugs.python.org/issue37564 -- ___ Python tracker ___ ___

[issue39167] argparse boolean type bug

like 'False', 'true', 'no', 'oui', 'niet', but if you want to convert those to boolean True/False values, you need to write your own 'type' function. There was a recent bug/issue that proposed providing such a function (or importing it from another module), and shadowing the existing 'bool

[issue39167] argparse boolean type bug

Trenton Bricken added the comment: Thank you for your quick and helpful reply. The problem with your solution is twofold: 1. it adds some cognitive load in needing to remember whether or not the flag defaults to True or False and thus whether or not you need to add it. It is easier for me

[issue39167] argparse boolean type bug

Karthikeyan Singaravelan added the comment: It seems like this is a common problem : https://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse . I guess you want to store verbose=True when --verbose is passed and verbose=False when --verbose is not passed where

[issue39167] argparse boolean type bug

Trenton Bricken added the comment: Update: I was being dumb before, the problem still remains but my work around previously was wrong. This is the new workaround: def buildBool(arg): if arg == 'False': return False else: return True --

[issue39167] argparse boolean type bug

New submission from Trenton Bricken : This is a bug with argparse. Say I have: parser.add_argument('--verbose', type=bool, action='store', nargs='+', default = [False], help='turns on verbosity') If in the command line I have "--verbose

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

STINNER Victor added the comment: Thanks for the fix. That was an interesting bug ;-) I like the simplicity of the fix. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

Antoine Pitrou added the comment: Thank you Jake for the report and PR! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 ___ Python tracker

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

miss-islington added the comment: New changeset 829593a9262e67c72167c6cb20d383203b2ea410 by Miss Islington (bot) in branch '3.8': bpo-38707: Fix for multiprocessing.Process MainThread.native_id (GH-17088) https://github.com/python/cpython/commit/829593a9262e67c72167c6cb20d383203b2ea410

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

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

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

miss-islington added the comment: New changeset c6b20be85c0de6f2355c67ae6e7e578941275cc0 by Miss Islington (bot) (Jake Tesler) in branch 'master': bpo-38707: Fix for multiprocessing.Process MainThread.native_id (GH-17088)

[issue3530] ast.NodeTransformer doc bug

Change by Terry J. Reedy : -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6 ___ Python tracker ___

[issue3530] ast.NodeTransformer doc bug

Terry J. Reedy added the comment: I re-verified the problem, its presence in the doc, and the fix with 3.9. -- ___ Python tracker ___

[issue3530] ast.NodeTransformer doc bug

Change by Batuhan : -- keywords: +patch pull_requests: +16681 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/17172 ___ Python tracker

[issue38808] weird bug while using a for loop and array

Zach kuunka added the comment: I will check that out, Thank you -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38808] weird bug while using a for loop and array

Mark Dickinson added the comment: This isn't a bug: it's the way that Python's assignment model works. This is explained in various places (including the official Python documentation), but you may find this excellent presentation by Ned Batchelder useful: https://nedbatchelder.com/text

[issue38808] weird bug while using a for loop and array

Zach kuunka added the comment: I found out it just happens when you set an array to an array they behave as the same thing, which if its not a bug it sure is counter-intuitive. if you do x = 1 then y = x then add one to y you have y = 2 and x = 1 if you do it for an array arr1 = [1

[issue38808] weird bug while using a for loop and array

New submission from Zach kuunka : I haven't used this bug reporting thing before so sorry if I mess something up. Anyway i'm not sure exactly what is causing the issue but the issue appears when you have a for loop looping through an array and you make a variable and set it to that array

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

Jake Tesler added the comment: PR was updated with tests and is ready for core developer review and then the merge to cpython:master. After that (if I understand correctly) a backport will automatically get picked into the 3.8 branch if there aren't any conflicts. --

[issue38771] Bug in example of collections.ChainMap

Raymond Hettinger added the comment: New changeset d8e08456025d9349abbf76035c821d3f7b2d722a by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-38771: Explict test for None in code example (GH-17108) (GH-17109)

[issue38771] Bug in example of collections.ChainMap

Raymond Hettinger added the comment: New changeset cb1c06e3bfbce7f4e8dcb0db84bcee54c8d4fa21 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7': bpo-38771: Explict test for None in code example (GH-17108) (GH-17110)

[issue38771] Bug in example of collections.ChainMap

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 ___ Python tracker ___

[issue38771] Bug in example of collections.ChainMap

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

[issue38771] Bug in example of collections.ChainMap

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

[issue38771] Bug in example of collections.ChainMap

Raymond Hettinger added the comment: New changeset 98480cef9dba04794bd61c7e7cca643d384c8c35 by Raymond Hettinger (Jonathan Scholbach) in branch 'master': bpo-38771: Explict test for None in code example (GH-17108)

[issue38771] Bug in example of collections.ChainMap

Raymond Hettinger added the comment: The example was just meant to be a quick snippet to suggest a possible use case. It isn't a stand-alone application. However, stylistically, this is an improvement and I'll accept some variation of the PR. -- priority: normal -> low versions:

[issue38771] Bug in example of collections.ChainMap

Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list

[issue38771] Bug in example of collections.ChainMap

Change by Jonathan Scholbach : -- keywords: +patch pull_requests: +16614 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17108 ___ Python tracker

[issue38771] Bug in example of collections.ChainMap

, jonathan.scholbach priority: normal severity: normal status: open title: Bug in example of collections.ChainMap versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bug

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

Change by Ned Deily : -- nosy: +davin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

Jake Tesler added the comment: @vstinner PR created :) https://github.com/python/cpython/pull/17088 -- ___ Python tracker ___ ___

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

Change by Jake Tesler : -- keywords: +patch pull_requests: +16596 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17088 ___ Python tracker ___

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

STINNER Victor added the comment: > See the branch here: > https://github.com/jaketesler/cpython/tree/fix-mp-native-id Can you please create a PR? -- ___ Python tracker ___

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

Change by Jake Tesler : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()

New submission from Jake Tesler : I have encountered a minor bug with the new `threading.get_native_id()` featureset in Python 3.8. The bug occurs when creating a new multiprocessing.Process object on Unix (or on any platform where the multiprocessing start_method is 'fork' or 'forkserver

[issue38495] print built-in function docs bug

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

[issue38637] fix GROWTH_RATE comments bug

Brandt Bucher added the comment: This PR was closed as invalid for the same reasons Steven mentioned above. -- nosy: +brandtbucher resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bug

[issue38637] fix GROWTH_RATE comments bug

Steven D'Aprano added the comment: Please explain the bug here on the bug tracker, people shouldn't have to drill down into the PR to find out what it means. Before fixing the bug, you should find out whether or not it actually is a bug. In my testing, the comment is approximately correct

[issue38637] fix GROWTH_RATE comments bug

New submission from toywei : It also exists in 3.7/3.6/3.3. -- assignee: docs@python components: Documentation messages: 355688 nosy: docs@python, toywei priority: normal pull_requests: 16516 severity: normal status: open title: fix GROWTH_RATE comments bug type: resource usage

[issue38611] Bug in traceback.py

diving in, wasn't sure which path people would prefer to see fixed? The code in traceback.py is from lines 516 - 521. -- components: Library (Lib) messages: 355518 nosy: jamercee priority: normal severity: normal status: open title: Bug in traceback.py versions: Python 3.8

[issue38512] bug of the v3.7 API document demo case code

Steven D'Aprano added the comment: What is this a screen shot of? What error occurs? The picture doesn't show any errors that I can see. Please COPY and PASTE the code you are running, as text, and the FULL EXCEPTION (the traceback and error message), if there is one. We cannot guess what

[issue38512] bug of the v3.7 API document demo case code

Change by zr22122 <2212239...@qq.com>: -- title: bug of the v3.8 api demo case -> bug of the v3.7 API document demo case code ___ Python tracker <https://bugs.python.or

[issue38512] bug of the v3.8 api demo case

New submission from zr22122 <2212239...@qq.com>: There exists a bug in the python 3.7 API document, as the picture shows below. When run this code in my python3.7.3 windows7 os, error occurs. -- components: Regular Expressions files: 2.png messages: 354871 nosy: ezio.m

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Walter Dörwald added the comment: codecs.iterencode()/iterdecode() are just shallow 10-line wrappers around incremental codecs (which are used as the basis of io streams). Note that the doc string for iterencode() contains: Encodes the input strings from the iterator using an

[issue38503] bug: string search can find \n, but can NEVER find \r

Inada Naoki added the comment: It is "universal newline". See https://docs.python.org/3/library/functions.html#open and https://docs.python.org/3/glossary.html#term-universal-newlines -- nosy: +inada.naoki resolution: -> not a bug stage: -> resolved status

[issue38503] bug: string search can find \n, but can NEVER find \r

.csv', >>> 'rb').read().count(b'\r') 88 >>> open('./3cjkxdnw/accessibilityLog/1570181896323.csv').read().count('\r') 0 >>> type(open('./3cjkxdnw/accessibilityLog/1570181896323.csv').read()) >>> type('\r') Thanks! -- messages: 354834 nosy: xuancong84 priority

[issue38495] print built-in function docs bug

Serhiy Storchaka added the comment: Maybe just explain defaults in the text? Print *objects* to the text stream *file* (the standard output by default), separated by *sep* (a space by default) and followed by *end* (a newline by default). -- nosy: +serhiy.storchaka

[issue38495] print built-in function docs bug

Inada Naoki added the comment: https://github.com/sphinx-doc/sphinx/pull/6401/files Recent Sphinx uses . So we can add style like this: .sig-paren { font-family: monospace, sans-serif; font-style: normal; } -- ___ Python tracker

[issue38495] print built-in function docs bug

Inada Naoki added the comment: Space is not trimmed. You can confirm there is a space by copy it from rendered HTML. print(*objects, sep=' ', end='\n', file=sys.stdout, flush=False)¶ So this is caused by rendering sep=' '. I don't like , but I'm not sure this can be customized by theme.

[issue38495] print built-in function docs bug

Karthikeyan Singaravelan added the comment: In the sphinx source it's ' ' so maybe it's a problem with the rendering part. https://raw.githubusercontent.com/python/cpython/master/Doc/library/functions.rst .. function:: print(*objects, sep=' ', end='\\n', file=sys.stdout, flush=False)

[issue38495] print built-in function docs bug

New submission from Alex Mashianov : Python docs says print() function default sep='': http://joxi.ru/EA44JnfonNwLAb.png While in reality sep=' ': http://joxi.ru/n2YXyRsbw6oYm6.png Probably it's a bug with space not being escaped in html to prevent trimming. -- assignee: docs@python

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Jim Carroll added the comment: I understand. btw; I did a deep dive on cpython codebase, and the only references to codecs.iterencode()/iterdecode() is in ./Lib/tests/test_codecs.py. I suspect functions are not used by many people. The patch I proposed was a three line change that would

[issue38485] BUG Modules/_io/texio.c

Change by Serhiy Storchaka : -- components: +IO nosy: +benjamin.peterson, stutzbach type: -> behavior versions: +Python 2.7, Python 3.8, Python 3.9 ___ Python tracker ___

[issue38485] BUG Modules/_io/texio.c

(tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32 -- messages: 354733 nosy: jamercee priority: normal severity: normal status: open title: BUG Modules/_io/texio.c versions: Python 3.7 ___ Python tracker <ht

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Walter Dörwald added the comment: The documentation might be unclear here. But the argument iterator of iterdecode(iterator, encoding, errors='strict', **kwargs) *is* supposed to be an iterable over bytes objects. In fact iterencode() transforms an iterator over strings into an iterator

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Jim Carroll added the comment: According to the documentation (https://docs.python.org/3.7/library/codecs.html#codecs.iterdecode), the first parameter is a bytes object to decode (not an iterable of bytes). Which is also consistent with it's companion iterencode() which accepts a str

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Serhiy Storchaka added the comment: The first argument of iterdecode() should be an iterable of bytes objects, not a bytes object. Try codecs.iterdecode([enc], 'utf-8') -- nosy: +serhiy.storchaka ___ Python tracker

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Change by Jim Carroll : Added file: https://bugs.python.org/file48662/codecs.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38482] BUG in codecs.BufferedIncrementalDecoder

Change by Jim Carroll : Removed file: https://bugs.python.org/file48661/codecs.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38482] BUG in codecs.BufferedIncrementalDecoder

\codecs.py", line 1048, in iterdecode output = decoder.decode(input) File "C:\Python37\lib\codecs.py", line 321, in decode data = self.buffer + input TypeError: can't concat int to bytes -- components: Library (Lib) files: codecs.patch keywords: patch mes

[issue38389] Bug on sorted with count key

Benjamin Peterson added the comment: 5 and 12 both appear twice in the list, so as far as the key function is concerned, they're equal. -- nosy: +benjamin.peterson resolution: -> not a bug stage: -> resolved status: open -> closed _

[issue38389] Bug on sorted with count key

[4, 5, 12, 12, 5, 2, 2, 2, 3, 3, 3, 3] should be [4, 5, 5, 12, 12, 2, 2, 2, 3, 3, 3, 3] -- messages: 354063 nosy: Tamirys Pino priority: normal severity: normal status: open title: Bug on sorted with count key type: behavior versions: Python 3.6 __

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

Vinay Sajip added the comment: This could perhaps be handled by just swallowing errors in the constructor (as is done for Unix sockets, for example) and trying to connect in emit() if there is no connection. Not sure I want to go down the caching route - it complicates things for what is a

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

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

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

Enji Cooper added the comment: Capturing more context here, based on internal discussion: other handlers are doing address resolution in `emit()` (HTTPHandler, SMTPHandler), which is expensive. In order for SysLogHandler to not regress behavior and not become expensive, performance-wise, it

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

Change by Enji Cooper : -- title: Fix for bug 30378 regressed SysLogHandler -> Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()` ___ Python tracker <https://bugs.pyth

[issue38354] Fix for bug 30378 regressed SysLogHandler

New submission from Enji Cooper : The change made for bug 30378 caused a regression in our code by making lookups for SysLogHandler addresses at init time, instead of making them more lazy. Example: >>> import logging.handlers >>> LOGGER = logging.getLogger("logger&

[issue38195] A bug in the multiprocessing module

Change by Terry J. Reedy : -- nosy: +davin, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38196] Bug fix in folderstats module

Serhiy Storchaka added the comment: This tracker is for bugs in the C implementation of Python. "foldersize" is not a module from the standard Python library. Use the corresponding bug tracker for reporting a bug in third-party modules. -- nosy: +serhiy.storchaka

[issue38196] Bug fix in folderstats module

: open title: Bug fix in folderstats module type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue38196> ___ ___ Python-bugs-list mailin

[issue38195] A bug in the multiprocessing module

New submission from eshkrig : Hi! I found a bug in the multiprocessing module. The documentation (https://docs.python.org/3.6/library/multiprocessing.html) for the Queue.get method says: "If timeout is a positive number, it blocks at most timeout seconds ..." But the Queue.

Re: Weird Python Bug

On 2019-09-13 20:17, CrazyVideoGamez wrote: For some reason, if you put in the code def odd_ones_out(numbers): for num in numbers: count = numbers.count(num) if not count % 2 == 0: for i in range(count): numbers.remove(num) return

RE: Weird Python Bug

2, 67, 67] >>> odd_ones_out(nums) [4, 67, 67] >>> nums [4, 67, 67] >>> -Original Message- From: Python-list On Behalf Of CrazyVideoGamez Sent: Friday, September 13, 2019 3:18 PM To: python-list@python.org Subject: Weird Python Bug For some reason, if you put i

Weird Python Bug

For some reason, if you put in the code def odd_ones_out(numbers): for num in numbers: count = numbers.count(num) if not count % 2 == 0: for i in range(count): numbers.remove(num) return numbers nums = [72, 4, 82, 67, 67]

[issue38139] [BUG] datetime.strptime could not handle timezone

Paul Ganssle added the comment: Hi Yixing, thank you for your bug report. This issue has already been reported, and the discussion is in issue #22377. In the short term I believe the solution will be to document the current behavior. In the long term there are some solutions, though I

[issue38139] [BUG] datetime.strptime could not handle timezone

Karthikeyan Singaravelan added the comment: This seems to be same as issue22377 where UTC, GMT and value time.tzname in the machine are the supported values. -- nosy: +xtreak ___ Python tracker

[issue38139] [BUG] datetime.strptime could not handle timezone

Change by Karthikeyan Singaravelan : -- type: crash -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38139] [BUG] datetime.strptime could not handle timezone

Change by Karthikeyan Singaravelan : -- nosy: +belopolsky, p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38139] [BUG] datetime.strptime could not handle timezone

t;> datetime.datetime.strptime('20190911183517334000', '%Y%m%d%H%M%S%f') datetime.datetime(2019, 9, 11, 18, 35, 17, 334000) ``` so strptime could only handle the format without %Z. -- components: Library (Lib) messages: 352163 nosy: Yixing Jiang priority: normal severity: normal statu

[issue433625] bug in PyThread_release_lock()

Kirill Smelkov added the comment: I still believe there is a race here and it can lead to MEMORY CORRUPTION and DEADLOCK: https://bugs.python.org/issue38106. -- nosy: +navytux ___ Python tracker

[issue34293] DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar

Zachary Ware added the comment: New changeset 12228ce41de1b8fcfb3f1ba0a86d98a232815e85 by Zachary Ware in branch '3.7': [3.7] bpo-34293: Fix PDF documentation paper size (GH-8585) (GH-15817) https://github.com/python/cpython/commit/12228ce41de1b8fcfb3f1ba0a86d98a232815e85 --

[issue34293] DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar

Zachary Ware added the comment: New changeset 99df5e837334b62c29c979bb0806f525778a4f3e by Zachary Ware in branch '3.8': [3.8] bpo-34293: Fix PDF documentation paper size (GH-8585) (GH-15816) https://github.com/python/cpython/commit/99df5e837334b62c29c979bb0806f525778a4f3e --

[issue34293] DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar

Zachary Ware added the comment: Thank you for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker

[issue34293] DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar

Change by Zachary Ware : -- pull_requests: +15465 pull_request: https://github.com/python/cpython/pull/15817 ___ Python tracker ___

[issue34293] DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar

Change by Zachary Ware : -- pull_requests: +15464 pull_request: https://github.com/python/cpython/pull/15816 ___ Python tracker ___

[issue34293] DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar

Zachary Ware added the comment: New changeset b5381f669718aa19690f42f3b8bd88f03045b9d2 by Zachary Ware (Jean-François B) in branch 'master': bpo-34293: Fix PDF documentation paper size (GH-8585) https://github.com/python/cpython/commit/b5381f669718aa19690f42f3b8bd88f03045b9d2 --

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Change by Sanyam Khurana : -- pull_requests: +14935 pull_request: https://github.com/python/cpython/pull/15206 ___ Python tracker ___

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Kostis Anagnostopoulos added the comment: > > BTW, i went back to my code and pasted what seemed to cure the problem, > added in commit 2b99cec in my PR. But i don't have much time to track if it really works. I hope it will help you resolve the issue. Best, Kostis --

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Kostis Anagnostopoulos added the comment: Dear Sanyam, My apologies, it's been almost a year that i don't need the fix for this code, my app has been graciously decommissioned, and i don;t have any time for it. Best, Kostis On Fri, 9 Aug 2019 at 21:35, Sanyam Khurana wrote: > > Sanyam

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Sanyam Khurana added the comment: Hey ankostis, Please let us know if you've time to complete the PR. Thank you :) -- ___ Python tracker ___

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Sanyam Khurana added the comment: Removing 3.5 as it is in security fix mode. Also, the PR just contains the test case that would trigger the condition and not the actual code. -- nosy: +CuriousLearner stage: -> patch review versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5

[issue37787] Minimum denormal or ** bug

Steve Dower added the comment: Only half serious ;) I'd settle for "reliable, consistent and easy to explain rounding", which is unfortunately not what IEEE 754 provides (unless you assume significant amounts of CS background that most Python users do not have). But then, nothing else

[issue37787] Minimum denormal or ** bug

Tim Peters added the comment: Since this depends on the platform libm implementation of pow(), I'm closing this as "won't fix". Steve, on the chance you're serious ;-) , there are implementations of the "constructive reals", which indeed act like infinite-precision floats. But they tend

[issue37787] Minimum denormal or ** bug

Steve Dower added the comment: I have nothing to contribute here. Tim's right. (I would love Python to have infinite precision float by default...) -- ___ Python tracker ___

<    5   6   7   8   9   10   11   12   13   14   >