Guido van Rossum added the comment:
Please answer this question. Under what circumstances can a signal handler
interrupt a blocking system call in a thread that is not the main thread?
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Yeah, the behavior is at least different for each type of polling system calls,
and possibly also for different platforms. It would be good to describe at
least all the different possible behaviors
Guido van Rossum added the comment:
Note: it is possible that SO_REUSEPORT is defined yet not implemented (and
you'll get an OSError when using it).
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I'm not sure I understand the hesitation about backporting the Python 3
solution. We're acknowledging it's a bug, so the fix is not a feature. The
Python 3 solution is the future. So why not fix it?
--
___
Guido van Rossum added the comment:
I see no point in keeping this open.
--
resolution: -> works for me
stage: -> committed/rejected
status: open -> closed
type: enhancement -> behavior
___
Python tracker
<http://bugs.python
Guido van Rossum added the comment:
I think we should give the reader some kind of hint, since a bug in this area
may cause a lot of pain when it has to be debugged on porting from a system
where the issue is silent to one where it causes a crash. These docs (unlike a
PEP) are not a formal
Guido van Rossum added the comment:
OK, I've harassed you enough. Sorry. Go ahead and commit this.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I think you're looking for the discussion in issue 19017.
IIRC the conclusion is that not only do you not get the same error everywhere,
but you get it at different points -- sometimes register() of a bad FD passes
and then [Selector.]select() fails,
Guido van Rossum added the comment:
Heh, I'd forgotten the behavior of unregister(). It seems that there are two
layers to the behavior -- if this FD was never register()ed it will raise; if
it was register()ed but has since been close()d it may raise.
For the higher-level APIs in asyn
Guido van Rossum added the comment:
(What I meant to add was, I'd be happy if unregister() also just used a
true/false return.)
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
LGTM. I know I've written similar code in Python. :-)
--
___
Python tracker
<http://bugs.python.org/issue19827>
___
___
Guido van Rossum added the comment:
I just ran into a live case of the platform differences here. Check out
http://bugs.python.org/review/19509/ (issue 19509). Christian uploaded a patch
for asyncio, and when I tested it I got a double traceback and a hang. This
could have been avoided if
Guido van Rossum added the comment:
See my messages on the review. Is it absolutely necessary to close the socket
when the hostname verification fails?
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
The more I think about this the more I believe unregister() should catch the
OSError (but not the KeyError).
Every unregister() implementation starts by calling super().unregister(key),
which has a side effect (it removes the key from the _fd_to_key dict
Guido van Rossum added the comment:
I don't know if it's worth reopening this, but I had a need for generating docs
including attribute docstrings for a namedtuple class using Sphinx, and I
noticed a few things...
(1) Regarding there not being demand: There's a StackOverflow qu
Guido van Rossum added the comment:
On Wed, Dec 4, 2013 at 5:40 PM, Terry J. Reedy wrote:
> 1. I posted on SO the simple Py 3 solution that replaces the previously
> posted wrapper solutions needed for Py 2.
Thanks, that will give people some pointers for Python 3. We need
folks to upv
Guido van Rossum added the comment:
On Wed, Dec 4, 2013 at 10:25 PM, Terry J. Reedy wrote:
> I am familiar with running Sphinx on .rst files, but not on docstrings.
> It looks like the docstrings use .rst markup. (Is this allowed in the
> stdlib?)
I'm not sure if it is allo
Guido van Rossum added the comment:
Thanks Christian, this is almost right. I'm uploading a patch that covers all
bases:
- Works on Python 3.3 (TEST_HOME_DIR isn't defined there)
- Works on older Python 3.4 versions (check_hostname may not exist)
- Works on latest Python 3
Changes by Guido van Rossum :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue19901>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Well, registration is a very common pattern and you can't really require
everyone to use an inferior word just because ABCMeta uses it.
There's a simple work-around:
abc.ABCMeta.register(selectors.BaseS
Guido van Rossum added the comment:
Here's a tentative change to selectors.py that ignores the OSError in various
unregister() methods (but not in register()).
--
keywords: +patch
Added file: http://bugs.python.org/file32999/unregister
Guido van Rossum added the comment:
With the latest (revision 1605eda93392) I get four failures on OS X. Three are
like this (in all three selector types -- kqueue, select, poll):
==
ERROR: test_create_ssl_connection
Guido van Rossum added the comment:
It was never about signature detection for me -- what gave you that idea? I
simply want to have the option to put individual docstrings on the properties
generated by namedtuple.
--
___
Python tracker
<h
Guido van Rossum added the comment:
That's fixed by revision ec1e7fc9b5a4.
Christian, can this bug be closed now, or is there more?
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
This is done AFAICT.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
Ping? Charle-François, what do you think of my patch to ignore OSError in
unregister()?
--
assignee: docs@python -> neologix
___
Python tracker
<http://bugs.python.org/issu
New submission from Guido van Rossum:
compile() takes a string, bytes or AST as the "source" argument. The bytes
option are not documented except in the error message you get when you pass
something else. The AST option is in the library docs but not in the function
Changes by Guido van Rossum :
--
keywords: +easy
priority: normal -> low
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue19910>
___
__
Guido van Rossum added the comment:
Here's a new patch. Note that it includes a commented-out test that
demonstrates the failure if the socket object itself is closed (rather than
just its FD).
--
Added file: http://bugs.python.org/file33013/unregister2
Guido van Rossum added the comment:
Here's a variant that documents the ValueError issue and omits the
commented-out test.
--
Added file: http://bugs.python.org/file33014/unregister3.diff
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Here's an attempt at fixing the ValueError.
I don't like the exhaustive search much, but the alternative is to maintain an
inverse dict. What do you think?
--
Added file: http://bugs.python.org/file33015/unregi
Guido van Rossum added the comment:
OK, I'll make a new patch (maybe Monday). I want to be a little more careful
with the exhaustive search, I think it should not be attempted if we see
KeyError or AttributeError (those should not be dynamic).
I tested for the epoll error on Ubunt
Guido van Rossum added the comment:
So I think this is why epoll doesn't raise OSError:
http://hg.python.org/cpython/file/44dacafdd48a/Modules/selectmodule.c#l1335
The Python wrapper explicitly checks for EBADF and turns this into a non-error
r
Guido van Rossum added the comment:
Well, I take it back. If you close the FD and then reuse it, you get ENOENT,
which is not caught. So we still need the try/except OSError.
I am going to experiment with a PollSelector as well.
--
___
Python
Guido van Rossum added the comment:
PollSelector doesn't seem to have this behavior.
--
___
Python tracker
<http://bugs.python.org/issue19876>
___
___
Pytho
Guido van Rossum added the comment:
New patch. Please review.
The error handling is a bit complicated but I like to be careful in which
errors I catch.
--
Added file: http://bugs.python.org/file33020/unregister5.diff
___
Python tracker
<h
Guido van Rossum added the comment:
Sorry, here's another version. It keeps the original _fileobj_to_fd function
and wraps it with a method that does the exhaustive search.
--
Added file: http://bugs.python.org/file33025/unregister6.diff
___
P
Guido van Rossum added the comment:
I think I got the closing sorted out now, and through reordering the dup2()
calls are actually needed.
--
Added file: http://bugs.python.org/file33028/unregister7.diff
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
OK, here's another try. I ran what you suggested for all three tests I added
and they are all clean. I realized that every single call to socketpair() is
followed by two addCleanup calls, so I added a make_socketpair() helper method
that does
Guido van Rossum added the comment:
Is this worthy of a Misc/NEWS entry?
--
___
Python tracker
<http://bugs.python.org/issue19876>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Done.
--
assignee: neologix -> gvanrossum
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.pyt
Guido van Rossum added the comment:
I don't think we should be more selective about the errno values, the try block
is narrow enough (just one syscall) and we really don't know what the kernel
will do on different platforms. And what would we do about it anyway?
I will look into t
Guido van Rossum added the comment:
Then here's a hopeful fix for the Windows situation that relies on the
socketpair() operation reusing FDs from the lowest value. I'm adding asserts to
check that this is actually the case. (These are actual assert statements to
indicate tha
Guido van Rossum added the comment:
Patch looks good. Go ahead.
--
nosy: +Guido.van.Rossum
___
Python tracker
<http://bugs.python.org/issue21163>
___
___
Pytho
Guido van Rossum added the comment:
Class doctests are already supported separately, see
https://docs.python.org/3/library/doctest.html#which-docstrings-are-examined
--
nosy: +Guido.van.Rossum
___
Python tracker
<http://bugs.python.org/issue21
Guido van Rossum added the comment:
On Sun, Jul 13, 2014 at 7:00 PM, Nick Coghlan
wrote:
>
> Nick Coghlan added the comment:
>
> On 13 Jul 2014 18:39, "Marc-Andre Lemburg" wrote:
> >
> >
> > Marc-Andre Lemburg added the comment:
> >
> > Why
Guido van Rossum added the comment:
In this case I think there is no legal issue. All you have to do is take the
link from the patch and come up with a fresh patch of your own.
(However I think Georg's objection against a Linux-specific link stands. You
can probably find a POSIX link
Guido van Rossum added the comment:
I don't see the value in this complication. Please close as won't fix.
--
nosy: +Guido.van.Rossum
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
(Had to switch identities to close it.)
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
I did my meditation. I now understand the race:
- main thread is blocked in select() (or poll() etc.)
- C-level signal handler is called in thread B and writes a byte to self-pipe
- kernel immediately switches threads
- main thread wakes up, reads data from
Guido van Rossum added the comment:
The more esoteric system calls you use the more you end up debugging it on
esoteric platforms. :-(
On Thu, Jul 17, 2014 at 9:17 AM, STINNER Victor
wrote:
>
> STINNER Victor added the comment:
>
> > I don't know if it can be useful, b
Guido van Rossum added the comment:
Not in my wildest dreams could I have expected that that claim would still be
in the docs 20 years later. :-) Please get rid of it.
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
I don't know much about how sockets are implemented on Windows; is there a
guarantee that the space of possible socket fds doesn't overlap the space of
possible stream fds?
--
___
Python trac
Guido van Rossum added the comment:
Perhaps the API should take a socket object on Windows to avoid any confusion?
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
So perhaps an int or a socket?
--
___
Python tracker
<http://bugs.python.org/issue22018>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
My worry is that somehow a program has a fd that refers to both a file and a
socket. But I agree that changing the API is not a great option either.
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
This does appear to be a bug. Please research the C code that originates the
error message -- there's probably a simple logic mistake.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I find Charles' argument pretty convincing. The whole point of this API is to
have another thing you can add to the selector to deal with a race condition.
You then pass this thing's fileno() to signal.set_wakeup_fd(). That should be
totally port
Guido van Rossum added the comment:
I think if it's not a socket (or a closed one) it should raise ValueError or
perhaps OSError -- TypeError would mean that it's not an int.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
PEP 3156 is clear: "The socket argument has to be a non-blocking socket." So
it's a documentation issue.
--
___
Python tracker
<http://bugs.pyt
Guido van Rossum added the comment:
Antoine, what do you want me to do? I think improving __repr__ of a socket
sounds fine for some Python 2.7 bugfix release.
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
I don't think it's against policy. Do doctests even work for objects that have
an address as part of their repr()?
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
OK, I'm convinced. Sorry Victor.
On Saturday, July 26, 2014, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> See for example test_generators, test_genexps, test_xml_etree or
> ctypes.test.test_objects.
>
>
Guido van Rossum added the comment:
Good point. Asyncio definitely should not share event loops across forked
processes. However, I don't like the dependency on multiprocessing (even
though it's in the stdlib) -- can't the policy just use os.getpid()?
Also, I've got a fe
Guido van Rossum added the comment:
I think there should still be a new unittest -- we're adding a behavior we're
promising, so we should test it.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
Oh the joy of duck typing. :-(
If anything, set should be made to behave more like MutableSet by allowing
arbitrary iterable arguments to the __i**__ methods.
I do not think it is a good idea to add all of the named versions of the
methods to the ABC (even
Guido van Rossum added the comment:
Was this always so or did it recently start? Victor has made a ton of changes.
Anyway, I imagine there may be some objects stuck in cycles and the collection
may not happen until a random later time, and the tests do timing-specific
stuff so the number of
Guido van Rossum added the comment:
Is this at all related to the use of GNU readline?
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue17
Guido van Rossum added the comment:
I propose not to mess with GNU readline. But that doesn't mean we can't try to
fix this issue by detecting that sys.stdin has changed and use it if it isn't
referring to the original process stdin. It will be tricky however to make
sure
Guido van Rossum added the comment:
sys.stdin.readline() never delegates to GNU readline. The REPL calls GNU
readline directly. There's clearly some condition that determines whether to
call GNU readline or sys.stdin.readline, but it may not correspond to what you
want (e.g. it may
Guido van Rossum added the comment:
Agreed with Raymond. The return type of copy() for ABCs feels problematic.
MutableMapping doesn't have it either.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Hm. I think there are two different situations.
One is where the app creates a socket (or other I/O thingie), passes it off to
asyncio, and then asyncio owns it. This is the case for pipes and also for the
optional sock parameter for create_connection
Guido van Rossum added the comment:
Thanks for reporting a doc bug!
The code should use asyncio.async() instead of loop.create_task().
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
I honestly don't know; ask Benjamin. :-)
Personally, I'd say that ship has sailed.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
asyncio has an explicit exemption from the general rule that bugfixes
should not add new features. This is because of the "provisional" status of
the PEP. We'll stop doing this once 3.5 is out.
I don't know what's up with the onl
Guido van Rossum added the comment:
You need to learn when to give up. :-)
I wasn't the one who added a copy() method to other containers. I personally
despise almost all uses of "copying" (including the entire copy module, both
deep and shallow copy functionality). I much
Guido van Rossum added the comment:
Looks good!
On Sat, Aug 2, 2014 at 4:19 AM, STINNER Victor
wrote:
>
> STINNER Victor added the comment:
>
> Here is a a patch which replaces loop.create_task(coro) with
> asyncio.async(coro), mention that asyncio.async() can be used t
Guido van Rossum added the comment:
It's clear that dict.values() shouldn't be hashable -- using the identity is
plain wrong here. But shouldn't the fix be to implement rich comparisons for
dict.values()?
I think just a a.keys() == set(a.keys()), a.values() should be =
Guido van Rossum added the comment:
Oh. Yeah. Then I think there's nothing to do.
--
___
Python tracker
<http://bugs.python.org/issue22192>
___
___
Pytho
Guido van Rossum added the comment:
I'm all in favor of documenting that you must keep a strong reference to a
task that you want to keep alive. I'm not keen on automatically keep all
tasks alive, that might exacerbate leaks (which are by definition hard to
find) in existing program
Guido van Rossum added the comment:
So you are changing your mind and withdrawing your option #1.
I don't have the time to really dig deeply into the example app and what's
going on. If you want to help, you can try to come up with a patch (and it
should have good unit tests).
Guido van Rossum added the comment:
While I understand your problem, I really do not want to enable recursive event
loops. While they are popular in some event systems (IIRC libevent relies
heavily on the concept), I have heard some strong objections from other parts,
and I am trying to keep
Guido van Rossum added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue22063>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Good point. I think I had forgotten how BufferedIOBase worked... :-(
I believe we should just change this -- Victor, what do you think?
--
___
Python tracker
<http://bugs.python.org/issue22
Guido van Rossum added the comment:
Oh, I just checked the docs. io.BufferedIOBase.read(size) is more complicated
than I (or Jack) thought -- it can return a short read if the underlying raw
stream is "interactive". The subclass io.BufferedReader uses the definition
preferred by Ja
Guido van Rossum added the comment:
Also, I'm not too fond of the read1()/read() dichotomy. I was pretty much
forced into it because Python 2 streams implemented read() using the libc
fread() function, which has this behavior -- but in general I find the UNIX
read() syscall more conve
Guido van Rossum added the comment:
Loet's just spruce up the docs a bit. (Also maybe fix that awkward sentence in
the BufferedReader docs.)
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Yeah, that too should just be documented. The read-until-eof behavior is
quite entrenched (in fact I had a hard time finding example read calls with
a size parameter :-). Specifying a huge buffer size in order to read until
EOF isn't really a common pra
Guido van Rossum added the comment:
Looks good.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue21527>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Oooh, yes. The colon in a slice should be treated as a binary operator, with
equal space before and after.
I think we can add this (as a new bullet following the bullet "Immediately
before a comma, semicolon, or colon"):
- However, the colon
Guido van Rossum added the comment:
Just like for other binary operators (except for the ones mentioned as always
needing spaces), the spaces around ":" are neither mandatory nor objectionable.
I am not making up a new rule, this is how I've always thought -- we just have
to m
Guido van Rossum added the comment:
Committed rev e98737176f1d.
If there's more discussion I can add more.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Does anyone care that there is now one bullet in the "avoid spaces ..." list
that isn't strictly about avoiding spaces?
--
___
Python tracker
<http://bugs.pyt
Guido van Rossum added the comment:
Thanks!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22346>
___
___
Guido van Rossum added the comment:
- This bug should discuss doc updates, not question the rules.
- The rules have evolved over time and the docs stayed behind.
- We should definitely update the 2.7 docs as well as the 3.4 and 3.5 (in
development) docs. The 2.7 docs need to be different
Guido van Rossum added the comment:
That's a pretty new feature. Someone probably forgot to clean up all the
places where it was documented.
On Sat, Sep 6, 2014 at 4:18 PM, Martin Panter
wrote:
>
> Martin Panter added the comment:
>
> The point about “a != b” deferring to “no
Guido van Rossum added the comment:
Do you have a specific sentence or paragraph in mind that could be added?
Be aware help() just shows what's in the docstring, which is typically
abbreviated. The full docs are on docs.python.org. Can you find what you need
there?
--
Guido van Rossum added the comment:
It looks like this feature request tries to change an existing (ancient) module
into something it isn't. At the very least can you point to a spec for the
syntax of "POSIX" config files? I always thought they were essentially shell
scripts,
Guido van Rossum added the comment:
Then let's close this issue.
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
1. Great that you're trying to implement this!
2. But I really recommend that you try to structure this as a 3rd party module
first rather than patching the Python distribution -- it's much harder to get
accepted. Or as a pure-Python patch
4201 - 4300 of 5563 matches
Mail list logo
