Guido van Rossum added the comment:
I agree with Yuri and I approve of the patch.
--
___
Python tracker
<http://bugs.python.org/issue21209>
___
___
Python-bug
Guido van Rossum added the comment:
My bad. But I think docstrings should NOT be just copies of the separate
docs.
On Apr 16, 2014 9:01 AM, "Yury Selivanov" wrote:
>
> Yury Selivanov added the comment:
>
> I had plans to copy some documentation from python docs to asyn
Guido van Rossum added the comment:
IMO the comment is too aggressive. I want the workaround to stay in the
codebase so CPython asyncio ans Tulip asyncio (== upstream) don't diverge.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Hm, I've never hear from someone who did this before. It might be easy to fix,
but it would be ugly too (every EventLoop method would have to check this), and
not very useful (you'll only make this mistake once in your life).
How much time did
Guido van Rossum added the comment:
Can you also think about how this would be wrapped in asyncio?
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue17
Guido van Rossum added the comment:
Looks like there is a bug in CoroWrapper -- when the assert in __init__ fails,
__del__ gets called imediately after and that triggers this traceback.
However I'm not sure what causes the assert to fail -- it looks like this is
coming from sleep(),
Guido van Rossum added the comment:
Oh wait, it looks like the assert failed because KeyboardInterrupt hit right at
that point. I ran the program a few times and when I hit ^C I get a traceback
at a different point in the code each time. This is as expected. You must have
hit the rare case
Guido van Rossum added the comment:
Sorry, should have let someone review it. I'm a bit out of practice. :-)
But in this case I think three-arg getattr() is better; less code, less
indentation, and the final question (is the frame not None?) must still be
Guido van Rossum added the comment:
I considered this, and decided against unifying the two TimeoutErrors.
First the builtin TimeoutError is specifically a subclass of OSError
representing the case where errno is ETIMEDOUT. But asyncio.TimeoutError means
nothing of the sort.
Second, the
Guido van Rossum added the comment:
Confirmed too (OSX 10.9 again, CPython 3.4 or 3.5; but it doesn't crash with
CPython 3.3). There is no C code in asyncio, so I'm not sure how asyncio can be
directly responsible for this crash. Probably some of the GC improvements have
an edge ca
Guido van Rossum added the comment:
So should we just add
if (!gc)
break;
at the top of the for-loop body? That prevents the crash for me. But why is
it needed?
--
___
Python tracker
<http://bugs.python.org/issue21
Guido van Rossum added the comment:
The second error is easy to explain and fix: it's a race condition between the
OS thread used to call getaddrinfo() and the main thread. The method
_write_to_self() in selector_events.py is hopelessly naive. It should probably
become something like
Guido van Rossum added the comment:
I'm a little closer to understanding the first (more common) traceback. I can
repro it by running your demo program in a loop -- it may take a while but
occasionally I do get the same InvalidStateError.
This appears to be an example of the pr
Guido van Rossum added the comment:
Thanks Tim! I'm not sure who should review the patch, but it's not me. :-) I've
verified that the patch stops the example program from segfaulting on OSX, and
I assume you've verified it on Windows -- that's good enough for me. We
Guido van Rossum added the comment:
Thanks for the report, that should be easy to fix.
Regarding PTYs, we're aware:
https://code.google.com/p/tulip/issues/detail?id=147
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg219253
___
Python tracker
<http://bugs.python.org/issue1683368>
___
___
Python-bug
Guido van Rossum added the comment:
If you don't know enough about the base class you shouldn't be subclassing it.
In this particular case you should be overriding __init__, not __new__.
--
___
Python tracker
<http://bugs.python.org
Guido van Rossum added the comment:
Sorry, I didn't realize why __new__ was being used. But what Jason's code is
doing isn't any cleaner than monkey-patching.
--
___
Python tracker
<http://bugs.pytho
Guido van Rossum added the comment:
Good idea.
--
___
Python tracker
<http://bugs.python.org/issue21443>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Hrm. I've always thought that the key point of cooperative MI was the term
*cooperative*. Consider a regular (non-constructor) method. You must have a
common base class that defines this method, and *that* method shouldn't be
calling the su
Guido van Rossum added the comment:
FWIW while the Tulip changes should indeed go into the Tulip repo first, the
rest should be committed to the CPython 3.5 tree first. Then I'll commit the
Tulip changes, first to the Tulip repo, then to the CPython 3.4 branch (yes!)
and then merge that
Guido van Rossum added the comment:
I'm not sure. Running out of file descriptors is really not something a
library can handle on its own -- this needs to be kicked back to the app to
handle. E.g. by pacing itself, or closing some connections, or changing the
system limit... The library r
Guido van Rossum added the comment:
Maybe see Tulip issue 168? That test was added to support that. Maybe the fix
doesn't work for this platform?
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20475>
___
___
Python-bugs-
Changes by Guido van Rossum :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21180>
___
___
Python-bugs-
Guido van Rossum added the comment:
I'm sorry, but I find this way too intrusive, and a little risky too (I'm not
sure how to verify even that the new parser accepts exactly the same set of
programs as the old version).
I would much prefer a solution to this particular issue along
Guido van Rossum added the comment:
I don't want the O(1) property explicitly denounced in the reference manual.
It's fine if the manual is silent on this -- maybe someone can prove that it
isn't a problem based on benchmarks of an alternate implementation, but until
then
Guido van Rossum added the comment:
I don't want the 3.4 and 3.5 versions of asyncio to be different. You should
just copy the 3.5 code back into the 3.4 tree. A new method is fine. Really.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Yes, something like that. Don't change the grammar, just hack the heck out of
the error message.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Nice! I put it through a bit of a torture test and found a few odd corners.
E.g. it doesn't catch this:
if 1: print 42
nor this:
if 1:
print 42
nor this:
def foo():
print 42
I also notice that if the printed expression s
Guido van Rossum added the comment:
I also found some amusing false positives (syntax errors that weren't valid
print statements in Python 2):
print [/
print /
print )# but not "print)" !
print]
None of these matter though. Perhaps more concerning is how
Guido van Rossum added the comment:
I agree with Raymond -- this is a common pattern but there are many variations
that are hard to catch in a single implementation. E.g. at Dropbox we have a
decorator like this that lets you specify an identifier for the block you name,
and which logs the
Guido van Rossum added the comment:
FWIW, I definitely don't think this belongs in the timeit module, unless you
are going to treat that module as a "namespace" package, which I don't like
much (though in Java I think it's a pretty common pattern). If we have to ha
Guido van Rossum added the comment:
The patch looks fine to me.
--
___
Python tracker
<http://bugs.python.org/issue21723>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
There used to be some places in the C code that raise MemoryError to
indicate that some parameter indicating a desired result size is out
of range, i.e. before even trying to allocate anything. I can't
confirm any, but these should probably be replaced
Guido van Rossum added the comment:
Well, you can fix that, right? Just add a new function with a better
signature and use that for one of the two scenarios.
(I think third scenario might be when realloc fails -- IIRC it
doesn't guarantee that the original pointer is still valid e
Changes by Guido van Rossum :
--
nosy: -gvanrossum, python-dev
___
Python tracker
<http://bugs.python.org/issue15990>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Thanks! I will try it out shortly.
--
___
Python tracker
<http://bugs.python.org/issue16596>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
It looks like xdegaye's patch breaks 'n' when not debugging a generator.
--
___
Python tracker
<http://bugs.pyt
Guido van Rossum added the comment:
I recommend documenting it.
On Monday, December 31, 2012, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Indeed. In any case, if this idiom is widely used, we can't hide this
> parameter and should document it (and p
Guido van Rossum added the comment:
I think this is a great idea. But let's wait until Tulip is a bit further
along; the design of its Pollster might still change as PEP 3156 gets more
review and feedback. According to PEP 429 the first beta of 3.4 won't go out
until November
Guido van Rossum added the comment:
Would it make sense to explore this in the Tulip project first? It could be a
new module, tulip/selector.py. (Heck, I'll even give you commit privileges in
Tulip.)
Also, I've heard (but don't know from personal experience) that Jython suppo
Guido van Rossum added the comment:
Giampaolo, there are many details in the Tornado and pyftpdlib I/O loops that
may or may not be intentional. I wrote the Tulip pollster from scratch but am
looking to merge in relevant knowledge and features from Tornado, Twisted and
pyftpdlib. AFAIK the
Guido van Rossum added the comment:
I think that this needs extensive tests that verify the behavior of many end
cases, including under duress (e.g. when there are too many connections for the
kernel to handle). That would seem the only way to make sure that the code is
reliable across
Guido van Rossum added the comment:
I am trying to use this module in Tulip instead of its pollster implementation,
and am running into a problem. Tulip defines separate
add_reader()/add_writer() methods, which call to the pollster's
register_reader()/register_writer(), respectively.
Guido van Rossum added the comment:
This seems okay. I am attaching the changes I had to make to Tulip to support
this. However, two Tulip tests are now failing:
- tulip.events_test.PollEventLoopTests.testCreateSslTransport fails with
spurious file descriptors returned by poll() that aren&#
Guido van Rossum added the comment:
Maybe I should explain the need for SELECT_CONNECT more. This is necessary so
that on Windows the PollSelector can use WSAPoll(). The reason is that for
async connect() calls, WSAPoll() doesn't return the FD as writable, just as
having an exceptio
Guido van Rossum added the comment:
(Adding Richard Oudkerk to the nosy list as I am pleading here for support of
WSAPoll(), see last few messages.)
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue16
Guido van Rossum added the comment:
There's a bug in the kqueue selector. The following code in your patch has
'fd' instead of 'key.fd', twice:
if events & SELECT_IN:
kev = kevent(key.fd, KQ_FILTER_READ, KQ_EV_ADD)
sel
Guido van Rossum added the comment:
Ok, I fixed test_writer_callback() in the tulip repo.
Indeed the error I reported first is gone now.
I logged the value of kev on failure, and got this output:
ERROR:root:kev =
Traceback (most recent call last):
File "/Users/guido/tulip/
Guido van Rossum added the comment:
Figured it out. KqueueSelector was missing the unregister() implementation.
Here it is:
def unregister(self, fileobj):
key = super().unregister(fileobj)
mask = 0
if key.events & SELECT_IN:
Guido van Rossum added the comment:
Whoops, the unregister() function needs to return key.
--
___
Python tracker
<http://bugs.python.org/issue16853>
___
___
Pytho
Guido van Rossum added the comment:
That ought to be added to the docstrings for register()/unregister() in
_BaseSelector.
--
___
Python tracker
<http://bugs.python.org/issue16
Guido van Rossum added the comment:
A patch for making register()/unregister() return the key.
--
Added file: http://bugs.python.org/file28638/return_key_fix.diff
___
Python tracker
<http://bugs.python.org/issue16
Guido van Rossum added the comment:
Please consider my patches instead; it seems our patches crossed. Merging is
now difficult because I already submitted my version to Tulip. Your version
still has a bug: it uses select.kevent(...) twice, where it should just use
kevent(...). Also my
Guido van Rossum added the comment:
- How shall we go forward? I've made a variety of small changes to the Tulip
version (selector.py) now. Can you work those into a fresh unified patch for
CPython 3.4?
- I tried making a single combined kqueue call in register(), and it caused the
Guido van Rossum added the comment:
On Wed, Jan 9, 2013 at 12:47 PM, Charles-François Natali
wrote:
>> - How shall we go forward? I've made a variety of small changes to the
>> Tulip version (selector.py) now. Can you work those into a fresh unified
>> patch for CPyt
Guido van Rossum added the comment:
I've fixed the signal handling issue. Please check Tulip revision
1c4db3d1a688:
http://code.google.com/p/tulip/source/detail?r=1c4db3d1a68874dc22c84f9c1c376c5371037f09
--
___
Python tracker
Guido van Rossum added the comment:
And the next Tulip rev renames Key to SelectorKey.
--
___
Python tracker
<http://bugs.python.org/issue16853>
___
___
Python-bug
Guido van Rossum added the comment:
I am sticking with my opinion from before: the code should be fixed. It
doesn't look like assignment to me.
I am fine with making this a "feature" only fixed in 3.4. (You can even fix
the docs in 3.3 as long as you fix them back for 3.4.)
Guido van Rossum added the comment:
Just a note of support for Richard -- having I/O use the native APIs directly
rather than via emulation or other wrappers is a good idea, because the
emulations / wrappers usually add restrictions that are not present in the
native API. This is also the
New submission from Guido van Rossum:
On Windows I get an immediate crash with the following code:
import signal
signal.set_wakeup_fd(400)
I think there's a range check missing somewhere.
(I found this because I was passing a socket's fileno() -- my bug, but
shoul
Guido van Rossum added the comment:
This works well enough (tested in old version of Tulip), right? What's holding
it up?
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Oh, it needs a new patch -- the patch fails to apply in the 3.4
(default) branch.
--
___
Python tracker
<http://bugs.python.org/issue16
Guido van Rossum added the comment:
Here's a new version of the patch. (Will test on Windows next.)
--
Added file: http://bugs.python.org/file28799/runtime_wsapoll.patch
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
That compiles (after hacking the line endings). One Tulip test fails,
PollEventLooptests.testSockClientFail. But that's probably because the
PollSelector class hasn't been adjusted for Windows yet (need to dig this out
of the Pollster cod
Guido van Rossum added the comment:
That compiles (after hacking the line endings). One Tulip test fails,
PollEventLooptests.testSockClientFail. But that's probably because the
PollSelector class hasn't been adjusted for Windows yet (need to dig this out
of the Pollster cod
Guido van Rossum added the comment:
Ow. How painful. I'll leave this for you to do. Note that this also
requires separating EVENT_WRITE from EVENT_CONNECT -- I am looking
into this now, but I am not sure how far I will get with this.
--
___
P
Guido van Rossum added the comment:
(FWIW, I've got the EVENT_CONNECT separation done.)
--
___
Python tracker
<http://bugs.python.org/issue16507>
___
___
Guido van Rossum added the comment:
This is a very good question to which I have no good answer. If it weren't for
this, we could probably do away with the distinction between add_writer and
add_connector, and a lot of code could be simpler. (Or is that distinction
also needed for
Guido van Rossum added the comment:
Thanks -- I am now close to rejecting the WSAPoll() patch, and even
closer to rejecting its use for Tulip on Windows. That would in turn
mean that we should kill add/remove_connector() and also the
EVENT_CONNECT flag in selector.py. Anyone not in favor please
Guido van Rossum added the comment:
I'd like to keep the essay around as a permalink, but I don't object against
putting some red text at the top warning people is is horribly out of date, and
linking to a better tutorial.
--
___
Pyth
Guido van Rossum added the comment:
Short reads/writes are orthogonal to EAGAIN. All the mainline code treats
readiness as a hint only, so tests should too.
--Guido van Rossum (sent from Android phone)
--
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Twisted still would like to see this.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue3982>
___
___
Pytho
Guido van Rossum added the comment:
Would it be easier if the only format codes/types supported were
bytes, int and float?
--
___
Python tracker
<http://bugs.python.org/issue3
Guido van Rossum added the comment:
Twisted would really like to see this bug fixed.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue12
Guido van Rossum added the comment:
Honestly, what Twisted is mostly after is a way to write code that
works both with Python 2 and Python 3. They need the types I mentioned
only (bytes, int, float) and not too many advanced features of
.format() -- but if it's not called .format() or i
Guido van Rossum added the comment:
Agreed, it does not sound very useful to support WSAPoll(), neither in
selector.py (which is intended to eventually be turned into
stdlib/select.py) nor in PEP 3156. And then, what other use is there
for it, really
Guido van Rossum added the comment:
Does anyone who was on this bug previously (e.g. the original author
or the reviewers) know what was holding up the patch? Does it need
more review? More tests? Is there any reason to reject fixing this at
all? (I hope not.) As far as replacing the whole thing
Guido van Rossum added the comment:
Thank you very much Senthil!
--
___
Python tracker
<http://bugs.python.org/issue12411>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Well, msg171804 makes it a much bigger project than the feature that Twisted
actually needs. Quoting:
* The default formatting should not use str(), but buffer protocol.
Fine.
* There is no place for floating point.
Actually they do need it -- and it&#
Guido van Rossum added the comment:
I don't believe it either. I find join consistently faster than format:
python2.7 -m timeit -s 'x = [b"x"*1000']*10 'b"".join(x)'
100 loops, best of 3: 0.686 usec per loop
python2.7 -m timeit -s 'x = b&
Guido van Rossum added the comment:
Remember, the only reason to add this would be to enable writing code
that works in both 2.7 and 3.4. So it has to be called .format() and
it has to format numbers as decimal strings by default.
--
___
Python
Guido van Rossum added the comment:
Can someone review Thomas's patch? It's nearly a year old... I just
discovered this same issue.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.
New submission from Guido van Rossum:
The profile module exports convenience functions for run() and runctx(), which
wrap the corresponding methods of the Profile object. But perhaps the most
useful method, runcall(), is not wrapped. :-(
--
messages: 181403
nosy: gvanrossum
priority
Guido van Rossum added the comment:
Eric, you could also check it in with your own changes added.
How far can we backport docs?
--
___
Python tracker
<http://bugs.python.org/issue6
Guido van Rossum added the comment:
While we're on profile convenience features, how about adding two context
managers:
- one that just profiles a block and prints the profile (or dumps the data to a
file)
- one that takes a Profile instance and enables profiling to that instance
E.
New submission from Guido van Rossum:
I'm trying to speed up a web template engine and I find that the code needs to
do a lot of string replacements of this form:
name = name.replace('_', '-')
Characteristics of the data: the names are relatively short (1-10 char
Guido van Rossum added the comment:
Hm, you seem to be right. Changing the bug title.
So, can we speed up method lookup? It's a shame that I have to start promoting
this ugly idiom. There's a similar issue where s[:5]=='abcde' is faster than
s.startswith('abcde'
Guido van Rossum added the comment:
Great to see some action. Would there be a problem in backporting this? It's
not a new feature after all...
--
stage: patch review ->
___
Python tracker
<http://bugs.python.org
Guido van Rossum added the comment:
Antoine, what about the decorator? I've come across a few use cases.
--Guido van Rossum (sent from Android phone)
On Feb 10, 2013 10:14 AM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
>
> +1 for runcal
Guido van Rossum added the comment:
Sure, I will comment on that issue.
--
___
Python tracker
<http://bugs.python.org/issue17130>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Brief comments:
- Please don't call it profile -- we already have a module by that name.
- Please make it so that both the decorator and context manager can specify a
file where to dump the raw data -- basically it needs to have the same
functionali
Guido van Rossum added the comment:
If I quickly want to profile one function, with the decorator I have to
insert a with-statement in its body and mess with the indentation of the
entire body. With a decorator it's just a one-line inse
Guido van Rossum added the comment:
What's the status of Argument Clinic? Won't that make this obsolete?
--Guido van Rossum (sent from Android phone)
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
Interesting issue. ISTM that closing the FD before unregistering it is a
programmer's mistake that shouldn't pass silently. And closing it in a
separate thread while the selector is active sounds like an even bigger bug.
Could we report an new
Guido van Rossum added the comment:
> The problem is that for epoll (and kqueue I think) the FD is
> automagically removed from the backend, which means that we won't get
> any notification for this FD, hence we're unable to report it as
> closed.
That makes it sound l
Guido van Rossum added the comment:
FWIW, using class attributes to ensure __del__ does not hit AttributeError when
__init__ failed is more idiomatic than using three-argument getattr().
The reason: in general it is possible that __del__ calls almost any other
method on a class (e.g. for a
New submission from Guido van Rossum:
Check out
http://stackoverflow.com/questions/9327597/python-get-does-not-evaluate-to-true-even-though-there-is-an-object
It turns out a cgi.FieldStorage object may consider itself False even when it
has data. This happens when the initialization
Guido van Rossum added the comment:
PS. Simple repro:
import cgi; bool(cgi.FieldStorage('logo', u'tux.png'))
This reveals it's been fixed in Python 3 -- it raises TypeError there as it
should. (But __nonzero__ should be deleted, and if someone adds __bool__ they
s
3901 - 4000 of 5563 matches
Mail list logo
