[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: Nick, Martin, here's an updated patch with all your comments addressed. -- Added file: http://bugs.python.org/file39751/corotype.patch ___ Python tracker <http://bugs.python.org/is

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Changes by Yury Selivanov : -- dependencies: +Awaitable ABC incompatible with functools.singledispatch ___ Python tracker <http://bugs.python.org/issue24

[issue24468] Expose C level compiler flag constants to Python code

Yury Selivanov added the comment: Larry, Nick, Attached patch exposes CO* constants in the '_opcode' module. There is one slight complication though: importing '_opcode' in 'types' (required for issue24400) breaks Python compilation, as 'types' module i

[issue24325] Speedup types.coroutine()

Yury Selivanov added the comment: Larry, Nick, Looking at how issue24400 progresses, I think it would be really great if we can merge this one in 3.5.0. It also makes it unnecessary to merge issue24468 in 3.5. -- dependencies: +Awaitable ABC incompatible with

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: An updated patch is attached. I'll commit it tomorrow morning. -- Added file: http://bugs.python.org/file39764/corotype.patch ___ Python tracker <http://bugs.python.org/is

[issue24439] Feedback for awaitable coroutine documentation

Yury Selivanov added the comment: Martin, if you want to help with the documentation, it would be great if you can help me with updating asyncio coroutines section: https://docs.python.org/3.5/library/asyncio-task.html#coroutines -- ___ Python

[issue24487] Change asyncio.async() → ensure_future()

Yury Selivanov added the comment: Martin, I believe this was done as part of issue24180, see this commit https://hg.python.org/cpython/rev/9d9e445d25dc -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.p

[issue24485] Function source inspection fails on closures

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue24485> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24485] Function source inspection fails on closures

Yury Selivanov added the comment: Looks like this is a regression in 3.5. -- priority: normal -> release blocker stage: -> needs patch ___ Python tracker <http://bugs.python.org/i

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: Nick, Martin, Stefan, thanks to all of you for the code review! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24439] Feedback for awaitable coroutine documentation

Yury Selivanov added the comment: Hi Martin, I've left you some feedback in the code review. > * “async def” routines are allowed in addition to generators in asyncio (e.g. > in Task constructor) Right. I think we need to add some code samples too. > * Other awaitables are al

[issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot

Yury Selivanov added the comment: Hi Zachary, This is extremely strange. The test doesn't even start the loop, it only creates it, and prints out what 'get_debug' says. It can't be 'sys.set_coroutine_wrapper' either, as it's only called when a loop is r

[issue24325] Speedup types.coroutine()

Yury Selivanov added the comment: A rebased version of the patch is attached (now a "review" link should appear). Nick, Stefan, please take a look. Larry, can we merge this in 3.5.0? I've invested a lot of time to have 100% test coverage; the test suite is very elaborate now.

[issue24325] Speedup types.coroutine()

Changes by Yury Selivanov : -- nosy: +asvetlov, haypo, vadmium ___ Python tracker <http://bugs.python.org/issue24325> ___ ___ Python-bugs-list mailing list Unsub

[issue24450] Add gi_yieldfrom calculated property to generator object

Yury Selivanov added the comment: Please find attached a new patch that exposes 'cr_await' attribute on coroutine objects. I don't think we can merge 'gi_yieldfrom' in 3.5, but 'cr_await' should probably be fine. -- Added file: http://bugs.

[issue24450] Add cr_await calculated property to coroutine object

Changes by Yury Selivanov : -- title: Add gi_yieldfrom calculated property to generator object -> Add cr_await calculated property to coroutine object ___ Python tracker <http://bugs.python.org/issu

[issue24495] asyncio.ensure_future() AttributeError with “async def” coroutines

Yury Selivanov added the comment: Should be fixed now. Thanks for discovering this, Martin! Victor, I'll make a PR on github/asyncio with some refactoring or CoroWrapper etc. The code became too cumbersome, and has to be properly refactored. At least we should have one wrapper clas

[issue24439] Feedback for awaitable coroutine documentation

Yury Selivanov added the comment: Committed. Thanks a lot, Martin! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache()

Yury Selivanov added the comment: > I would prefer do not repeat the code, but I afraid this can affect the > performance, and the performance of PyDict_GetItem is critical for Python. Static function calls like that one will most likely be inlined by the compiler... But if you don

[issue24325] Speedup types.coroutine()

Yury Selivanov added the comment: I've committed new unittests from this patch (as they are applicable to pure Python implementation of the wrapper too) The patch now contains only the C implementation of the wrapper and should be ready to be committed. Larry? -- Added file:

[issue24450] Add cr_await calculated property to coroutine object

Yury Selivanov added the comment: Larry, what's your opinion on this? cr_await is a new thing (trivial on the C level) on a new type, it shouldn't break anything. gi_yieldfrom is identical to cr_await. Can we add this to 3.5? --

[issue24510] Make _PyCoro_GetAwaitableIter a public API

New submission from Yury Selivanov: We should consider making _PyCoro_GetAwaitableIter(o) a public API. Its implementation isn't trivial because it's not around simply accessing 'tp_as_async->am_await'. You also need to check is 'o' is a generator with a CO_I

[issue24511] Add methods for async protocols

New submission from Yury Selivanov: Let's consider adding C API functions for working with new tp_as_async: PyAwait_Check for checking tp_as_async->am_await || PyCoro_Check || PyGen & CO_ITERABLE_COROUTINE PyAwait_AsyncIterCheck for checking tp_as_async->am_iter PyAwait_G

[issue24511] Add methods for async protocols

Changes by Yury Selivanov : -- type: -> enhancement ___ Python tracker <http://bugs.python.org/issue24511> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24439] Feedback for awaitable coroutine documentation

Yury Selivanov added the comment: Martin, it's now updated. (As for why it wasn't applied in the first place, I guess standard MacOS `patch` command fails to apply git binary diffs) -- ___ Python tracker <http://bugs.python.o

[issue24510] Make _PyCoro_GetAwaitableIter a public API

Yury Selivanov added the comment: > It looks like the code is currently moving fast. [..] Yeah, that's my feeling too, I don't want to rush things too much. Unless Guido, Nick and you are in complete agreement that we need this, we should post

[issue24509] Undocumented features of asyncio: call_at, call_later

Yury Selivanov added the comment: Thanks for reporting this Mark! -- resolution: -> fixed stage: -> commit review status: open -> closed versions: +Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.or

[issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator

Yury Selivanov added the comment: Here's an update on #24485 regression. Looks like getsource() is now using code objects instead of tokenizer to determine blocks first/last lines. The problem with this particular case is that "inner" function's code object is complet

[issue24485] Function source inspection fails on closures

Yury Selivanov added the comment: Thanks, Terry. I posted some findings to #21217. -- nosy: +ncoghlan, pitrou ___ Python tracker <http://bugs.python.org/issue24

[issue22609] Constructors of some mapping classes don't accept `self` keyword argument

Yury Selivanov added the comment: Left some feedback in the code review. -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue22609> ___ ___ Pytho

[issue24336] Allow arbitrary keywords to @contextmanager functions

Yury Selivanov added the comment: lgtm.. Serhiy, I think you should just commit it. -- ___ Python tracker <http://bugs.python.org/issue24336> ___ ___ Python-bug

[issue24528] Misleading exeption for await in comprehensions.

Changes by Yury Selivanov : -- assignee: -> yselivanov ___ Python tracker <http://bugs.python.org/issue24528> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24528] Misleading exeption for await in comprehensions.

Yury Selivanov added the comment: Thanks for discovering this, Ivan. The patch is attached. -- keywords: +needs review, patch nosy: +ncoghlan stage: -> patch review Added file: http://bugs.python.org/file39834/awaitcomp.patch ___ Python trac

[issue24532] asyncio.sock_recv() blocks normal ioloop actions.

Yury Selivanov added the comment: > You should develop using asyncio debug mode: Maybe we should promote this check to the production mode? -- ___ Python tracker <http://bugs.python.org/issu

[issue24528] Misleading exeption for await in comprehensions.

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: > > isawaitable(), however, should continue using abc.Awaitable, since it only > > checks for __await__ presence on the type (or should we just drop it?) > I'd really remove it. It's not referring to an actual type, so it doesn&#x

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: > Look like you forgot to adjust test_inspect for the removal. eg: My bad. Thanks, David! -- ___ Python tracker <http://bugs.python.org/issu

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Yury Selivanov added the comment: +1 for readfd/writefd. I think 'fd' suffix is necessary to make it explicit that those aren't file objects. -- nosy: +yselivanov ___ Python tracker <http://bugs.pyt

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Yury Selivanov added the comment: This has already been fix (see issue24400). I've also updated the comment (16 -> 18). Let's keep the test as is. -- nosy: +yselivanov resolution: -> fixed stage: -> resolved status: open -> closed

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Yury Selivanov added the comment: Thanks for pushing this Martin. I didn't notice that you suggested to update inspect.rst as well. And it does make sense to just remove the number of is* functions from the docs (and after that we don't need th

[issue24487] Change asyncio.async() → ensure_future()

Yury Selivanov added the comment: Thanks, Martin! -- resolution: out of date -> fixed ___ Python tracker <http://bugs.python.org/issue24487> ___ ___ Python-

[issue24487] Change asyncio.async() → ensure_future()

Changes by Yury Selivanov : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue24487> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Yury Selivanov added the comment: Here's a patch, please review. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39839/ospipe.patch ___ Python tracker <http://bugs.python.org

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Changes by Yury Selivanov : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue24400> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: Thanks, Martin, it was indeed something that shouldn't been committed. -- ___ Python tracker <http://bugs.python.org/is

[issue24325] Speedup types.coroutine()

Yury Selivanov added the comment: > Oh, wait, I was confusing myself. This is that new module you guys created > for type hints, and this is a new object with no installed base. (Right?) No, you were right in your previous comment... > Help me to understand here. You want to c

[issue24450] Add cr_await calculated property to coroutine object

Yury Selivanov added the comment: Benno, thanks for coming up with the idea and for the patches. Larry, thanks for approving this for 3.5! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +P

[issue19235] Add a dedicated subclass for recursion errors

Yury Selivanov added the comment: Thanks Larry and Georg! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 ___ Python tracker <http://bugs.python.or

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: Guido, Ben, Stefan, Nick, I want to re-open this issue. I'm still not satisfied with the current state of things, mainly with the __instancecheck__ hack for Awaitable & Coroutine ABCs (as Ben initially suggested). I think we should r

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: > If you want to cover the "iterable coroutine" case, why not add an inspect > helper function for that? That's clearly a concrete type (even more > concrete than a concrete type) that can be inspected. Because I view "iterab

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: > I think we should add "inspect.isawaitable()", and have it pass for > *anything* that can be used in an await expression (whether that's by > implementing the Awaitable protocol, or due to special casing at the > interpreter level

[issue24654] PEP 492 - example benchmark doesn't work (TypeError)

Yury Selivanov added the comment: Fixed in https://hg.python.org/peps/rev/7ad183c1d9be I'll quote the commit message here: pep-492: Update benchmark code Since coroutines now have a distinct type, they do not support iteration. Instead of doing 'list(o)', we now

[issue24619] async/await parser issues

Yury Selivanov added the comment: Sorry for not responding earlier, I'm on vacation and don't check email too often. While investigating what can be done in tokenizer.c to fix some of the bugs that Stefan pointed out, I discovered a simpler approach: instead of checking what kind o

[issue24619] async/await parser issues

Yury Selivanov added the comment: An updated patch is attached. I had to implement a little bit more sophisticated tracking of one-line functions to fix parsing of things like def foo(): async def f(): pass async def f(): pass async = 1 I hope that

[issue24485] Function source inspection fails on closures

Yury Selivanov added the comment: Meador, the patch looks OK. Could you please commit it yourself? -- assignee: -> meador.inge ___ Python tracker <http://bugs.python.org/issu

[issue24669] inspect.getsource() returns the wrong lines for coroutine functions

Yury Selivanov added the comment: Thanks, Kai! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 ___ Python tracker <http://bugs.python.or

[issue24619] async/await parser issues

Yury Selivanov added the comment: Thanks Nick! I've committed the patch with a few more unittests and a couple of additional comments in tokenizer.(c|h). -- resolution: -> fixed ___ Python tracker <http://bugs.python.org

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue24619> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- stage: patch review -> resolved ___ Python tracker <http://bugs.python.org/issue24619> ___ ___ Python-bugs-list mailing list Un

[issue24619] async/await parser issues

Yury Selivanov added the comment: > I'm just curious if the 'ctx' is still needed: It looks like > the outermost "async def" dominates all further nested scopes > w.r.t the tokenizer mode, no matter whether they're "def" or > "async

[issue24687] refleak on SyntaxError in function parameter annotation

New submission from Yury Selivanov: A simple way of reproducing the issue is to try to compile the following piece of code with refleaks check mode on: def foo(a:(yield)): pass Since '(yield)' expression is outside of a function, it will trigger a SyntaxError. There is a sub

[issue24688] Fix ast.get_docstring to support 'async def' functions

New submission from Yury Selivanov: Please see the attached patch. -- components: Library (Lib) files: compile.patch keywords: patch messages: 247154 nosy: benjamin.peterson, georg.brandl, yselivanov priority: high severity: normal stage: patch review status: open title: Fix

[issue24688] Fix ast.get_docstring to support 'async def' functions

Changes by Yury Selivanov : Added file: http://bugs.python.org/file39987/ast.patch ___ Python tracker <http://bugs.python.org/issue24688> ___ ___ Python-bugs-list mailin

[issue24688] Fix ast.get_docstring to support 'async def' functions

Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39986/compile.patch ___ Python tracker <http://bugs.python.org/issue24688> ___ ___ Python-bugs-list m

[issue24688] Fix ast.get_docstring to support 'async def' functions

Yury Selivanov added the comment: Thank you, Benjamin. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24687] refleak on SyntaxError in function parameter annotation

Yury Selivanov added the comment: > I would prefer that compiler_visit_argannotation[s] be fixed to use the > normal calling convention. Agree, new patch attached. -- Added file: http://bugs.python.org/file39990/compile2.patch ___ Python t

[issue24687] refleak on SyntaxError in function parameter annotation

Yury Selivanov added the comment: Thanks, Benjamin! -- ___ Python tracker <http://bugs.python.org/issue24687> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24687] refleak on SyntaxError in function parameter annotation

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- nosy: +benjamin.peterson ___ Python tracker <http://bugs.python.org/issue24619> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24619] async/await parser issues

Yury Selivanov added the comment: Updated patch attached (rebased; minor optimization). I'll commit this patch in a few hours to make sure it lands in 3.5beta4. -- Added file: http://bugs.python.org/file39991/issue24619.4.patch ___ Python tr

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> commit review ___ Python tracker <http://bugs.python.org/issue24619> ___ ___ Pyth

[issue24692] types.coroutines() idempotence documentation

Changes by Yury Selivanov : -- nosy: +vadmium ___ Python tracker <http://bugs.python.org/issue24692> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

Yury Selivanov added the comment: This is a documented behaviour, changing it would likely break too much code. Moreover, I don't think that calling addCleanup callbacks before tearDown makes more sense than after. tearDown is a common cleanup method for all tests of testcase, and addCl

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

Yury Selivanov added the comment: > But I guess that ship has sailed... Closing the issue. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python

[issue24485] Function source inspection fails on closures

Yury Selivanov added the comment: Meador, I've reverted changes introduced in #21217 -- I don't want to risk shipping 3.5beta4 with broken backwards compatibility. Feel free to rebase & commit your patch (I decorated test_decorator_with_lambda with @unittest.e

[issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines

New submission from Yury Selivanov: Since native coroutines (see PEP 492) hadn't had a separate type when the PEP was accepted, we didn't discuss that it might be necessary to introduce new exception types specifically for coroutines. To maintain backwards compatibility with 3.5,

[issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines

Yury Selivanov added the comment: > What problem does this solve? Only avoiding confusion, because coroutines now have a separate type, lack __iter__, and thus are quite different (on the surface) from generators. The fact that 'coro.send(..)' raises StopIteration (when coro

[issue24383] consider implementing __await__ on concurrent.futures.Future

Yury Selivanov added the comment: > Any counterarguments? There are no counterarguments. There is no obvious way to support concurrent.futures transparently, though: await conc_fut requires conc_fut to implement __await__. So we either have to implement __await__ for concurrent futu

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- stage: commit review -> resolved ___ Python tracker <http://bugs.python.org/issue24619> ___ ___ Python-bugs-list mailing list Un

[issue23441] rlcompleter: tab on empty prefix => insert spaces

Yury Selivanov added the comment: Berker, the patch looks good to me. Please commit. Larry, is it possible we can include this in 3.5.0? -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue23

[issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ???

Yury Selivanov added the comment: Thank you, Berker! -- ___ Python tracker <http://bugs.python.org/issue13248> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24768] Bytearray double free or corruption

Changes by Yury Selivanov : -- nosy: +benjamin.peterson, yselivanov ___ Python tracker <http://bugs.python.org/issue24768> ___ ___ Python-bugs-list mailin

[issue24383] consider implementing __await__ on concurrent.futures.Future

Yury Selivanov added the comment: > In short, I implemented support for concurrent.futures in the asyncio Task > class instead of making concurrent.futures aware of asyncio. The __await__ > implementation in concurrent.futures closely mirrors that of asyncio's Future. I like you

[issue24383] consider implementing __await__ on concurrent.futures.Future

Yury Selivanov added the comment: > There are other implementations of asyncio than the one in CPython. > Pulsar and Tornado define their own Task class. The greenio project I'm not sure if it's possible (or even makes any sense) to integrate tasks from other frameworks into a

[issue24383] consider implementing __await__ on concurrent.futures.Future

Yury Selivanov added the comment: > I agree with Stefan and Yury. As for the tests, Yury seemed to have those in > his patches -- I'll take a look and see if they're directly applicable. Good idea, the tests are in a fine shape. > For Python 3.5 and earlier, there is a wor

[issue24383] consider implementing __await__ on concurrent.futures.Future

Yury Selivanov added the comment: Alex, the updated patch is attached. Guido, do you like the new approach? Can I commit this in 3.6? -- Added file: http://bugs.python.org/file40103/concurrent.patch ___ Python tracker <http://bugs.python.

[issue24383] consider implementing __await__ on concurrent.futures.Future

Yury Selivanov added the comment: > We may be able to do this for 3.5.1 (since PEP 492 was accepted > provisionally, see > https://mail.python.org/pipermail/python-dev/2015-May/139844.html) although > it's still a pretty big new feature. I agree. I'm -1 on pushing thi

[issue24785] Document asyncio.futures.wrap_future()

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue24785> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24755] asyncio.wrap_future undocumented

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue24755> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

Yury Selivanov added the comment: > Any of the last two patches ("*_value") will fix it, with my preference on > the last one. Stefan, the last patch looks good to me. Do you think we can have a unittest for this? -- ___ Pytho

[issue24791] *args regression

Yury Selivanov added the comment: The attached patch should fix that. Please review. -- keywords: +patch Added file: http://bugs.python.org/file40128/issue24791.patch ___ Python tracker <http://bugs.python.org/issue24

[issue24791] *args regression

Changes by Yury Selivanov : -- nosy: +larry, ncoghlan ___ Python tracker <http://bugs.python.org/issue24791> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue2292] Missing *-unpacking generalizations

Yury Selivanov added the comment: Do we need to make lib2to3 compatible with the new grammar? -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue2

[issue24791] *args regression

Yury Selivanov added the comment: > Actually, I think `star_expr` will probably go away entirely. I'm not so concerned with supporting [*[] or []] stuff, but rather fixing the immediate regression in 3.5.0. I'd keep the patch size t

[issue23749] asyncio missing wrap_socket (starttls)

Yury Selivanov added the comment: I'm working on porting pypostgresql (pure python postgresql driver) library to use asyncio as its underlying IO machinery. And it appears that PQ3 protocol starts as clear text, and then upgrades to use TLS (if server or connection configured so). I&#x

[issue23749] asyncio missing wrap_socket (starttls)

Yury Selivanov added the comment: > Why does the start_tls() function need to know the internal structure of the > Transport? If start_tls() is added to the loop, it will (likely) have the following signature: loop.start_tls(transport) then I'd want it to check if the `trans

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Yury Selivanov added the comment: The fix is committed. Closing the issue. Thanks a lot, Gustavo! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24667] OrderedDict.popitem()/__str__() raises KeyError

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24791] *args regression

Changes by Yury Selivanov : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24810] UX mode for IDLE targeted to 'new learners'

Changes by Yury Selivanov : -- versions: -Python 3.5 ___ Python tracker <http://bugs.python.org/issue24810> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    19   20   21   22   23   24   25   26   27   28   >