[issue41199] Docstring convention not followed for dataclasses documentation page

Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) added the comment: Please go ahead and create a PR. -- nosy: +thatiparthy ___ Python tracker ___

[issue41199] Docstring convention not followed for dataclasses documentation page

Wansoo Kim added the comment: May I solve this issue? -- nosy: +ys19991 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41253] unittest -h shows a flag -s but it doesn't work

Karthikeyan Singaravelan added the comment: The -s option shown in `python3 -m unittest -h` is grouped under help for discover. Options for a discover command don't necessarily apply to the unittest command itself. $ python3 -m unittest -h usage: python3 -m unittest [-h] [-v] [-q]

[issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong

Serhiy Storchaka added the comment: It was not officially dropped. It was kept as a joke. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue41250] Number separators in different places

Raymond Hettinger added the comment: This was considered in PEP 378 — Format Specifier for Thousands Separator.¹ The decision was to keep it simple and only support groups of three digits using a comma as the separator. FWIW, the decimal documentation has a formatting recipe that could be

[issue41253] unittest -h shows a flag -s but it doesn't work

Serhiy Storchaka added the comment: Where do you see option -s? -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue41253] unittest -h shows a flag -s but it doesn't work

New submission from Faris Chugthai : I'm not 100% sure what's happening here but running: `python -m unittest -h` shows a flag `-s` as does `python -m unittest discover -h`. When run as: `python -m unittest discover -s test` the command runs correctly but when run as `python -m unittest

[issue41250] Number separators in different places

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

[issue41252] Incorrect reference counting in _ssl.c's _servername_callback()

Change by Zackery Spytz : -- keywords: +patch pull_requests: +20557 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21407 ___ Python tracker ___

[issue41252] Incorrect reference counting in _ssl.c's _servername_callback()

New submission from Zackery Spytz : In _servername_callback(), servername_bytes will be used after being decrefed if PyUnicode_FromEncodedObject() fails. -- assignee: christian.heimes components: Extension Modules, SSL messages: 373371 nosy: ZackerySpytz, christian.heimes priority:

[issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong

Change by wyz23x2 : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong

wyz23x2 added the comment: Help on _Feature in module __future__ object: class

[issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong

Change by wyz23x2 : -- components: +Library (Lib) versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker ___

[issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong

New submission from wyz23x2 : __future__.barry_as_FLUFL turns x!=y into x<>y. But the doc by help() says: Help on _Feature in module __future__ object:

[issue41250] Number separators in different places

wyz23x2 added the comment: Q: Why not use f"{var:,}".replace(',', sepchar) for the sepchar parameter? A: It is very complicated in the case below: num = 1234567 text = 'Hello, world!' print(f"{num:,}{text}").replace(',', ' ') # Becomes '1 234 567Hello world!' print(f"{f'{num:,}'.replace(',', '

[issue41250] Number separators in different places

New submission from wyz23x2 : The current syntax is this for thousand separators: f'{var:,}' It will return this when var is 1234567: '1,234,567' But sometimes we need a way to insert them in other places. For example: 123456789 → '1,2345,6789' (4) 62938757312 → '6,29387,57312' (5) This could be

[issue41239] SSL Certificate verify failed in Python3.6/3.7

Wu Wenyan added the comment: OK. Thanks for your suggestion. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37765] IDLE: Include keywords in module-level autocomplete list

Terry J. Reedy added the comment: Tal, I suggested the compromise because of your original objection. Since you think half is worse than all, I will revert the change. It did get me to do a needed rewrite of the Completions section of the IDLE doc. -- title: IDLE: Include longer

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

Cooper Lees added the comment: Yury, only problem with that is aiohttp hard blocks HTTPS proxies period. The aiohttp issue says they won't fix this until asyncio supports it. Kinda understand that. [cooper:~]$ ./aioclient.par HTTPS proxies https://fwdproxy:8082 are not supported, ignoring

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

Abhilash Raj added the comment: Thanks Mark! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

Abhilash Raj added the comment: Closing this since the PRs for the behavior change reported by Mike and BPO-41206 is now merged too. -- nosy: +maxking stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue41206] behaviour change with EmailMessage.set_content

Abhilash Raj added the comment: I have merged https://github.com/python/cpython/pull/20542 and backported to 3.8 and 3.9 branches (https://github.com/python/cpython/pull/21404 & https://github.com/python/cpython/pull/21405). Closing this issue. -- resolution: -> fixed stage: patch

[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules

Change by Guido van Rossum : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules

New submission from Keith Blaha : Copied from https://github.com/python/typing/issues/737 I came across this issue while using inheritance to express required keys in a TypedDict, as is recommended by the docs. It's most easily explained by a minimal example I cooked up. Let's say we have a

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

Change by Cooper Lees : -- keywords: +patch pull_requests: +20556 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17975 ___ Python tracker ___

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

Yury Selivanov added the comment: Looks like https://github.com/python/cpython/pull/17975 was forgotten and was never committed to 3.9. So it's 3.10 now. Best bet for you is to use uvloop which should support the feature. -- ___ Python tracker

[issue34624] -W option and PYTHONWARNINGS env variable does not accept module regexes

Marco Paolini added the comment: hello Thomas, do you need any help fixing the conflicts in your PR? even if Lib/warnings.py changed a little in the last 2 years, your PR is still good! -- nosy: +mpaolini ___ Python tracker

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

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

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: $ PYTHONWARNINGS=ignore gdb --args /home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python ./repro.py GNU gdb (GDB) Fedora 9.1-5.fc32 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: "Short" reproducer: repro.py: ``` import sys from os import getcwd, chdir from runpy import run_path def smoke_test(script, *args): old_argv = list(sys.argv) del sys.argv[:] sys.argv.append(script) sys.argv.extend(args) old_modules =

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

Cooper Lees added the comment: Another bump since I've waiting over a year. Any plans for this? Will it make 3.10? Anything I can do? -- versions: +Python 3.10 -Python 3.8 ___ Python tracker

[issue41247] asyncio.set_running_loop() cache running loop holder

Change by Tony : -- pull_requests: +20555 pull_request: https://github.com/python/cpython/pull/21406 ___ Python tracker ___ ___

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

miss-islington added the comment: New changeset e68978978f49cfc489fa0f888281ce84460818c0 by Miss Islington (bot) in branch '3.9': bpo-40597: Allow email.contextmanager set_content() to set a null string. (GH-20542)

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

miss-islington added the comment: New changeset c1c50345933efca42169f03d79ff4fe3d9c06bdc by Miss Islington (bot) in branch '3.8': bpo-40597: Allow email.contextmanager set_content() to set a null string. (GH-20542)

[issue41093] TCPServer's server_forever() shutdown immediately when calling shutdown()

Tony added the comment: bump -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: I'm working on a short reproducer, but otherwise reproducer is exactly the same as described in https://bugs.python.org/issue41194#msg372854 The way I bumped into this is trying to confirm the fix in Beta 4 (which apparently didn't make it, as you

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

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

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

miss-islington added the comment: New changeset 4fa61a7732923f92de0f7830c12da48c4cec937f by Mark Sapiro in branch 'master': bpo-40597: Allow email.contextmanager set_content() to set a null string. (GH-20542) https://github.com/python/cpython/commit/4fa61a7732923f92de0f7830c12da48c4cec937f

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

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

[issue41202] Allow to provide custom exception handler to asyncio.run()

Kyle Stanley added the comment: Yep, having to set a custom exception handler definitely constitutes as needing "finer control over the event loop behavior". There's absolute nothing wrong with using the low-level API when you need further customization, but we try to minimize the

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

STINNER Victor added the comment: I checked manually that msg372859 example is fixed. > @vstinner, this is in the current 3.9 as of > a0a6f1167834c87f12e2eca11dd77143103e7691 (11hrs ago). We didn't get the > actual bug, we just got stopped by an assertion when python got built with >

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: @vstinner, this is in the current 3.9 as of a0a6f1167834c87f12e2eca11dd77143103e7691 (11hrs ago). We didn't get the actual bug, we just got stopped by an assertion when python got built with debug. -- ___ Python

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

STINNER Victor added the comment: > Thanks for doing this. I can confirm the performance regression is fixed and > that clean code is being generated for PyTuple_Check(). Thanks for checking! > BTW, I support your efforts — just wanted to make sure we didn't > unintentionally take a step

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

STINNER Victor added the comment: > I'm reopening this as the original SEGV didn't go away in 3.9 beta 4. It > looks like debug build caught an assertion and prevented the SEGV from > triggering. Right, the fix was merged after v3.9.0b4 was merged. The fix will be part of the next 3.9

[issue41175] Static analysis issues reported by GCC 10

STINNER Victor added the comment: New changeset 61fc23ca106bc82955b0e59d1ab42285b94899e2 by stratakis in branch 'master': bpo-41175: Guard against a NULL pointer dereference within bytearrayobject (GH-21240) https://github.com/python/cpython/commit/61fc23ca106bc82955b0e59d1ab42285b94899e2

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: > Program received signal SIGSEGV, Segmentation fault. 0x00623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 ) at ./Include/object.h:128 128 return ob->ob_type == type; (gdb) py-bt Traceback (most recent call first): File

[issue39017] Infinite loop in the tarfile module

Ben Caller added the comment: A smaller bug: If instead of 0 you use a large number (> 2^63) e.g. 999 you get `OverflowError: Python int too large to convert to C ssize_t` rather than the expected `tarfile.ReadError` regardless of errorlevel. --

[issue41247] asyncio.set_running_loop() cache running loop holder

miss-islington added the comment: New changeset fbd71f66843aea71c09656f17a196d29d5d484af by Miss Islington (bot) in branch '3.9': bpo-41247: asyncio.set_running_loop() cache running loop holder (GH-21401) https://github.com/python/cpython/commit/fbd71f66843aea71c09656f17a196d29d5d484af

[issue39017] Infinite loop in the tarfile module

Ben Caller added the comment: I've attached a minimal tar file which reproduces this. I think the minimum length is 516 bytes. We need a 512 byte PAX format header block as normal. Then we need a pax header which matches the regex in

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

Raymond Hettinger added the comment: Thanks for doing this. I can confirm the performance regression is fixed and that clean code is being generated for PyTuple_Check(). BTW, I support your efforts — just wanted to make sure we didn't unintentionally take a step backwards. -- nosy:

[issue41247] asyncio.set_running_loop() cache running loop holder

Yury Selivanov added the comment: > n python to know if there could be a context switch to get_running_loop while > set_running_loop is running. No, it's protected by the GIL. Good catch, and merged. -- nosy: +yselivanov resolution: -> fixed stage: patch review -> resolved

[issue41247] asyncio.set_running_loop() cache running loop holder

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

[issue41247] asyncio.set_running_loop() cache running loop holder

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

[issue41247] asyncio.set_running_loop() cache running loop holder

miss-islington added the comment: New changeset 529f42645d38b6b0075f256814dfb3d220ac7d92 by Tony Solomonik in branch 'master': bpo-41247: asyncio.set_running_loop() cache running loop holder (GH-21401) https://github.com/python/cpython/commit/529f42645d38b6b0075f256814dfb3d220ac7d92

[issue41248] Python manual forced in maximized window

New submission from Mischiew Rithe : In versions 3.8.1 and 3.8.3-amd64 (only versions tested), on Windows, the "Python 3.8 Manuals" opens in a maximized window. This is unexpected and undesired, as the user cannot see the other windows, including the one he's developing from (IDE, editor,

[issue41247] asyncio.set_running_loop() cache running loop holder

Change by Tony : -- title: asyncio module better caching for set and get_running_loop -> asyncio.set_running_loop() cache running loop holder ___ Python tracker ___

[issue41247] asyncio.set_running_loop() cache running loop holder

Change by Tony : -- keywords: +patch pull_requests: +20550 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21401 ___ Python tracker ___

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Peter Ludemann added the comment: Yes, I'm thinking of doing this as a wrapper, in such a way that it could be incorporated into Lib/ast.py eventually. (Also, any lib2to3-ish capabilities would probably not be suitable for inclusion in the stdlib, at least not initially ... but I have no

[issue41247] asyncio module better caching for set and get_running_loop

New submission from Tony : There is a cache variable for the running loop holder, but once set_running_loop is called the variable was set to NULL so the next time get_running_loop would have to query a dictionary to receive the running loop holder. I thought why not always cache the latest

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Guido van Rossum added the comment: Can that be done as a 3rd party wrapper? Then you would be able to support older Python versions, and typed_ast (which can parse older Python grammars with a newer Python that's older than 3.8). Plus it would be much easier to get your code released -- no

[issue41244] Change to use str.join() instead of += when concatenating string

Yury Selivanov added the comment: > Changes in bpo-41242 were rejected not because the new code is worse, but > because it is not obviously and significantly better that the existing code. > Here status quo wins for the same reasons. This rule saves us from endless > rewriting the code and

[issue41245] cmath module documentation is misleading on branch cuts

Mark Dickinson added the comment: > [...] see the change of sign in the real part below [...] Grr. Stupid fingers. That should say "imaginary part", not "real part" -- ___ Python tracker

[issue41245] cmath module documentation is misleading on branch cuts

Mark Dickinson added the comment: Yes, that looks like the right part of the sqrt code. For the acos docstring, "continuous from below" implies that for any complex number z that lies exactly _on_ the branch cut, acos(z) is close to acos(w) for a nearby value w just _below_ the branch cut.

[issue41245] cmath module documentation is misleading on branch cuts

Raymond Hettinger added the comment: +1 for changing the language to match the actual mechanics. > "the sign of the imaginary part of x is used [...]" I'm trying to see where this happens. Is this part of cmath_sqrt? if (z.real >= 0.) { r.real = s; r.imag = copysign(d,

[issue41172] test_peg_generator C tests fail on Windows ARM

Change by Steve Dower : -- keywords: +patch pull_requests: +20549 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21400 ___ Python tracker ___

[issue41246] IOCP Proactor same socket overlapped callbacks

Change by Tony : -- keywords: +patch pull_requests: +20547 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21399 ___ Python tracker ___

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Peter Ludemann added the comment: I've written up a proposal for adding "whitespace" handling to the ast module: https://mail.python.org/archives/list/python-id...@python.org/thread/X2HJ6I6XLIGRZDB27HRHIVQC3RXNZAY4/ I don't think it's a "summer-of-code-sized project", mainly because I already

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: Confirmed not fixed. Taken with 3.9 branch as of today. (pyb-3.9-dev-d) [arcivanov@ai-karellen-lap pybuilder]$ abrt gdb 1f24453 GNU gdb (GDB) Fedora 9.1-5.fc32 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

[issue41245] cmath module documentation is misleading on branch cuts

Change by Mark Dickinson : -- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker

[issue41246] IOCP Proactor same socket overlapped callbacks

New submission from Tony : In IocpProactor I saw that the callbacks to the functions recv, recv_into, recvfrom, sendto, send and sendfile all give the same callback function for when the overlapped operation is done. I just wanted cleaner code so I made a static function inside the class

[issue41245] cmath module documentation is misleading on branch cuts

Mark Dickinson added the comment: > the sign of x is used [...] Correction: That should say "the sign of the imaginary part of x is used [...]" -- ___ Python tracker ___

[issue41245] cmath module documentation is misleading on branch cuts

New submission from Mark Dickinson : The documentation for the cmath module is misleading on the behaviour near branch cuts. For example, the documentation for cmath.acos says: Return the arc cosine of x. There are two branch cuts: One extends right from 1 along the real axis to ∞,

[issue41242] When concating strings, I think it is better to use += than join the list

Wansoo Kim added the comment: Well... to be honest, I'm a little confused. bpo-41244 and this issue are completely opposite. I'm not used to Python community yet because it hasn't been long since I joined it. You're saying that if a particular method is not dramatically good, we prefer to

[issue41244] Change to use str.join() instead of += when concatenating string

Serhiy Storchaka added the comment: Changes in bpo-41242 were rejected not because the new code is worse, but because it is not obviously and significantly better that the existing code. Here status quo wins for the same reasons. This rule saves us from endless rewriting the code and allows

[issue41242] When concating strings, I think it is better to use += than join the list

Serhiy Storchaka added the comment: In this particular case the number of concatenations is limited, the resulting string is usually short, and the code is not performance critical (it is the __repr__ implementation). So there is no significant advantage of one way over other, and no way is

[issue41244] Change to use str.join() instead of += when concatenating string

Zachary Ware added the comment: That is not performance-critical code, and in that case it is clearer to use `+=` than str.join. Closing the issue; Andrew or Yury can of course reopen it if they disagree with my assessment. -- nosy: +zach.ware resolution: -> wont fix stage: patch

[issue41244] Change to use str.join() instead of += when concatenating string

Change by Wansoo Kim : -- keywords: +patch pull_requests: +20546 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21398 ___ Python tracker ___

[issue41244] Change to use str.join() instead of += when concatenating string

New submission from Wansoo Kim : https://bugs.python.org/issue41242 According to BPO-41242, it is better to use join than += when concatenating multiple strings. https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/asyncio/queues.py#L82 However, the link above

[issue41194] Python 3.9.0b3 crash on compile() in PyAST_Check() when the _ast module is loaded more than once

Arcadiy Ivanov added the comment: I'm reopening this as the original SEGV didn't go away in 3.9 beta 4. It looks like debug build caught an assertion and prevented the SEGV from triggering. -- resolution: fixed -> status: closed -> open ___

[issue41243] SPAM

Change by Zachary Ware : -- components: -Interpreter Core nosy: -Deon257 versions: -Python 3.7 ___ Python tracker ___ ___

[issue41243] SPAM

Change by Zachary Ware : -- Removed message: https://bugs.python.org/msg373315 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue41242] When concating strings, I think it is better to use += than join the list

Andrew Svetlov added the comment: Remi is correct. Closing the issue. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41242] When concating strings, I think it is better to use += than join the list

Change by Andrew Svetlov : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33840] connection limit on listening socket in asyncio

Change by Karthikeyan Singaravelan : -- Removed message: https://bugs.python.org/msg373314 ___ Python tracker ___ ___

[issue41243] SPAM

Change by Steven D'Aprano : -- resolution: -> not a bug stage: -> resolved status: open -> closed title: Android Game -> SPAM type: security -> ___ Python tracker ___

[issue33840] connection limit on listening socket in asyncio

Change by Karthikeyan Singaravelan : -- Removed message: https://bugs.python.org/msg373313 ___ Python tracker ___ ___

[issue41243] Android Game

New submission from Deon : Download FIFA 14 apk https://apkgreat.com/fifa-14-apk/ -- components: Interpreter Core messages: 373315 nosy: Deon257 priority: normal severity: normal status: open title: Android Game type: security versions: Python 3.7

[issue33840] connection limit on listening socket in asyncio

Deon added the comment: Download FIFA 14 apk https://apkgreat.com/fifa-14-apk/ -- ___ Python tracker ___ ___ Python-bugs-list

[issue33840] connection limit on listening socket in asyncio

Deon added the comment: hi -- nosy: +Deon257 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41242] When concating strings, I think it is better to use += than join the list

Rémi Lapeyre added the comment: Hi Wansoo, using += instead of str.join() is less performant. Concatenating n strings with + will create and allocate n new strings will str.join() will carefully look ahead and allocate the correct amount of memory and do all concatenation at one: ➜ ~

[issue22239] asyncio: nested event loop

mike bayer added the comment: I tested "cancellation", shutting down the DB connection mid query. Because the greenlet is only in the middle and not at the endpoints, it propagates the exception and there does not seem to be anything different except for the greenlet sequence in the

[issue41242] When concating strings, I think it is better to use += than join the list

Change by Wansoo Kim : -- keywords: +patch pull_requests: +20545 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21397 ___ Python tracker ___

[issue41242] When concating strings, I think it is better to use += than join the list

New submission from Wansoo Kim : Hello I think it's better to use += than list.join() when concating strings. This is more intuitive than other methods. Also, I personally think it is not good for one variable to change to another type during runtime.

[issue41241] Unnecessary Type casting in 'if condition'

Change by Wansoo Kim : -- keywords: +patch pull_requests: +20544 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21396 ___ Python tracker ___

[issue41241] Unnecessary Type casting in 'if condition'

New submission from Wansoo Kim : Hello! When using 'if syntax', casting condition to bool type is unnecessary. Rather, it only occurs overhead. https://github.com/python/cpython/blob/b26a0db8ea2de3a8a8e4b40e69fc8642c7d7cb68/Lib/asyncio/futures.py#L118 If you look at the link above, the

[issue41073] [C API] PyType_GetSlot() should accept static types

Change by hai shi : -- keywords: +patch pull_requests: +20543 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21395 ___ Python tracker ___

[issue41239] SSL Certificate verify failed in Python3.6/3.7

Christian Heimes added the comment: I'm afraid I have to close this issue as OUT-OF-DATE. It's either a bug in pywbem or a 3.6-only bug. Python 3.6 is in security maintenance mode and no longer receive bug fixes. I suggest that you take this issue to pywbem bug tracker and get assistance

[issue16396] Importing ctypes.wintypes on Linux gives a ValueError instead of an ImportError

Change by Jason R. Coombs : -- pull_requests: +20542 pull_request: https://github.com/python/cpython/pull/21394 ___ Python tracker ___

[issue22239] asyncio: nested event loop

mike bayer added the comment: as far as cancellation, I gather you're referring to what in gevent / greenlet is the GreenletExit exception. Sure, that thing is a PITA. Hence we're all working to provide asyncio frontends and networking backends so that the effects of cancellation I

  1   2   >