Guido van Rossum added the comment:
Corrected aixfix.diff (the other one was for the Tulip repo).
--
___
Python tracker
<http://bugs.python.org/issue19
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg200877
___
Python tracker
<http://bugs.python.org/issue19293>
___
___
Python-bug
Guido van Rossum added the comment:
Corrected aixfix.diff for CPython repo (the previous one was for the Tulip
repo).
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Third try's a charm. Corrected aix fix.
--
Added file: http://bugs.python.org/file32292/aixfix2.diff
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg200878
___
Python tracker
<http://bugs.python.org/issue19293>
___
___
Python-bug
Changes by Guido van Rossum :
Removed file: http://bugs.python.org/file32291/aixfix.diff
___
Python tracker
<http://bugs.python.org/issue19293>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
"And there was much rejoicing."
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs
Guido van Rossum added the comment:
If the buildbot is still green, can you close this? I don't think it's worth
trying to formulate and test a more precise theory about the root cause, given
that it's most likely a plat
Guido van Rossum added the comment:
I revived my ancient PowerBook G4 just to get to the bottom of this.
The long and short of the issue seems to be that when subprocess.Popen() closes
the *read* end of the stdin pipe, fstat() on the *write* end starts failing
with EBADF. The exact line where
Guido van Rossum added the comment:
@grahamd: I occasionally have felt the pain of wrapping @classmethod (or
@staticmethod). Never enough though to think of how to fix it. I really don't
have the stomach to review your wrapt library, but your code looks okay except
for style and missing
Guido van Rossum added the comment:
I added some comments to the code review. Please take a look.
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
LGTM. Commit!
--
___
Python tracker
<http://bugs.python.org/issue19172>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
(Adding CF's new patch so I can compare and review it.)
--
Added file: http://bugs.python.org/file32428/selectors_map-2.patch
___
Python tracker
<http://bugs.python.org/is
New submission from Guido van Rossum:
(Bruce Leban, on python-ideas:)
"""
ntpath still gets drive-relative paths wrong on Windows:
>>> ntpath.join(r'\\a\b\c\d', r'\e\f')
'\\e\\f'
# should be r'\\a\b\e\f'
>>> ntpath.jo
Guido van Rossum added the comment:
What's the use case for not wanting to use an extra FD?
Nevertheless I'm fine with using a function to pick the default selector (but
it requires some changes to asyncio too, which currently uses DefaultSelector).
Something I would find useful
Guido van Rossum added the comment:
Hm... I'm trying to understand how you're using the selector in
telnetlib.py (currently the only example outside asyncio). It seems you're
always using it with a single file/object, which is always 'self' (which
wraps a socket), exce
Guido van Rossum added the comment:
OK. Let's have a function to select a default selector. Can you think of a
better name for the parameter? Or maybe there should be two functions?
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Hm. If you really are going to create 300 instances, you should probably
use asyncio. Otherwise, how are you going to multiplex them? Create 300
threads each doing select() on 1 FD? That sounds like a poor architecture
and I don't want to bend over back
Guido van Rossum added the comment:
Well, I don't know if this sways anything, but I was probably responsible, and
I think my argument was something about not all timestamp sources having
microseconds, and not wanting to emit the ".00" in that case. If I could go
back
Guido van Rossum added the comment:
Looking at this some more, I think one of the reasons is that isabs() does not
consider paths consisting of *just* a drive (either c: or \\host\share) to be
absolute, but it considers a path without a drive but starting with a \ as
absolute. So perhaps it&#
Guido van Rossum added the comment:
PEP 428 offers a reasonable view. Search
http://www.python.org/dev/peps/pep-0428/ for "anchored" and read on.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
Do we even have a way to get the current directory for a given drive? (I guess
this is only needed for C: style drives.)
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
> AFAICT, we haven't reached a consensus yet on the best way to handle
EBADF.
By which you mean that you still don't agree with my proposal? Which is to
fix it for most syscalls but not for select(), poll() and similar (anything
that the new sel
Guido van Rossum added the comment:
Eww, sorry. That's the second time I mistook this thread for the other. I
re-read the original description and I now think that we should follow your
original advice.
There are two separate cases:
(1) Registering an invalid FD; this succeeds for s
Changes by Guido van Rossum :
--
nosy: +gvanrossum, neologix
___
Python tracker
<http://bugs.python.org/issue19497>
___
___
Python-bugs-list mailing list
Unsub
New submission from Guido van Rossum:
The patch doesn't actually apply, not just because the pathnames are different,
but because the unittests in Lib/test/test_selectors.py have a different
structure.
--
___
Python tracker
<http://bugs.py
Guido van Rossum added the comment:
Check out my review: http://bugs.python.org/review/19497/#ps9821
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Fixed by revision 9c976f1b17e9.
--
assignee: -> gvanrossum
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
Style is a matter of taste, not of correctness. It is pointless to debate the
finer points in a bug report.
--
resolution: -> invalid
status: pending -> closed
___
Python tracker
<http://bugs.p
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue19565>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I'll ask Anthony Baire (the author of the new child watcher code) to look into
this. Thanks for reporting this!
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Hmm... That fix works, and if you're concerned about the buildbots, by all
means check it in.
But I think the root cause is a poor API for initializing ChildWatchers. This
is currently done at the end of __init__() -- it calls self.set_loop() whi
Guido van Rossum added the comment:
TBH the test structure is also rather fragile. I need to think about it more;
the global state to hold the current test instance smells, as do the various
class-level functions (waitpid(), WIFEXITED() etc.) that aren't methods but
used as mock func
Guido van Rossum added the comment:
I pushed Victor's temporary patch so the buildbots can have peace.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
resolution: -> duplicate
superseder: -> test_asyncio: test__run_once timings should be relaxed
___
Python tracker
<http://bugs.python.org/i
Changes by Guido van Rossum :
--
nosy: +ezio.melotti, pitrou
___
Python tracker
<http://bugs.python.org/issue19579>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Thanks for the fix!
--
___
Python tracker
<http://bugs.python.org/issue19580>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Looks good -- please commit.
--
___
Python tracker
<http://bugs.python.org/issue19589>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Likely. Can you suggest a fix?
--
___
Python tracker
<http://bugs.python.org/issue19598>
___
___
Python-bugs-list mailin
Changes by Guido van Rossum :
--
nosy: +larry
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue16596>
___
___
Python-bugs-lis
Guido van Rossum added the comment:
I'd love it if someone could review this. This would be a great improvement to
debugging coroutines in asyncio.
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org
Guido van Rossum added the comment:
I think this is not ready for inclusion. It works wonderfully when stepping
over a yield[from], but I can't seem to get it to step nicely *out* of a
generator. (Details on request -- basically I put a "pdb.set_trace()" call in
Tulip'
Guido van Rossum added the comment:
I don't think it's worth complicating the code for this (except perhaps by
making the tests fail more gracefully).
The tasks and futures modules import various things from concurrent.futures
(some exceptions, and some constants for wait()).
If
Guido van Rossum added the comment:
Well, what would be the incantation to just skip the tests if
concurrent.futures can't be imported?
(Although it seems that there's a problem with concurrent.futures if the whole
thing refuses to import just because multiprocessing isn&#
Guido van Rossum added the comment:
Can you try this patch? It tweaks the test to skip everything if it can't
import concurrent.futures.
--
keywords: +patch
Added file: http://bugs.python.org/file32676/skipit.patch
___
Python tracker
Guido van Rossum added the comment:
I'll just commit it and pray.
--
___
Python tracker
<http://bugs.python.org/issue19635>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
Basically the debugger lost control and the program ran to completion after I
hit 'n' that returned from the coroutine.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
The traceback is pretty useless. So is the title of the other bug report "hangs
for 1 hour" (which just means it hangs forever but the test runner kills it
after one hour).
We would need to run the tests with -v so at least we can pinpoint which o
Guido van Rossum added the comment:
I cannot help you unless you tell me which specific test is failing. But once
you have a proposed fix I will review it. Thanks for advocating for the
minority platforms!
--
___
Python tracker
<h
Guido van Rossum added the comment:
It's not fixed. Let me paste in a session. This uses the latest Tulip repo
(simple_tcp_server.py was just added). I've added "import pdb;
pdb.set_trace()" to the top of the client() coroutine, to set a breakpoint (I'm
a very
Changes by Guido van Rossum :
--
nosy: -gvanrossum, jackjansen
___
Python tracker
<http://bugs.python.org/issue15204>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Oh, sorry, I didn't realize the name of the failing test was in the issue
title. But even that's no excuse, because it's also in the log. :-(
Fortunately the line where we're hanging is also in the log: line 291 in
selectors.py is in Pol
Guido van Rossum added the comment:
I don't feel very strongly, but I do think that most of the things the new
syntax allows are not improvements -- they make the decorator harder to read.
It was intentional to force you to compute a variable before you can use it as
a decorator
Guido van Rossum added the comment:
This version works beautifully in that scenario!
Does anyone else reading this bug report object to this being committed?
--
___
Python tracker
<http://bugs.python.org/issue16
Guido van Rossum added the comment:
I think there's a similar but slightly different convention in Sphinx
autodoc -- the first line of the docstring can be "name(...)" . Isn't that
better than def?
--
___
Python tracker
<
Guido van Rossum added the comment:
Hmm... When did you last see the hang? We've had a variety of checkins that
might have affected this code.
If you've seen at least one traceback later than the commit below, feel free to
commit. Otherwise, let's wait.
changeset: 87088:eb
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Guido van Rossum added the comment:
Can you also add a patch to asyncio (I suppose to the code where it calls
set_default_verify_paths())?
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
So do you need anything on *this* issue?
(And are you asking me to review/approve the other issue? I haven't kept
track carefully enough for that, and the beta is looming.)
--
___
Python tracker
Guido van Rossum added the comment:
I need help!
There is one urgent issue: should the chapter on asyncio go into section 17
(Concurrent Execution) or section 18 (Interprocess Communication and
Networking)??? It would seem that event loops and coroutines fit better in
section 17, while
Guido van Rossum added the comment:
OK. I accidentally committed the patch. Will move the three modules to the
ipc section now.
On Fri, Nov 22, 2013 at 11:47 AM, Eric Snow wrote:
>
> Eric Snow added the comment:
>
> I was thinking the same thing as Antoine. 18 fits in more clo
Guido van Rossum added the comment:
Heh, I'd forgotten about this issue. Done. :-)
--
assignee: -> gvanrossum
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> enhancement
___
P
Guido van Rossum added the comment:
Thanks -- please just commit, we can iterate.
--
___
Python tracker
<http://bugs.python.org/issue19291>
___
___
Python-bug
Guido van Rossum added the comment:
Good question. I don't mind making these ABCs, but I don't think it's necessary
to do it before beta1 (since it won't matter for most people).
--
___
Python tracker
<http://bug
Guido van Rossum added the comment:
I'm not sure that "ABC" implies "an instance of abc.ABC". It's still an
abstract base class (in the usual definition of that concept) even if it
doesn't enforce anything.
Guido van Rossum added the comment:
Well, it *is* abstract because it has no implementations and all the
methods raise NotImplementedError. We can do better in the .rst docs though.
--
___
Python tracker
<http://bugs.python.org/issue19
New submission from Guido van Rossum:
When running test_pathlib on my OSX (10.8) laptop I get these errors:
==
ERROR: test_group (test.test_pathlib.PathTest
Guido van Rossum added the comment:
Agreed that that is probably unrelated.
I suspect that all tests doing real I/O (stuff that goes through the OS kernel)
and wait for it using run_briefly() are theoretically broken like that. It may
just be harder to provoke for some tests than for others
Changes by Guido van Rossum :
--
components: +Tests
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Guido van Rossum added the comment:
I don't know much about subprocess.py and I don't have access to Windows 8.
But it looks like the kind of thing that might happen if the other end of the
"pipe" is closed, which might happen if the subprocess exits early, either
becau
Guido van Rossum added the comment:
Can you try this patch?
diff -r 14cbf01b1929 tests/test_unix_events.py
--- a/tests/test_unix_events.py Sun Nov 24 11:04:44 2013 -0800
+++ b/tests/test_unix_events.py Sun Nov 24 12:28:42 2013 -0800
@@ -379,7 +379,7 @@
fstat_patcher
Guido van Rossum added the comment:
Can you try this fix?
diff -r 8d0206f97439 Lib/test/test_asyncio/test_events.py
--- a/Lib/test/test_asyncio/test_events.py Sun Nov 24 22:41:35 2013 -0800
+++ b/Lib/test/test_asyncio/test_events.py Mon Nov 25 07:48:29 2013 -0800
@@ -559,7 +559,7
Guido van Rossum added the comment:
That's not even in test_asyncio. It also doesn't belong in this bug (which is
for AIX).
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
I decided to abandon this project and close the issue as wontfix.
--
resolution: -> wont fix
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
OK, let's forget about it.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Guido van Rossum added the comment:
I would much rather review the docs after they've been committed.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
resolution: rejected -> fixed
___
Python tracker
<http://bugs.python.org/issue19822>
___
___
Python-bugs-list mailing list
Un
Guido van Rossum added the comment:
This is explicitly left up to the core developers' finely tuned sense of
judgment. Adding a definition will not simplify decisions or reduce
disagreements, it will just cause more pointless legalistic debate about the
meaning of specific
Guido van Rossum added the comment:
This is definitely an improvement over the previous example, but I think both
examples are still pretty unrealistic; they seem to be more useful as smoke
tests than as examples. My primary concern is that, in order to be both
self-contained and small, both
Guido van Rossum added the comment:
Here's my suggestion. It can use a lot of cleaning up, but it shows the
fundamentals of a selector-based I/O loop.
--
Added file: http://bugs.python.org/file32896/echo.py
___
Python tracker
Changes by Guido van Rossum :
Removed file: http://bugs.python.org/file32896/echo.py
___
Python tracker
<http://bugs.python.org/issue19836>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Sorry, here's a version with slightly more logical order of the code.
--
Added file: http://bugs.python.org/file32897/echo.py
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Committed: revision 2a679870d7d2.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
I wouldn't call that "being the most careful". I've always had an implicit
understanding that calls with timeouts may, for whatever reason, return sooner
than requested (or later!), and the most careful approach is to re-ch
Guido van Rossum added the comment:
You're right, I commented previously without reading the context. The classes
defined in protocol.py are not ABCs, they are just base classes (and not
mandatory, just convenient, because the transport *will* assume all methods are
implemented, and
Changes by Guido van Rossum :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
LGTM, although I wish that you had time to implement the comment "TODO:
Subclasses can probably optimize this even further" rather than just shuffling
the existing code around. :-)
--
___
Python trac
Guido van Rossum added the comment:
We went through this whole discussion before. Returning immediately with three
empty lists is better than raising InterruptedError. Retrying is not always
better.
--
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Do you haven an example of a program using asyncio that fails because of this?
Adding gps because he seems to agree that EINTR must die.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
I appreciate the simplicity, but I don't think it is acceptable -- if the dict
is large, materializing the entire list of keys/values/items might allocate a
prohibitive amount of memory. It's worse if you have code that is expected to
break out o
Guido van Rossum added the comment:
I'm with Antoine. Have we heard of any problems with the 3.x version of the
patch? How different is it?
--
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
Isn't this mostly political correctness? The hello world programs really don't
need to worry about closing the socket pair. Most real-world programs don't
either -- the recommended pattern is just to loop until the end of the world,
an
Guido van Rossum added the comment:
I have a question. Is there actually any need for this with asyncio? The
selector already handles EINTR, and all the I/O done by asyncio's transports
already handles it too (there are "except (BlockingIOError, InterruptedError)"
clauses all
Guido van Rossum added the comment:
That's just rhetoric -- I am beginning to believe that nobody has any data.
Here's some opposite rhetoric. If it ain't broke, don't fix it. Plus, if it's
so much better, why isn't it the default? If you say "for
Guido van Rossum added the comment:
To create a new event loop, use set_event_loop(new_event_loop()). You have to
do that if you want an event loop in a thread; it's also handy in unit tests.
(However asyncio's own unit tests only call new_event_loop() and pass it around
expli
Guido van Rossum added the comment:
But there is Antoine's point. This makes
with get_event_loop() as loop:
an attractive nuisance if it's used in the wrong place.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
Well, calling close() is best practice *if you own the loop*. But the thing is
that you may not own what get_event_loop() returns, and in fact in most cases
where it is called you don't own it. This is very different from files:
with open(...)
Guido van Rossum added the comment:
The asyncio patch looks fine, but I'd like to see a unittest that actually
fails (or mocks failing) the hostname check where it is now performed (in
wrap_socket() IIUC?), to make sure that the exception is propagated out
pro
Guido van Rossum added the comment:
Hm, so we can choose to be more like POSIX realpath() or more like
os.path.realpath(). I guess your original intuition was right. Close with no
action is fine. If I need a partial real path I can always crawl up parents()
until I find a path that does
Guido van Rossum added the comment:
Sure.
--
___
Python tracker
<http://bugs.python.org/issue19717>
___
___
Python-bugs-list mailing list
Unsubscribe:
4101 - 4200 of 5563 matches
Mail list logo
