Changes by Guido van Rossum :
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue19097>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Charles-Francois, sorry to add you back to the bug, but (a) I thought you had
agreed to a compromise patch that restarts signals in most cases but not for
select(), poll() etc.; (b) I may have found a flaw in the idea.
The flaw (if it is one) is related to
Guido van Rossum added the comment:
I believe you that the example invocation is wrong. But then shouldn't it raise
an exception? I still think that if len() raises KeyError, bool() should raise
KeyError too.
--
___
Python tracker
Changes by Guido van Rossum :
--
stage: -> patch review
type: -> enhancement
versions: +Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/i
New submission from Guido van Rossum:
The traceback module is driving me nuts. It has some handy helpers to extract
info about a traceback or a full stack without formatting them, but (a) these
are _internal, and (b) they don't return the frame object as part of the
information, so code
Guido van Rossum added the comment:
Sigh. Here it is.
--
keywords: +patch
Added file: http://bugs.python.org/file31946/TB.patch
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
>
> I don't like "_ex" suffixes, it's not future proof if we need to add
> another function later.
>
Me neither, but you can't change a function that returns a list of 4-tuples
into a function that returns a list of 5-
Guido van Rossum added the comment:
No, reversed() doesn't work on iterators.
--
___
Python tracker
<http://bugs.python.org/issue19146>
___
___
Python-bugs-l
Guido van Rossum added the comment:
Nice. However it will take up a lot more space, because now there's an instance
dict. (And adding __slots__ to a namedtuple subclass doesn't work.) I'll have
to think about whether I care about
Guido van Rossum added the comment:
Well this is what I get:
$ python3
Python 3.4.0a1+ (default:41de6f0e62fd+, Aug 27 2013, 18:44:07)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" fo
Guido van Rossum added the comment:
No time to follow this in detail, but one thing: please do not make the
selector appear "false" under *any* circumstances. I've seen too many code
write "if foo" where they meant "if foo is not None" and get in trouble be
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue3982>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue4888>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Guido van Rossum:
I'll add the tests next. The plan is to get this in the next (last) alpha
release.
--
messages: 199953
nosy: gvanrossum, larry, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: Add asyncio (tulip, PEP
Guido van Rossum added the comment:
Here's an updated patch that doesn't botch the selectors imports.
--
keywords: +patch
Added file: http://bugs.python.org/file32125/asyncio2.patch
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
What I need help with most right now is a suggestion of where the unittests
should go. There are too many of them to all put in one file. Some options:
asyncio/test/*_test.py
asyncio/test/test_*.py
test/test_asyncio/
What's the best current practice
Guido van Rossum added the comment:
OK, here's a new patch that includes tests.
To run the tests, I use:
./python.exe Lib/test/regrtest.py --fromfile Lib/test/test_asyncio/tests.txt
--verbose
There are a total of 4 individual test failures, all having to do with SSL:
ssl.SSLEOFError
Guido van Rossum added the comment:
Found the cause of the ssl test failure -- the location of the ssl test key and
cert are different. Here's a new patch with a quick fix (#4), but I think the
correct solution is to either have the certificates inline in the source and
write them to a
Guido van Rossum added the comment:
Turns out there were other uses of the sample key/cert pair. The easiest
solution is to just have the code try both locations if necessary. Here's a new
patch to review.
--
Added file: http://bugs.python.org/file32134/asyncio5.
Guido van Rossum added the comment:
Here's a partial patch for Windows. (Mostly for myself; I need to integrate
this into the main patch.)
--
Added file: http://bugs.python.org/file32139/winasyncio.diff
___
Python tracker
<http://bugs.py
Guido van Rossum added the comment:
Here's a full new patch, with Windows project/solution changes included, and
updated from the latest Tulip asyncio branch.
--
Added file: http://bugs.python.org/file32140/asyncio6.patch
___
Python tracker
Changes by Guido van Rossum :
Removed file: http://bugs.python.org/file32139/winasyncio.diff
___
Python tracker
<http://bugs.python.org/issue19262>
___
___
Python-bug
Guido van Rossum added the comment:
PS. There's some garbage at the start of pcbuild.sln (perhaps a BOM mark?). I'm
not going to re-upload the patch for now, but please note this.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
New patch, mostly SSL hardening IIRC.
--
Added file: http://bugs.python.org/file32145/asyncio7.patch
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
I could use some help for two issues with the tests:
(1) How do I stop regrtest.py from running the windows tests? (These import
_winapi.)
2 tests failed:
test_asyncio.test_windows_events test_asyncio.test_windows_utils
(2) I get this message -- what
Guido van Rossum added the comment:
I'd have to decorate a lot of tests. Is there a way to fix this at the module
or at least class level? (I'd be willing to move the imports around.)
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
Yup, that works! Not uploading a new patch right now but this is in the tulip
repo now.
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Another day, another patch.
I'd rather like to commit this (and then iterate as needed), it makes my
workflow for porting to Windows a little easier.
Larry???
--
Added file: http://bugs.python.org/file32158/asyncio8.
Guido van Rossum added the comment:
It doesn't break anything AFAICT. (It's a pure addition except for one new
extension module on Windows).
However I just discovered that apparently regrtest doesn't automatically
run tests in a subdirectory of the test package. I'm guess
Changes by Guido van Rossum :
--
keywords: +needs review -patch
___
Python tracker
<http://bugs.python.org/issue19262>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
OK, no more giant patches. It's checked in. I've also solved the regrtest
issues by adding some code in __init__.py and __main__.py.
I expect to iterate a bit over the next few days.
--
___
Python trac
Guido van Rossum added the comment:
Now asyncio/tulip has landed in the 3.4 stdlib, asyncore will be effectively
obsolete starting 3.4 (even if we don't mark it so). Its presence is required
for backwards compatibility, but that doesn't mean we should encourage people
to keep u
Guido van Rossum added the comment:
@Koobs: I'll look into these, but in the future it's better to report bugs
"upstream" for now, i.e. at http://code.google.com/p/tulip/ -- they will get my
immediate attention.
@Antoine: while most of the timing-related tests use a si
Guido van Rossum added the comment:
I fixed the easy one (the expected delay in test_call_later). I could use some
hands with the rest -- I suspect there are similar race conditions.
I'm tracking this now in http://code.google.com/p/tulip/issues/detail?
Guido van Rossum added the comment:
Maybe adding something that returns [] from suite() if therea re no threads in
test/test_asyncio/__init__.py would help? I don't have time to test this, but
go ahead and commit something if it's a release blocker.
Even better would or course
Guido van Rossum added the comment:
Lgtm. Check it in if you can, otherwise I'll take care of it later.
--Guido van Rossum (sent from Android phone)
On Oct 18, 2013 11:51 AM, "Stefan Krah" wrote:
>
> Changes by Stefan Krah :
>
>
> --
> ke
Guido van Rossum added the comment:
Relaxed a bunch of timeouts. No news on the --without-threads case, that
will have to happen post-alpha-4 I expect.
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
I've landed a bunch of stuff, and now I am pretty happy. It's also soon going
to be weekend, which means family time, so I really hope everyone else is also
happy. :-)
A summary of what changed since the initial asyncio checkin:
- Rename the
Guido van Rossum added the comment:
Ready for release!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
I'll track that separately: http://bugs.python.org/issue19291
For now, PEP 3156 has a lot of information. (But the PEP also needs to be
updated to track recent developments.)
--
___
Python tracker
New submission from Guido van Rossum:
The asyncio module needs documentation. I'll work on this in time for the beta
1 release. Until then, please refer to PEP 3156.
--
assignee: gvanrossum
messages: 200324
nosy: gvanrossum
priority: deferred blocker
severity: normal
status:
New submission from Guido van Rossum:
See discussion on
https://groups.google.com/forum/#!topic/python-tulip/c_lqdFjPEbE .
If you set sslcontext.verify_mode = ssl.CERT_REQUIRED and call
sslcontext.set_default_verify_paths(), the stdlib ought to have enough smarts
to use the system root
Guido van Rossum added the comment:
Maybe once this is addressed we could also change urllib.request.urlopen() to
default to cadefault=True?
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Why is this not a security patch? Because it's not a "vulnerability" in the
narrow technical sense? I expect that it will greatly increase the actual
practical security, by making it easier to do
Guido van Rossum added the comment:
Please be more specific.
--
___
Python tracker
<http://bugs.python.org/issue19262>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Is that traceback upside down compared to normal Python tracebacks?
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Assuming it is, it is hanging in the poll() syscall, here:
http://hg.python.org/cpython/file/f3a2dab1623b/Lib/selectors.py#265
Could you see if it works better with select()? Comment out lines 402, 403 in
that file
Guido van Rossum added the comment:
Thanks for reporting these. These tests sometimes pass and sometimes fail,
right? I suspect that there's a race condition in the test and slower
machines provoke it more often. I'm not sure what to do -- I won't have
time to properly debug this
Guido van Rossum added the comment:
@Christian: What is holding up those patches? I don't believe we should be
in the business of distributing certificates -- we should however make it
easy to use the system certificates.
@Antoine: I still claim that a flag that defaults to no security
Guido van Rossum added the comment:
I noticed this previously and was told it wasn't very important. Can I delay
the fix until after the alpha 4 release?
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Thanks for the investigation and the patch.
As to the deeper issue, I'm not sure I understand what's going on -- is this a
bug in Python or in AIX? Is there a better work-around than disabling the
test? The issue 18238 that you mention seems to
Guido van Rossum added the comment:
[Off-topic: Heck, another one of those upside-down tracebacks. WHY???]
I'll need a lot of help from folks on the affected platforms in debugging this,
since these tests work fine when I run them on the platforms to which I have
access (Ubuntu and OS X
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
___
Python tracker
<http://bugs.python.org/issue19293>
___
___
Python-bugs-list mailing list
Un
Guido van Rossum added the comment:
So you agree that we should change the urllib default in 3.4? I'm all for
that.
Tools like svn and hg have extensive configurations for this purpose, and
(at least hg) secure defaults; I certainly remember having to deal with hg
complaining about the sec
Guido van Rossum added the comment:
But do you agree that the urllib default should be changed?
--
___
Python tracker
<http://bugs.python.org/issue19292>
___
___
Guido van Rossum added the comment:
No, please let's not get in the business of shipping certs. Please not.
There should be only *one* place per system where sysadmins have to update
certs. It would not scale if every language implementation were to have its
own set of certs.
Trusting
Guido van Rossum added the comment:
Actually, I think we're talking about the actual select() syscal not
returning when SIGCHLD is received and handled. Running the C-level handler
isn't enough, the syscall must return with EINTR so the Python handler can
run (which then writes a b
Guido van Rossum added the comment:
Thanks Larry!
On Sat, Oct 19, 2013 at 11:32 AM, Larry Hastings wrote:
>
> Larry Hastings added the comment:
>
> Mr. D'Aprano emailed me about getting this in for alpha 4. Since nobody
> else stepped up, I volunteered to check it in for h
Guido van Rossum added the comment:
Looks good. How about adding executor.shutdown(wait=False)? E.g.
def close(self):
self._ready.clear()
self._scheduled.clear()
executor = self._default_executor
if executor is not None:
self._default_executor
Guido van Rossum added the comment:
I guess it's a shame that the two issues got merged, since now it looks like
they may have to be unmerged again. I sent a few comments to neologix' patch
that should be easy to address; for AIX I'm afraid we're still looking for m
Guido van Rossum added the comment:
If CF's patch fixes the Ubuntu hang, commit it! We can iterate on my nits
post-alpha.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I'm guessing there's a whole lot of tests calling run_briefly() that really
need to be fixed along these lines:
http://code.google.com/p/tulip/source/detail?r=44e4c8257a9d
I'd like to add a new method to test_utils.py for that purpose
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
___
Python tracker
<http://bugs.python.org/issue19305>
___
___
Python-bugs-list mailing list
Un
Guido van Rossum added the comment:
Hm... Maybe the wakeup_fd machinery is broken on some systems?
Has anybody been able to confirm that CF's patch fixes the hang on any non-AIX
system? If so, maybe we should commit first, understand
Guido van Rossum added the comment:
That patch looks good except please don't call it wait_for(), since there's
already tasks.wait_for(). You can call it run_until().
Having to pass the loop to sleep() is only really required in the tests --
there was a movement a while ago (start
Guido van Rossum added the comment:
Separate question for David: if CF's patch were committed, would we still need
your patch to disable three subprocess-related tests on AIX? (That can be dealt
with after the alpha release though -- in fact I propose not to wait for AIX if
we can ge
New submission from Guido van Rossum:
I was confused for a while when seeing the thread stacks dumped by the
faulthandler module. (See issue 19293.)
I propose the following tweaks of the output to make this more obvious. The
first chunk changes the header written when called as
Guido van Rossum added the comment:
I looked into this a bit more and it's tricky, because without threads,
asyncio/futures.py can't import some base exceptions concurrent.futures. Also,
some tests create servers in separate threads, and getaddrinfo() would of
course block.
Not su
Guido van Rossum added the comment:
BTW, another oddity in traceback.c: dump_hexadecimal() has the "int fd"
argument at the end, while all other dump_*() functions have it at the front --
even its cousin dump_decimal(). Here's a patch that includes a fix.
--
keyword
Guido van Rossum added the comment:
I wonder if subprocess pipes have a version of the race condition I fixed
for sockets yesterday:
http://code.google.com/p/tulip/source/detail?r=2d392599fa067038b5fc9eeaf051011307aeadee
The pipe code seems derived from the socket code long ago
Guido van Rossum added the comment:
Let's just release the alpha with this as it stands; I will look at the race
condition later, and also at CF's patch (which may be a good idea regardless of
what it fixes).
I did add the breaks to echo and echo3 since the busy-waiting just make
Guido van Rossum added the comment:
I'm trying to let go of the AIX hang. Here's a brain dump of what I've figured
out so far.
* There were a lot of red herrings in the early discussion. This hang doesn't
seem to have anything to do with nonblocking connect() or socket
Guido van Rossum added the comment:
> Apparently, the stdout pipe was closed by the parent process
Could it be that selecting for *read* on the *write* end of a pipe is
always ready? In _UnixWritePipeTransport there's a read handler that
immediately closes the pipe as soon as it c
Guido van Rossum added the comment:
I added an LGTM plus a pointer to
http://code.google.com/p/tulip/issues/detail?id=68
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Ah, sorry, I didn't see this before reviewing your other change to the same
code. Your 2nd bullet is http://code.google.com/p/tulip/issues/detail?id=68
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
> > Could it be that selecting for *read* on the *write* end of a pipe is
> > always ready?
>
> That's exactly what I was thinking when I read the code below: that's
> definitely a possibility on AIX.
David confirmed that it i
Guido van Rossum added the comment:
No, there's a use case for reading after the child exited, if there is a
grandchild still writing.
--Guido van Rossum (sent from Android phone)
On Oct 20, 2013 10:37 AM, "Richard Oudkerk" wrote:
>
> Richard Oudkerk added the comment
Guido van Rossum added the comment:
Is there a patch yet?
--Guido van Rossum (sent from Android phone)
On Oct 20, 2013 1:11 PM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
>
> Since the alpha appears to have been delayed, I think it wou
Guido van Rossum added the comment:
CF, feel free to commit this fix too.
--Guido van Rossum (sent from Android phone)
On Oct 20, 2013 1:05 PM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
>
> Sorry, scratch that. add_signal_handler() won't even a
Guido van Rossum added the comment:
OK, commit it.
--Guido van Rossum (sent from Android phone)
On Oct 20, 2013 2:06 PM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
>
> Yes, there is one :)
>
> --
>
> ___
Changes by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
New patch, with fixed test.
TBH now I'm getting worried that other programs may exist that parse this
format and will get confused.
--
Added file: http://bugs.python.org/file32267/traceback2.diff
___
P
Guido van Rossum added the comment:
On Victor's authority, committed. I've also (separately) committed some doc
changes.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Py
Guido van Rossum added the comment:
OK, I've created issue 19334 to track test_asyncio hangs on other platforms.
Let's please keep this issue restricted to AIX. I am aware of the following
issue:
- select for read on the write end of a pipe returns immediately
Any other AIX i
New submission from Guido van Rossum:
There are still some problems with asyncio tests hanging on FreeBSD and
possibly other platforms.
While these were originally conflated with a hang on AIX, the root causes are
different; just the symptoms are the same (the test hangs forever and after
Guido van Rossum added the comment:
@Richard: socketpair() seems to work fine on AIX (we use it internally). Maybe
we can always use that for subprocess management? But will the subprocess
module support this?
--
___
Python tracker
<h
Changes by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue19326>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Brilliant. It works for me too on OS X.
David, can you check this on AIX?
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Attached is a version of Richard's patch that I like better (sockpair.diff).
- instead of dropping the ValueError, check for ISFIFO and ISSOCK
- pass the read end of the socket pair to Popen()
--
Added file: http://bugs.python.org/file
Guido van Rossum added the comment:
This is by design. Let me try to defend the design.
As long as one of the pipes is still open the parent might be interested in it.
The Protocol object does get notified of the process's exit, via
process_exited(), and if at that point it wants to be
Changes by Guido van Rossum :
Removed file: http://bugs.python.org/file32282/sockpair.diff
___
Python tracker
<http://bugs.python.org/issue19293>
___
___
Python-bug
Guido van Rossum added the comment:
New, improved version of sockpair.diff.
--
Added file: http://bugs.python.org/file32284/sockpair.diff
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
I haven't seen any such hangs. I've seen one test_asyncio failure on FreeBSD
6.4 3.x, which is the following weirdness.
http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/4116/steps/test/logs/stdio
test test_async
Guido van Rossum added the comment:
I find it pretty suspicious that when this fails it is always connecting the
stdin pipe. That code is also suspect in the AIX failure (issue 19293),
although for a different reason.
The only theory I have at this point is that perhaps there's a platfor
Guido van Rossum added the comment:
Thanks; I've applied and pushed your fix for the hang.
I think it's time to commit the sockpair.diff change; the test_write_pipe()
failure looks related -- as you recall the problem doesn't really cause a hang,
it causes a premature closing
Guido van Rossum added the comment:
Let's see how this fares. If it passes on the AIX buildbot, maybe see which of
the tests we skipped on AIX can be re-enabled again?
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I committed a patch that should hopefully fix issue 19293 -- maybe it will also
reduce the flakiness of test_subprocess_shell() on OS X?
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
I think I know what that is -- the test should use a socketpair now. I'll see
how quickly I can give you a patch for that. The other one is now committed.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
David, try this fix (aixfix.diff).
--
Added file: http://bugs.python.org/file32291/aixfix.diff
___
Python tracker
<http://bugs.python.org/issue19
4001 - 4100 of 5563 matches
Mail list logo
