Guido van Rossum added the comment:
The _ is a good idea. Please do fix up the examples!
--
___
Python tracker
<http://bugs.python.org/issue25073>
___
___
Pytho
Guido van Rossum added the comment:
Good question. Let's discuss this in the type hinting / pep 484 tracker:
https://github.com/ambv/typehinting/issues/156
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
The simplest fix for this IMO is to add a sock parameter to
create_datagram_endpoint(). I've filed an issue for this in the upstream
asyncio project: https://github.com/python/asyncio/issues/266
--
___
P
Guido van Rossum added the comment:
See https://github.com/python/asyncio/pull/267. Can you patch that in and see
if you can make it work?
--
___
Python tracker
<http://bugs.python.org/issue25
New submission from Guido van Rossum:
See https://github.com/python/asyncio/issues/265 and
https://github.com/python/asyncio/issues/268. This looks like an important
regression and we should fix it before 3.5.1 goes out.
The symptom is "AssertionError: queue non-empty, why are getters wa
Guido van Rossum added the comment:
I have a fix pending here: https://github.com/python/asyncio/pull/269
--
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
Agreed we shouldn't change this. It looks like the behavior is consistent if
you consider `a = StringIO(stuff, newline=...)` merely a shorthand for `a =
StringIO(newline=...); a.write(stuff)`.
I understand you would like to have a way to set the int
Guido van Rossum added the comment:
Hm... Since \r\n ends with \n, what exactly would it help to pass in \r\n as
the desired line ending? In either case the entire line (including the \r\n)
would be returned.
Unless you have a need for treating foo\nbar\r\n as a single line? (But why
would
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
New submission from Guido van Rossum:
In 3.5 and up the asyncio test are pretty chatty with warnings. E.g. a recent
run gave me this in 3.5:
./python.exe -m test.test_asyncio
.../Users/guido
Guido van Rossum added the comment:
I added a whole bunch of review comments. Please send a new patch!
--
___
Python tracker
<http://bugs.python.org/issue23
Guido van Rossum added the comment:
Someone please submit a patch...
--
assignee: -> docs@python
components: +Documentation -asyncio
keywords: +easy
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issu
Guido van Rossum added the comment:
Or call gc.collect() in that TestCase.setUp()?
--
___
Python tracker
<http://bugs.python.org/issue25272>
___
___
Python-bug
Guido van Rossum added the comment:
I don't see a reason to deprecate anything. Can you write up in one paragraph
how StringIO's newline flag differs from the one to TextIOWrapper? (What
happens to the initial value is a separate i
Guido van Rossum added the comment:
Can you fix the issue title or do you want me to fix it? And did you also add a
file you meant to go to a different issue? (Maybe link to the new issue and I
can figure it out.)
--
___
Python tracker
<h
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg252050
___
Python tracker
<http://bugs.python.org/issue25291>
___
___
Python-bug
Changes by Guido van Rossum :
Removed file: http://bugs.python.org/file40651/example_files.tar.gz
___
Python tracker
<http://bugs.python.org/issue25291>
___
___
Python-bug
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg252051
___
Python tracker
<http://bugs.python.org/issue25291>
___
___
Python-bug
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg252053
___
Python tracker
<http://bugs.python.org/issue25291>
___
___
Python-bug
Guido van Rossum added the comment:
(OK, issue should be all cleaned up. :-)
--
___
Python tracker
<http://bugs.python.org/issue25291>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
Patch looks good.
--
___
Python tracker
<http://bugs.python.org/issue16802>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Guido van Rossum:
This is a placeholder bug to reference the PR:
https://github.com/python/asyncio/pull/273 by Vincent Michel.
--
assignee: gvanrossum
components: asyncio
messages: 252215
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status
Changes by Guido van Rossum :
--
nosy: +vxgmichel
___
Python tracker
<http://bugs.python.org/issue25304>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
stage: -> commit review
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue25304>
___
___
Python-bugs-list
Guido van Rossum added the comment:
It's done. But I am hoping you (or someone) will add docs.
--
___
Python tracker
<http://bugs.python.org/issue25304>
___
___
Guido van Rossum added the comment:
I'm adding a rebased version of Chris's v4 patch to see if I can get the code
review to trigger.
--
Added file: http://bugs.python.org/file40667/23972_cjl_v005.patch
___
Python tracker
<http://bu
Guido van Rossum added the comment:
You should not be using readline() for that use case. (Note that *no* sequence
of characters can be guaranteed not to occur in a binary protocol like pickle.)
--
resolution: -> not a bug
status: open ->
Guido van Rossum added the comment:
I'm against that idea. I don't really see a great important future for this
method either way: It's just a little bit of glue between the threaded and
asyncio worlds, and people will learn how to use it by finding an example.
The existin
Guido van Rossum added the comment:
@rdm: thanks, you nailed it. :-)
@yury: but where would you have gotten the awaitable in the first place? It's
easy to see how to get a coroutine -- just define it (with either @coroutine or
async def) and call it -- and I think that's the onl
Guido van Rossum added the comment:
Well, I still worry that this is just going to encourage more people to try and
call awaitables from threaded code, and through some circuitous path of
misunderstandings (probably involving StackOverflow :-) end up using this
function.
(Pretty much the
Guido van Rossum added the comment:
The docs look good. (I assume you've generated the HTML and checked that the
output looks good, links are clickable etc.) What do you need to add to the
concurrency and multithreading section?
I agree on the try/except; can you add that to the same
Guido van Rossum added the comment:
Thanks for the patch! It's live now. Closing. Watch the buildbots for me please!
--
assignee: -> gvanrossum
resolution: -> fixed
status: open -> closed
versions: +Python 3.6
___
Python
Guido van Rossum added the comment:
The patch fails to apply in the 2.7 branch. It works in 3.4. Could you look
into the 2.7 issue?
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
> Should I add a note to explain why the loop argument has to be explicitly
passed? (there is a note at the beginning of the `task functions` section
stating "In the functions below, the optional loop argument ...")
Oh, that's a good idea.
Guido van Rossum added the comment:
It looks like we don't merge 2.7 into 3.4 any more, so that will have to be a
separate patch anyway.
So you can commit the patch to 3.4, merge into 3.5 and 3.6. Good luck! And
thanks for your perseve
Guido van Rossum added the comment:
loop *is* required for this function. It's just that there's an earlier,
general comment describing it as optional for all functions in this section.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
I think it's fine. I'm going to commit this now. Thanks again!
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
Thanks!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25304>
___
___
Guido van Rossum added the comment:
Indeed, ptys and pipes behave very differently (that's why we have both -- they
serve different purposes).
More relevant question: we should find a way to decide whether to either apply
Antoine's patch or close this issue.
Finally, maybe arra
Guido van Rossum added the comment:
Honestly, Antoine's patch looks reasonable to me (except that the names of the
test modules perpetuate the confusion that pipes and ptys are similar).
Can someone just port that to 3.6? (The change in semantics is big enough that
I don't think
Guido van Rossum added the comment:
So maybe we should just close this as won't fix. Whoever wants to use the
master end of a pty had better be prepared for that IOError.
On Thursday, October 8, 2015, Martin Panter wrote:
>
> Martin Panter added the comment:
>
> My bigges
Guido van Rossum added the comment:
OK, I'm closing this as won't fix. If someone disagrees please explain.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.p
Guido van Rossum added the comment:
Can you test with this patch?
--
keywords: +patch
Added file: http://bugs.python.org/file40744/coro-skip.diff
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
Can one of you produce a proper patch? Then the other can review. Serhiy can
commit it.
--
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
Confirmed. The failure is because Pattern is _TypeAlias, which is not a type.
But it should be allowed. I'll think of something. (Does mypy accept this?)
--
nosy: +gvanrossum
___
Python tracker
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
___
Python tracker
<http://bugs.python.org/issue25390>
___
___
Python-bugs-list mailing list
Un
Guido van Rossum added the comment:
See also this upstream git issue: https://github.com/python/asyncio/issues/263.
Let me know whether the patch suggested there works for you, and I'll
prioritize getting it checked in. (Help would also be appreciated, e.g. in the
form of a uni
Changes by Guido van Rossum :
--
versions: +Python 3.4, Python 3.6
___
Python tracker
<http://bugs.python.org/issue25441>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Fixed by 17f76258d11d, d30fbc55194d and 08adb4056b5f.
--
assignee: -> gvanrossum
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
I just re-read the docs here (which came straight from the open_connection()
docstring). The parenthetical remark is confusing -- I meant something more like
"""
If you want to use different classes than StreamReader, StreamReaderProtocol
a
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Guido van Rossum :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25390>
___
___
Python-bugs-
Guido van Rossum added the comment:
FWIW the pickle produced looks like this, decoded with pickletools.dis():
0: \x80 PROTO 3
2: cGLOBAL '__main__ B'
14: qBINPUT 0
16: )EMPTY_TUPLE
17: \x81 NEWOBJ
18: qBINPUT 1
20: }EMPTY_DIC
Guido van Rossum added the comment:
The issue seems to be the line
inst_dict = inst.__dict__
in _Unpickler.load_build(). (I found this out by forcing
sys.modules['_pickle'] = None, so the pure-Python pickle.py code gets used.)
This leads to a simpler repro:
# Us
Guido van Rossum added the comment:
Whew. Complex issue!
The OP should probably use his workaround or call loop.stop() instead of
raising SystemExit.
Asyncio in general is rather careless about "true" BaseExceptions (i.e. that
aren't also Exceptions), we should decide what we
Guido van Rossum added the comment:
How about we extend loop.stop() so that you can pass it an exception to
raise once the loop is stopped? This exception would then be thrown out of
run_forever(). There may be some delay (callbacks already scheduled will
run first) but it is how things were
Guido van Rossum added the comment:
It makes it more awkward to keep the asyncio docs in sync between 3.4 and 3.5.
Also it makes copying examples harder for users who need compatibility with 3.4
or 3.3.
--
___
Python tracker
<h
Guido van Rossum added the comment:
Honestly I think it's better if most people keep using coroutine/yield-from
instead of async/await for a few more releases; their code will be more
portable, since it takes forever to update old datacenters. We put in
async/await with an eye toward
Guido van Rossum added the comment:
OK, I'll wait for someone to submit a patch for this. (I tried a quick hack,
but unless we limit this to BaseException instances that aren't also Exception
instances it's complicated).
--
___
Guido van Rossum added the comment:
Well, the warning points to a deeper issue -- the fix doesn't work for TLS
connections. Also, the upstream issue (
https://github.com/python/asyncio/issues/251) is still open because there's
no test for thi
Guido van Rossum added the comment:
I'm coming at this without much context (I don't recall the original issue)
but IIUC from a security POV, lenient parsing is unsafe -- it could allow
an attacker to modify a cookie (or part of a cookie -- I'm unclear on the
correct terminology h
Guido van Rossum added the comment:
Sounds good. I'll commit this.
--
___
Python tracker
<http://bugs.python.org/issue25536>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
Fixed in 3.4, 3.5, 3.6 by these commits: 193327cabbbc, e2400d5d67e7,
40ce5f4b8835.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
Hm... I don't know what answer you would expect. Who says your mock shouldn't
behave like a coroutine? In general, passing mocks to functions is likely to
return a mock -- even boolean functions.
Can you provide mo
Guido van Rossum added the comment:
Please show us how to repro -- there's no way we can figure out how this
"impossible" event could happen in your code without understanding your code.
Is it possible that multiprocessing forked your event loop or something
sim
Guido van Rossum added the comment:
Sorry, the code you posted is still incomprehensible. E.g. I suppose your
worker doesn't really have
```
obj = self.queue.get()
```
but rather something like
```
obj = yield from async_queue.get()
```
But in the end, even with that hypothesis, I can'
Guido van Rossum added the comment:
I wonder if the bug is in aiohttp? The code you show is still too complex
to debug for me.
--
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
Justin's repro provides a clue: when the event loop is stopped before all
callbacks have been processed, when the loop is restarted the I/O selector
is asked again to do its work, and it will report all the same sockets as
ready. So then the callback wi
Guido van Rossum added the comment:
I'm not an expert on this terminology but don't you have that backwards?
Assume we're using select() for a second. If you ask select() "is this FD
ready" several times in a row without doing something to the FD it will
answer yes
Guido van Rossum added the comment:
Thanks, but I don't like the idea of that patch. It feels like a hack that
makes it less likely that the issue occurs, but I don't feel we should rely on
the callbacks being called before checking the selector again. There may be
other reasons
Guido van Rossum added the comment:
I thought some more about this. The problem is due to stopping and
restarting the loop, and that's also something that occurs in
Alexander's example code, so I retract my accusation of aiohttp (and I
don't think I need more investigation o
Guido van Rossum added the comment:
Yeah, I've thought about changing the stop() mechanism too. It might
mean that some callbacks will be executed that are currently skipped
though, if your proposal is to run all callbacks in self._ready
(excluding new ones) and then just exit if the stop
Guido van Rossum added the comment:
The word 'optional' is literally the second word of the description of
get_extra_info(). WHat more do you want?
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
OK, I concede your point. It shouldn't be too hard to make
asyncio.iscoroutinefunction() behave the same way as
inspect.iscoroutinefunction(). Can you submit a patch?
--
___
Python tracker
<http://bugs.py
Guido van Rossum added the comment:
I'm okay with raising ValueError for length<0; but for length==0 the
behavior is very much intentional -- reading zero bytes is sometimes a
useful end case that otherwise you would have to work around in th
Guido van Rossum added the comment:
Well I don't know how adding a note to the doc is going to change that
much (those users probably don't read the docs but copy some example),
but go ahead and add something.
--
___
Python trac
Guido van Rossum added the comment:
Thinking about this more I believe it's possible for any of the FD callbacks in
selector_events.py to be placed into loop._ready multiple times if the loop is
stopped after the FD is ready (and the callback is scheduled) but before the
callback is c
Guido van Rossum added the comment:
Should also be fixed in the next 3.4/3.5 releases. We rewrote the guts of the
Queue class to be much simpler. See https://github.com/python/asyncio
(specifically,
https://github.com/python/asyncio/commit/872597ba12953849cc6893042fd044073b87f870
Guido van Rossum added the comment:
@Justin: Do you want to come up with a PR for the stop() changes?
Hopefully including tests (I bet at least one test will fail -- our
tests in generally are pretty constraining).
On Mon, Nov 16, 2015 at 6:32 PM, Justin Mayfield wrote:
>
> Justin Ma
Guido van Rossum added the comment:
Fixed in repo is good enough to close an issue.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
You might have to ping python-dev. But in terms of priorities I think
it's not a blocker -- it's been broken for quite some time now, and
it's a fairly odd corner of the language.
--
___
Python
Guido van Rossum added the comment:
Update: I have not forgotten this, but it's a tough case and I haven't made
much progress. I don't think I'll make the deadline for 3.5.1.
--
assignee: -> gvanrossum
___
Python tracker
Guido van Rossum added the comment:
Actually, I just found an embarrassingly simple fix:
diff --git a/src/typing.py b/src/typing.py
index d900036..49c4a06 100644
--- a/src/typing.py
+++ b/src/typing.py
@@ -981,7 +981,7 @@ class GenericMeta(TypingMeta, abc.ABCMeta
Guido van Rossum added the comment:
Thanks for the report! Made it before the 3.5.1 (rc1) deadline.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
Fixed it! Thanks for the report *and* the patch. I wrote a different test
though.
--
assignee: -> gvanrossum
resolution: -> fixed
status: open -> closed
versions: +Python 3.6
___
Python track
Guido van Rossum added the comment:
I'm going to fix up the patch and apply it so this can make 3.5.1 rc1.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Here's a better patch.
- Renamed _stopped to _stopping.
- Restore test_utils.run_once() and add a test for it.
- Change logic so if _stopping is True upon entering run_forever(), it will run
once.
Please try i
Guido van Rossum added the comment:
Here's the file.
--
Added file: http://bugs.python.org/file41080/issue25593_revised.patch
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
New patch. Update test_utils.run_once() to use the recommended idiom. On second
thought I don't like issuing a warning when stop() is called before the loop
runs -- a warning seems overkill for something so minor. But I'm okay with no
longer re
Guido van Rossum added the comment:
No, I mentioned the idea of a warning in the thread on the
python-tulip mailing list, but decided not to do it after all.
--
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
OK, here's another revision of the patch, setting the timeout passed to the
selector to 0 when the loop is pre-stopped.
--
Added file: http://bugs.python.org/file41084/issue25593_revised_3.patch
___
Python tr
Guido van Rossum added the comment:
OK, another revision, keep the mock selector.
--
Added file: http://bugs.python.org/file41086/issue25593_revised_4.patch
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
Whoops. Hopefully this one's right.
--
Added file: http://bugs.python.org/file41087/issue25593_revised_5.patch
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Hopefully this is it!
--
assignee: -> gvanrossum
resolution: later -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Guido van Rossum :
--
keywords: +easy
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue25675>
___
___
Python-bugs-list mai
Guido van Rossum added the comment:
I'm sorry, I'm no help here -- I don't know how __context__ is
supposed to work. :-(
On Fri, Nov 20, 2015 at 8:14 AM, Yury Selivanov wrote:
>
> Yury Selivanov added the comment:
>
> Martin, you might be right here. Guido, do you
Guido van Rossum added the comment:
Serhiy, feel free to commit that patch. I was just being lazy. Also, I was
using assert instead of self.assertEquals etc. out of laziness (and because at
Dropbox people have got the py.test religion and prefer to use assert
statements -- but I'm not ke
Guido van Rossum added the comment:
I don't think we should "fix" the select module; it's advertised as a wrapper
around the various syscalls, and if the platforms disagree on what that syscall
(e.g. select()) does we shouldn't try to fix it. (Documenting the differ
Guido van Rossum added the comment:
read(0) on a regular stream and os.read(fd, 0) also return an empty string
without error. This is not something we should keep debating.
--
___
Python tracker
<http://bugs.python.org/issue25
Guido van Rossum added the comment:
If you hit EOF in the middle of a partial separator, treat it as a premature
EOF just as if you hit EOF before the separator -- the record is not properly
terminated so it shouldn't be accepted.
I prefer a single PR that has the full code.
We kee
5001 - 5100 of 5563 matches
Mail list logo
