[issue24431] StreamWriter.drain is not callable concurrently

Guido van Rossum added the comment: Note that Glyph recommends against this fix (see mailing list). On Thu, Jun 11, 2015 at 7:59 AM, Martin Teichmann wrote: > > New submission from Martin Teichmann: > > Currently there is an assert statement asserting that no two > tasks (asyn

[issue24431] StreamWriter.drain is not callable concurrently

Guido van Rossum added the comment: See mailing list discussion. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue24449] Please add async write method to asyncio.StreamWriter

Guido van Rossum added the comment: Paul, you have brought this up many times before, and you have been refuted each time. Reading and writing just aren't symmetric operations. If you need awrite(), it's a two-line helper function you can easily write yourself. --

[issue24449] Please add async write method to asyncio.StreamWriter

Guido van Rossum added the comment: Most people actually are better off with just write(), and an API with more choices is not necessarily better. I'm sure this has come up before, I could've sworn it was you, sorry if it wasn't. Here's one reason why I don't like yo

[issue24451] Add metrics to future objects (concurrent or asyncio?)

Guido van Rossum added the comment: I'm not sure about concurrent.futures, but for asyncio I think this would cost too much overhead. -- ___ Python tracker <http://bugs.python.org/is

[issue24449] Please add async write method to asyncio.StreamWriter

Guido van Rossum added the comment: Good pontificating, Paul. -- ___ Python tracker <http://bugs.python.org/issue24449> ___ ___ Python-bugs-list mailing list Unsub

[issue24469] Py2.x int free list can grow without bounds

Guido van Rossum added the comment: 1) The intended solution is to require that int subclasses override tp_free. 2) I don't see any constructors that don't call PyInt_FromLong() -- what am I missing? -- ___ Python tracker <http://bu

[issue24469] Py2.x int free list can grow without bounds

Guido van Rossum added the comment: (1) Just look at the examples of other builtin types with a similar structure but no free_list. (2) I guess the intention is for classes that subclass int to also override tp_alloc. Note that much of this code is written pretty much assuming that

[issue24523] coroutine asyncio.wait() does not preserve order of elements

Guido van Rossum added the comment: The docs say that it returns two *sets* and Python's set datatype is unordered. So that's all you need to know. I don't think there's anything else needed in the docs. -- resolution: -> not a bug

[issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open

New submission from Guido van Rossum: See https://github.com/python/asyncio/issues/251. I'm on vacation and may or may not find the time to actually fix this (it needs a unittest written). -- components: asyncio messages: 245986 nosy: gvanrossum, haypo, yselivanov priority: n

[issue24571] [RFE] Add asyncio.call_async API

Guido van Rossum added the comment: You seem to miss that run_in_executor() does take *args -- so the partial() call is only needed if you need to pass keyword args. Is it really worth having a helper for this one-liner? def call_async(func, *args): return asyncio.get_event_loop

[issue24578] [RFE] Add asyncio.wait_for_result API

Guido van Rossum added the comment: Maybe the two issues should be merged so the two proposals can be considered together. I'm -0 on both, because each of these is really just one line of code and it seems they both encourage mindless copy-pasting that just saddens me (similar to &q

[issue24571] [RFE] Add asyncio.call_async API

Guido van Rossum added the comment: *If* it needs to be added I like call_in_thread(). (We should have used that instead of call_in_executor() on the loop, but too late now.) -- ___ Python tracker <http://bugs.python.org/issue24

[issue24571] [RFE] Add asyncio.call_async API

Guido van Rossum added the comment: But that example also shows what's wrong with the idea. I presume load_remote_data_set1 and load_remote_data_set2 are themselves just using synchronous I/O, and the parallelization is done using threads. So why not use concurrent.futures? Why bother

[issue24571] [RFE] Add asyncio.background_call API

Guido van Rossum added the comment: > 1. You have to manage the lifecycle of the executor yourself, rather than > letting asyncio do it for you > 2. There's no easy process wide way to modify the size of the background task > thread pool (or switch to using processes instea

[issue24571] [RFE] Add asyncio.background_call API

Guido van Rossum added the comment: Yeah, we should strongly consider writing more documentation before adding more convenience APIs. Esp. tutorial-style docs, which neither Victor nor I can supply because we've already moved beyond wizard level ourselves so it's hard for us to i

[issue24598] asyncio: add background task detecting reference cycles

Guido van Rossum added the comment: Doesn't the cycle-detecting GC handle these? -- ___ Python tracker <http://bugs.python.org/issue24598> ___ ___ Pytho

[issue24598] asyncio: add background task detecting reference cycles

Guido van Rossum added the comment: Hm. If the problem is most prominent with 3.3, why mark the issue as 3.6? Do you have an implementation already? Maybe it can be a 3rd party package rather than integrated in asyncio debug mode? -- ___ Python

[issue24598] asyncio: add background task detecting reference cycles

Guido van Rossum added the comment: OK, no problem. (Side comment: Future is being subclassed a lot, so parametrizing its construction may not be so easy.) -- ___ Python tracker <http://bugs.python.org/issue24

[issue24571] [RFE] Add asyncio.background_call API

Guido van Rossum added the comment: Please move the philosophical discussion to python-ideas. Regarding the phrasing about the two Future classes being almost compatible, that is unfortunate wording. Two things can have a similar API (merely having the same methods etc.) without being

[issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open

Guido van Rossum added the comment: I've added the return True from eof_received() to the asyncio repo (https://github.com/python/asyncio/commit/ce3ad816a2ef9456b4b1c26b99dfc85ea1236811), but it still needs a unittest and merging into CPython 3.4 a

[issue24635] test_typing is flaky

Guido van Rossum added the comment: You can list me as the expert for typing.py, since I wrote it. :-) (However, until mid August I have limited availability since I'm on vacation.) This looks indeed like a test order dependency. The three failures are all basic failures where an empt

[issue24619] async/await parser issues

Guido van Rossum added the comment: Haven't reviewed the patch, but this approach sounds great (in fact I had assumed you were doing this already, and I was a bit surprised by some of the problems you encountered :-). -- ___ Python tracker

[issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines

Guido van Rossum added the comment: What problem does this solve? -- ___ Python tracker <http://bugs.python.org/issue24697> ___ ___ Python-bugs-list mailin

[issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines

Guido van Rossum added the comment: What problem does this solve? -- ___ Python tracker <http://bugs.python.org/issue24697> ___ ___ Python-bugs-list mailin

[issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines

Guido van Rossum added the comment: Hm, I think there's little need for new exceptions... -- ___ Python tracker <http://bugs.python.org/issue24697> ___ ___

[issue15138] base64.urlsafe_b64**code are too slow

Guido van Rossum added the comment: I'm going to apply the 2.7 patch, except I'm going to leave the (now unused) _translate() function in place, in case it's used anywhere (minimizing the risk of breaking anything). -- ___ Python

[issue15138] base64.urlsafe_b64**code are too slow

Guido van Rossum added the comment: And just in case someone objects to my breaking the policy stated by Antoine in msg163432: see http://bugs.python.org/issue4753 -- it's not actually a real policy. -- versions: +Python 2.7 ___ Python tr

[issue23973] PEP 484 implementation

Guido van Rossum added the comment: I'm bumping this up since the CPython repo is several changes behind the typehinting repo (https://github.com/ambv/typehinting/tree/master/prototyping). Those should not miss RC1. -- priority: normal -> release

[issue24272] PEP 484 docs

Guido van Rossum added the comment: This should probably be committed before RC1 -- it's better than nothing! -- priority: normal -> release blocker ___ Python tracker <http://bugs.python.org

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

Guido van Rossum added the comment: [Repeat from the review] I still don't think this should be done for 3.5.0, it's definitely a feature, and there are no more betas planned (rc1 is next weekend). We may be able to do this for 3.5.1 (since PEP 492 was accepted provisionally,

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

Guido van Rossum added the comment: Please try to make sure this is fixed before 3.5 rc 1. -- ___ Python tracker <http://bugs.python.org/issue23996> ___ ___ Pytho

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

Guido van Rossum added the comment: Every individual use case can be dealt with easily by adding simple helper functions. I really want to keep async and threads separate. And it's no coincidence that concurrent.futures is threadsafe; that's part o

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

Guido van Rossum added the comment: Sorry, there's no space in this issue for an answer. -- ___ Python tracker <http://bugs.python.org/issue24383> ___ ___

[issue24272] PEP 484 docs

Guido van Rossum added the comment: Thank you Ivan! I am going to commit this, it's much better than the two lines we had before. :-) There's still a lot of work left to do -- towards the end there are many classes without description. Maybe you and Daniel can divide up the work for

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Yes we should. I'd consider it a bug if it wasn't supported in 3.5.0 and we could fix that bug in 3.5.1. -- ___ Python tracker <http://bugs.python.

[issue24272] PEP 484 docs

Guido van Rossum added the comment: I've landed this now (for real). Next time please strip all trailing whitespace from typing.rst, else the hg push fails! -- ___ Python tracker <http://bugs.python.org/is

[issue24795] Make event loops with statement context managers

Guido van Rossum added the comment: This seems the wrong idea to me. Event loops should be long-lived, so the context manager would ideally see very little use. -- ___ Python tracker <http://bugs.python.org/issue24

[issue23749] asyncio missing wrap_socket (starttls)

Guido van Rossum added the comment: Why does the start_tls() function need to know the internal structure of the Transport? I'm hesitant to add this API to Transport; it somehow feels wrong to put such an implementation-specific thing there. E.g. I presume you can't do this

[issue23749] asyncio missing wrap_socket (starttls)

Guido van Rossum added the comment: OK, got it. SGTM. -- ___ Python tracker <http://bugs.python.org/issue23749> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24795] Make event loops with statement context managers

Guido van Rossum added the comment: My worry is that the context manager will make people believe it's a good pattern to create an event loop just to make one call. If tests violate this pattern, add a context manager helper function to test_utils.py. On Thu, Aug 6, 2015 at 2:57 AM, M

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

Guido van Rossum added the comment: Honestly, I've lost track of the queue design. Maybe the push-back on cancellation is just wrong? After all, if a coroutine has received an item, it's out of the queue, even if it gets cancelled before it can do anything with the item. On Thu, Aug

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

Guido van Rossum added the comment: Honestly, I've lost track of the queue design. Maybe the push-back on cancellation is just wrong? After all, if a coroutine has received an item, it's out of the queue, even if it gets cancelled before it can do anything with

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

Guido van Rossum added the comment: So this looks like it will miss 3.5.0rc1. How confident are we that the new patch won't introduce new bugs? This late in the release process that would be awkward. On Fri, Aug 7, 2015 at 12:47 AM, Gustavo J. A. M. Carneiro < rep...@bugs.python.or

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

Guido van Rossum added the comment: You could also withdraw. The more I think about it the more I dislike it. I just don't think we should do *anything* that encourages confusion between threads and tasks. They are fundamentally different concepts and should remai

[issue24272] PEP 484 docs

Guido van Rossum added the comment: Yeah, there's another diff but I didn't get to it. -- ___ Python tracker <http://bugs.python.org/issue24272> ___ ___

[issue23973] PEP 484 implementation

Guido van Rossum added the comment: There's more, but you can reduce the priority now. -- ___ Python tracker <http://bugs.python.org/issue23973> ___ ___ Pytho

[issue24835] Consistent failure in test_asyncio on Windows 7 buildbot

Guido van Rossum added the comment: Probably Vincent knows? FWIW the actual failure from the log file is: FAIL: test_popen_error (test.test_asyncio.test_subprocess.SubprocessProactorTests) -- Traceback (most recent call last

[issue24835] Consistent failure in test_asyncio on Windows 7 buildbot

Guido van Rossum added the comment: Actually, this seems to be Yuri's mistake -- in rev 99550a01fa6e (in the 3.4 case, I suppose it's been merged into 3.5 and 3.6) he (accidentally, I assume) reverted Victor's (not Vincent's -- sorry!) fix from issue #24763. But apparentl

[issue24837] await process.wait() does not work with a new_event_loop

Guido van Rossum added the comment: I think it's unfortunate that this doesn't work. Note that the example program has no threads -- it just has a loop that isn't the default loop. The docs you refer to aren't very helpful. -- __

[issue9232] Allow trailing comma in any function argument list.

Guido van Rossum added the comment: I'm +1 on adding this. I don't believe it requires a PEP. A trailing comma in definitions is already supported in some places, so I don't buy the argument that it catches errors. During the moratorium we were perhaps too strict. -- no

[issue9232] Allow trailing comma in any function argument list.

Guido van Rossum added the comment: To be explicit, yes, I want to allow trailing comma even after *args or **kwds. And that's what the patch does. -- ___ Python tracker <http://bugs.python.org/i

[issue24893] Tk occasionally mispositions Text() insert cursor on mouse click.

Guido van Rossum added the comment: I don't have that laptop any more. It's likely that the screen resolution change caused Tcl/Tk to be confused. That's probably a Tcl/Tk bug. -- ___ Python tracker <http://bugs.pyt

[issue24893] Tk occasionally mispositions Text() insert cursor on mouse click.

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue24893> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22241] strftime/strptime round trip fails even for UTC datetime object

Guido van Rossum added the comment: OK, I guess we can change stdlib datetime.timezone.utc's str() to 'UTC'. Make sure to update both the C and the Python version, and the tests, and the docs. It's going to have to go into 3.6.

[issue23630] support multiple hosts in create_server/start_server

Guido van Rossum added the comment: Yeah, I think this is fine. I think the use case for multiple hosts is very different than that for multiple ports, so I see no reason to link the two features, and multiple ports hasn't been requested. The patch has a long line and the new docstring

[issue23630] support multiple hosts in create_server/start_server

Guido van Rossum added the comment: Also, I guess you'll need a branch that tracks what's going into 3.6. -- ___ Python tracker <http://bugs.python.o

[issue23630] support multiple hosts in create_server/start_server

Guido van Rossum added the comment: It can't go into 3.5.1 (a bugfix release) because it is a new feature (however small), and asyncio is not provisional in 3.5 (only in 3.4). -- ___ Python tracker <http://bugs.python.org/is

[issue23630] support multiple hosts in create_server/start_server

Guido van Rossum added the comment: The traditional solution is to rewrite the sentence so the name is not the first word. :-) -- ___ Python tracker <http://bugs.python.org/issue23

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

New submission from Guido van Rossum: The datetime isoformat() function for an aware datetime appends the timezone in the form +HH:MM or -HH:MM. But the %z format produces (strftime) or parses (strptime) either +HHMM or -HHMM. I looked it up on Wikipedia, and the ISO 8601 standard indeed uses

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: I don't want to own this, but this is absolutely a release blocker. I see three ways out: - Fix it right (if possible) -- "system immutable" types such as int should not allow __class__ assignment. Risk: there might be other cases (the code

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: If we don't reach an agreement we should fall back to Serhiy's (1) only. Eugene: Without more motivation that sounds like very questionable functionality to want to add to modules. I don't have time to read the discussion that led up to th

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: I don't think I told you to do it this way -- that message of mind sounded pretty noncommittal in all directions. I do understand your predicament. Can you live with just a special case for modules? __class__ assignment is full of non-portable special

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: PS. I have very little time this week or next to review everything -- if we don't find a reasonable compromise it *will* be rolled back. -- ___ Python tracker <http://bugs.python.org/is

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: OK, then I think it's between you and Serhiy. -- ___ Python tracker <http://bugs.python.org/issue24912> ___ ___ Pytho

[issue23630] support multiple hosts in create_server/start_server

Guido van Rossum added the comment: Let's not extend the API with support for multiple ports. Nobody has asked for it, and clearly the API design is not so simple. -- ___ Python tracker <http://bugs.python.org/is

[issue24995] better exception message when an unsupported object is passed to `async for` (pep 492)

Guido van Rossum added the comment: Did you get multiple complaints about this? The existing error doesn't seem so bad. -- ___ Python tracker <http://bugs.python.org/is

[issue24635] test_typing is flaky

Guido van Rossum added the comment: Sorry, this is a bug in typing.py. https://github.com/ambv/typehinting/issues/155 It's a subtle bug but the first reporter has done some good research; I will try to find time to fix it today. -- ___ P

[issue24635] test_typing is flaky

Guido van Rossum added the comment: Fixed now on the 3.5 branch. I still have to merge to default and create the pull request for Larry. -- assignee: -> gvanrossum resolution: -> fixed ___ Python tracker <http://bugs.python.org/i

[issue24635] test_typing is flaky

Guido van Rossum added the comment: Pull request for Larry: https://bitbucket.org/larry/cpython350/pull-requests/14/fix-issue-24635/diff -- ___ Python tracker <http://bugs.python.org/issue24

[issue24635] test_typing is flaky

Guido van Rossum added the comment: BTW, I screwed up and committed this into the public 3.5 repo first (and merged from there into default). I guess once Larry has merged the fix into his special closed 3.5 bitbucket repo I should do a null merge from there back to public 3.5 and forward the

[issue24635] test_typing is flaky

Guido van Rossum added the comment: Assigning to Larry since the next step is his. -- assignee: gvanrossum -> larry priority: high -> release blocker ___ Python tracker <http://bugs.python.org/i

[issue24635] test_typing is flaky

Guido van Rossum added the comment: OK, done. -- ___ Python tracker <http://bugs.python.org/issue24635> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25002] Deprecate asyncore/asynchat

New submission from Guido van Rossum: Now that we've got asyncio in two releases (3.4 and 3.5) we should start deprecating asyncore and asynchat. There isn't much use of these in the stdlib (smtpd.py uses them, and a bunch of tests) and we should probably rewrite those to use asyn

[issue25002] Deprecate asyncore/asynchat

Changes by Guido van Rossum : -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue25002> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25002] Deprecate asyncore/asynchat

Guido van Rossum added the comment: Yes, in 3.6 asyncio will no longer be provisional and we can start deprecating async{ore,hat}. Which is why I marked this bug with 3.6. -- ___ Python tracker <http://bugs.python.org/issue25

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: We should have something for rc3, which is imminent. I vote for (1) and (2) if Serhiy thinks the patch is ready. -- ___ Python tracker <http://bugs.python.org/issue24

[issue25002] Deprecate asyncore/asynchat

Guido van Rossum added the comment: Ideally these modules should emit a deprecation warning starting in 3.6 (when asyncio is no longer provisional) and we should strive to delete them per 3.8. If nobody rewrites smptd.py using asyncio it should be deleted at the same time

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: Serhiy, can you commit it and prepare a PR for Larry? -- ___ Python tracker <http://bugs.python.org/issue24912> ___ ___ Pytho

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: I'm creating the PR for Larry. -- ___ Python tracker <http://bugs.python.org/issue24912> ___ ___ Python-bugs-list m

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: PR: https://bitbucket.org/larry/cpython350/pull-requests/15/issue-24912-prevent-__class__-assignment/diff -- assignee: -> larry resolution: -> fixed ___ Python tracker <http://bugs.python.org/i

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: Oh. I feel dumb now. I guess I'll let Larry choose. If it's just a matter of comment text we can always improve it in 3.5.1. -- ___ Python tracker <http://bugs.python.o

[issue24912] The type of cached objects is mutable

Guido van Rossum added the comment: Mark, please calm down. Modules are incredibly simple objects compared to classes -- and yet you can change the __class__ of a class. You can also directly modify the __dict__ of a module. You can shoot yourself in the foot phenomenally this way, but that&#

[issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state

Guido van Rossum added the comment: (It could be fixed in 3.5.1, since asyncio is still provisional in 3.5.) -- ___ Python tracker <http://bugs.python.org/issue22

[issue24272] PEP 484 docs

Guido van Rossum added the comment: I apologize, I've been distracted. I will try to get to this before 3.5.0 final goes out! I don't know if the fixes will end up in the tar ball but they will certainly be on docs.python.org. -- ___ Pyth

[issue25003] os.urandom() should call getrandom(2) not getentropy(2)

Guido van Rossum added the comment: I got several long private emails from Theo De Raadt about this issue. I think the gist of it all is that most likely (a) the app most likely shouldn't be calling os.urandom() that often, and (b) Solaris getentropy() is apparently stunningly slow. Theo

[issue25002] Deprecate asyncore/asynchat

Guido van Rossum added the comment: Then can we at least close any feature requests for asyncore/asynchat as wontfix? (And porting smtpd.py to asyncio is still a good idea.) -- ___ Python tracker <http://bugs.python.org/issue25

[issue25003] os.urandom() should call getrandom(2) not getentropy(2)

Guido van Rossum added the comment: Also, Theo believes that our Mersenne Twister is outdated and os.urandom() is the only reasonable alternative. So we might as well keep it fast. -- ___ Python tracker <http://bugs.python.org/issue25

[issue25002] Deprecate asyncore/asynchat

Guido van Rossum added the comment: > Is it ok to add the PendingDeprecationWarning in Python 3.5.1? I prefer to wait until 3.6. A bugfix release should not rock the boat, it should not make your code emit new warnings. -- ___ Python trac

[issue25003] os.urandom() should call getrandom(2) not getentropy(2)

Guido van Rossum added the comment: To Theo it's probably inconceivable that anyone would be using random numbers for anything besides crypto security. :-) His favorite is arc4random() (but he notes it's not based on RC4 anymore, but uses chacha -- I have no idea what any of

[issue25003] os.urandom() should call getrandom(2) not getentropy(2)

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24912] The type of cached objects is mutable

Changes by Guido van Rossum : -- nosy: -Guido.van.Rossum ___ Python tracker <http://bugs.python.org/issue24912> ___ ___ Python-bugs-list mailing list Unsub

[issue24272] PEP 484 docs

Guido van Rossum added the comment: Pull Request: https://bitbucket.org/larry/cpython350/pull-requests/24/docs-update-for-typing-module/diff -- ___ Python tracker <http://bugs.python.org/issue24

[issue24272] PEP 484 docs

Guido van Rossum added the comment: I apologize for the mix-up! The code review tool didn't help. Regarding the single quotes, there seem to be a bunch more of these, and as cutting a PR is a fair bit of labor I'd rather not fix that. We can fix this once 3.5.0 it out of the door

[issue24272] PEP 484 docs

Guido van Rossum added the comment: Merged and pushed. Let's please use a new issue for any further patches. -- status: open -> closed ___ Python tracker <http://bugs.python.org

[issue24272] PEP 484 docs

Guido van Rossum added the comment: I suck at merge. :-( No idea what happened. To fix it, I have now just copied the file again from the larry branch and committed that in 3.5, then merged up to 3.6 (default). changeset: 97856:8a7814a3613b branch: 3.5 parent: 97847:6c8e2c6e3a99

[issue25062] Doc linter error: [2] library/typing.rst:358: default role used

Guido van Rossum added the comment: That link gives me a timeout right now. How can I run the doc linter manually? "make html" in the Doc tree didn't alert me to this issue. -- ___ Python tracker <http://bugs.pyt

[issue25062] Doc linter error: [2] library/typing.rst:358: default role used

Guido van Rossum added the comment: Maybe Zach knows how to fix this since he fixed it for an earlier version? (Sorry Zach!) -- nosy: +zach.ware ___ Python tracker <http://bugs.python.org/issue25

[issue25062] Doc linter error: [2] library/typing.rst:358: default role used

Guido van Rossum added the comment: Thanks everyone! This episode shows I should not try to commit CPython stuff. Period. -- ___ Python tracker <http://bugs.python.org/issue25

[issue25073] Document asyncio.test_utils

Guido van Rossum added the comment: Agreed, but then why isn't it in the tests directory? There are some examples in the asyncio repo on GitHub that use test_utils.dummy_ssl_context(), and that's probably why; but that's a fairly bad practice plus it's

<    45   46   47   48   49   50   51   52   53   54   >