Guido van Rossum added the comment:
Actually I expect that if you share an event loop across different processes
via form, everything's a mess -- whenever a FD becomes ready, won't both the
parent and the child be woken up? Then both would attempt to read from it.
One would pr
Guido van Rossum added the comment:
Wow. This is interesting. I thought that absolute URL support was only for
proxies, but the spec you quote says clearly it should be supported as a
transition towards always specifying the full URL. I guess they want to get rid
of the Host: header?
In any
Guido van Rossum added the comment:
But who says this isn't intended? I don't know why it was done this way, but
the following reasoning might apply: we want to have a stable API for
unpickling compiled regexps, but we want to be able to evolve the re.compile()
API. Just the
Guido van Rossum added the comment:
OK. Trying to understand the patch, there seem to be three parts to it:
(a) Changes to CPython to add a new flag to the exec/eval flags argument that
sets the GENERATOR flag in the resulting code object. This seems the most
fundamental, but it also feels
Guido van Rossum added the comment:
That sounds about right -- it's a doc issue. Let me propose a paragraph:
"""
NOTE: It is not safe to share an asyncio event loop between processes that are
related by os.fork(). If an event loop exists in a process, and that process
Guido van Rossum added the comment:
There's a sage piece of advice somewhere in the developer docs. "Know when to
give up."
I think you need to write a PEP trying to argue that supporting "yield from" in
the REPL is essential to a large category of users, so you ca
Guido van Rossum added the comment:
I'm sorry you feel that way. I hope one day you will understand the other side
of this kind of issue.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Love it!
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue22434>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Hm. Could you not use the new Enum class?
--
___
Python tracker
<http://bugs.python.org/issue22434>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
I think you are too casual in rejecting a standard approach over a custom
clever hack. Making the values enums gives them a standard interface that
goes beyond what you implemented, and just the fact that we can say "these
are IntEnum instances" s
Guido van Rossum added the comment:
Hi Joshua,
This is indeed a problem -- I just never expected that you would be having that
many events and and canceling the majority. I am sorry you had to debug this.
:-(
This was anticipated by the author of pyftpdlib (Giampaolo Roloda'), who
pro
Guido van Rossum added the comment:
We can merge the changes into 3.4 and 3.5 for you, it's just a simple copy
(the codebases are identical). However, the 3.4.2 release candidate is
apparently in 2 days, so I think you've missed that train already.
On Sat, Sep 20, 2014 at 9:02 AM, Jo
Guido van Rossum added the comment:
I'm not sure how that wait_for.py example from issue2116 relates to this issue
-- it seems to demonstrate the opposite problem (tasks are kept alive even
though they are cancelled).
Then again I admit I haven't looked deeply into the example (t
Guido van Rossum added the comment:
(Whoops meant to link to issue22448.)
--
___
Python tracker
<http://bugs.python.org/issue21163>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
By the way I just looked at wait_for.py; it has a bug where do_work() isn't
using yield-from with the sleep() call. But that may well be the issue you were
trying to debug, and this does not change my opinion about the issue -- I am
still looking forwa
Guido van Rossum added the comment:
I will try to review later tonight. One thing though:
> I tend to write my code with the thought that any non standard library
function can yield
That makes sense when using geven, but not when using asyncio or Trollius.
Nothing will make events run if
Guido van Rossum added the comment:
On Sat, Sep 20, 2014 at 3:38 PM, Joshua Moore-Oliva
wrote:
>
> Joshua Moore-Oliva added the comment:
>
> > I will try to review later tonight.
>
> Thanks!
>
> > That makes sense when using gevent, but not when using asyncio or
Guido van Rossum added the comment:
OK, then if you want to review Serhiy's original patch that would be great.
On Sun, Sep 21, 2014 at 5:12 AM, Antoine Pitrou
wrote:
>
> Antoine Pitrou added the comment:
>
> I think I agree with Serhiy. Augmenting the import dependencies fro
Guido van Rossum added the comment:
Raymond is correct. __base__ is closely tied to the C implementation. I think
it might be worth a mention, but with an explicit note that it is
CPython-specific. It is sometimes useful, e.g. when wondering why a certain
case of multiple inheritance is
Guido van Rossum added the comment:
I haven't seen the fix, but any place where an int is accepted but a long is
not, is a bug. The language has been on a long trip to making the two types
interchangeable and this seems one of the last remnants.
--
nosy: +gvanr
Guido van Rossum added the comment:
ISTM Nick meant that the exception that was raised can't cause arbitrary
code execution.
On Wednesday, October 1, 2014, Antony Lee wrote:
>
> Antony Lee added the comment:
>
> "it looks like all the avenues for arbitrary code executi
Guido van Rossum added the comment:
This is awesome news!
Since this is 3.5 only, I guess this means the end of my attempts to keep the
asyncio source code identical in the Tulip repo (from which I occasionally
create builds that work with Python 3.3) and in the 3.4 and 3.5 branches. I
Guido van Rossum added the comment:
Sadly, the optimistic code doesn't work on Windows. I think it may be because
the socketpair() helper at the top of test_selectors.py uses an extra socket
('l') and the handles just don't match up (I get a failure on assert
wr2.f
Guido van Rossum added the comment:
OK, closed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19876>
___
__
Guido van Rossum added the comment:
"I remembered we already run arbitrary code at roughly this point in the eval
loop, as we have to invoke __iter__ to get the exceptions to check when an
iterable is used in except clause."
Are you sure? IIRC the except clause only accept exce
Guido van Rossum added the comment:
I'm sorry, I really don't want the asyncio code for 3.3 and 3.4 to diverge just
yet. It would make keeping the two versions in sync just so much harder.
I'm happy with something that checks for the version and either adds the
__del__ meth
Guido van Rossum added the comment:
I agree with Mark and Stafan. Hex/oct/bin are only defined for integers.
__int__ is ambiguous -- it has the same problem as (int) in C in that it
applies to floats and then loses the fraction.
I think the problem with Ethan's ternary logic is th
Guido van Rossum added the comment:
I still think the problem is with your class design. You shouldn't want a hex
representation for a value that's not an integer.
For the difference between %x and hex() please open another issue (you might
want to track down the cause in the sourc
Guido van Rossum added the comment:
Not so fast. Currently, even in Python 3, '%d' % 3.14 returns '3'. "Fixing"
this will likely break a huge amount of code.
--
versions: +Python 3.5 -Python 3.4
___
Python tr
Guido van Rossum added the comment:
Also (the tracker email interface swallowed this):
> it is possible to want a type that can be used as an index or slice but that
> is still not a number
I'm sorry, but this requirement is absurd. An index *is* a number. You
have to make up yo
Guido van Rossum added the comment:
AFAIK %i and %d are the same.
--
___
Python tracker
<http://bugs.python.org/issue19995>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
So the new patch is fine, but I still think it's confusing that the _tb_logger
variable has a different type depending on the Python version. If you really
don't want to fix this, just go ahead and check in, it'
Guido van Rossum added the comment:
Looks good. I can fix that long line myself. :-)
--
___
Python tracker
<http://bugs.python.org/issue19967>
___
___
Python-bug
Guido van Rossum added the comment:
Eew. You're right. Sorry I didn't see this.
--
___
Python tracker
<http://bugs.python.org/issue19967>
___
___
Guido van Rossum added the comment:
Do you have an example of code that behaves differently with this patch? I
can't find any.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I propose that we fix the code. There are also some documented Transport
classes that aren't listed in __all__.
I'll submit the fix.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
The cycle will be cleaned up (and the message printed) when the
garbage collector runs next. Your demo doesn't do anything else, so it
never allocates memory, so it never runs gc.collect(). But that's only
because it's a toy program.
Maybe it
Guido van Rossum added the comment:
There's one issue left: the docs need to document BaseProtocol.
--
assignee: -> haypo
stage: -> needs patch
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
The only reasonable place to break the cycle seems to be the frame containing
the set_exception() call -- but that could be app code.
Looking again at what the patch actually does I think it is too big a hammer
anyway -- it would break debugging tools that
Guido van Rossum added the comment:
Victor, can you commit the fix (with my suggested improvement)?
--
___
Python tracker
<http://bugs.python.org/issue19
New submission from Guido van Rossum:
I was writing a new Tulip example (a cache client and server, not yet public)
and I noticed that when I interrupted the client with ^C I got a traceback
(expected) followed by a segfault (unexpected). This is on OSX 10.8 but I
don't think it is pla
Guido van Rossum added the comment:
Thanks for the quick fix guys! Sorry for the duplicate bug (probably a race
condition :-).
--
___
Python tracker
<http://bugs.python.org/issue20
New submission from Guido van Rossum:
A little birdie told me:
"""
Bug in Python subprocess doesn't allow to detect if
command executed through Windows system shell
exists.
If command doesn't exist, windows shell returns 9009
exit code (127 on Linux):
---[a.bat
Guido van Rossum added the comment:
I grepped for clinic in the source code and I have a hunch why this confusing:
each clinic-generated block has *three* marker comments, each containing
[clinic] or [clinic checksum: ...].
TBH I can't always tell on which side of the comment the gene
Guido van Rossum added the comment:
Yes. Then I suggest working on a patch before people get too deep into the
conversion project.
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
I use Emacs, so I have no idea what would help for Kate. I suppose Kate is
programmable? Maybe you can add some kind of filter for this purpose?
If e.g. binascii_a2b_uu_impl were moved to a different file, how would
binascii_a2b_uu call it without
Guido van Rossum added the comment:
And the stringlib situation confuses the hell out of me already.
--
___
Python tracker
<http://bugs.python.org/issue19
Guido van Rossum added the comment:
Then the separate file version looks much worse to me.
--
___
Python tracker
<http://bugs.python.org/issue19723>
___
___
Pytho
New submission from Guido van Rossum:
There's currently a deadlock in StreamReader.readexactly() -- if the requested
size is larger than the buffer limit for pause, the transport may be paused
with no way to unpause it.
See http://code.google.com/p/tulip/issues/detail?id=99 in the
Guido van Rossum added the comment:
I'd appreciate help writing a test. (Debugging this already set me back enough
hours.)
--
resolution: -> remind
___
Python tracker
<http://bugs.python.org
Guido van Rossum added the comment:
The new syntax is fine; I was only giving an example.
--
___
Python tracker
<http://bugs.python.org/issue19723>
___
___
Pytho
Guido van Rossum added the comment:
What part of the debug timing is more expensive than the select call itself?
--
___
Python tracker
<http://bugs.python.org/issue20
Guido van Rossum added the comment:
Can you check for the level of the logger? That would work for me.
--
___
Python tracker
<http://bugs.python.org/issue20
Guido van Rossum added the comment:
So you admit you just want to optimize prematurely?
--
___
Python tracker
<http://bugs.python.org/issue20275>
___
___
Pytho
Guido van Rossum added the comment:
I have definitely used this log message. It typically tells me that something
is responding too slow.
Regarding the microbench, please count and report how many times it actually
calls select().
--
___
Python
Guido van Rossum added the comment:
I like logger_is_enabled_for.patch.
If you want to add other debug features please propose something on the Tulip
tracker: http://code.google.com/p/tulip/issues/list .
--
___
Python tracker
<h
Guido van Rossum added the comment:
I really want to log the time every time if level == DEBUG and only if > 1 sec
for other levels, so maybe all you need to do is remove the comment? :-) (Or
maybe logger.isEnabledFor(logging.INFO) is faster than logger.log() when
nothing gets log
Guido van Rossum added the comment:
Now looking. Note that a few parts of the patch no longer cleanly apply:
hg import --no-c http://bugs.python.org/review/download/issue20189_10572.diff
applying http://bugs.python.org/review/download/issue20189_10572.diff
patching file Modules/_cursesmodule.c
Guido van Rossum added the comment:
I limited myself to the four files you mentioned, and they look totally fine.
Together with Nick's view you should have enough core review now, right?
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
You have convinced me.
--
___
Python tracker
<http://bugs.python.org/issue20326>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
I won't have time to fix this (and bardly to even review a fix) but this seems
a straightforward fix and you can go ahead without me -- maybe you can get
someone else with some asyncio experience to review your patch (e.g. Antoine or
V
Guido van Rossum added the comment:
I think you the caller was wrong to pass in [f, f] in the first place.
In asyncio, the argument is converted into a set before using it, but there's
still a bug if you pass it a list containing two references to the same
coroutine -- it gets wrapped i
Guido van Rossum added the comment:
I've lost some context, but perhaps we should have the notion of
"granularity" of the poll/select timeout (e.g. 1 msec), and consider
events that are in the future by less than that granularity as ready?
Then we can round the timeout down: if s
Guido van Rossum added the comment:
I don't have the energy to read all the debate here, but over on python-tulip
we continue to discuss this. Victor and I have currently agreed to drop the
math.ceil() calls from the event loop and instead simply consider any event
scheduled w
Guido van Rossum added the comment:
LGTM. But you also need to update Doc/library/concurrent.futures.rst
I see this as a bugfix so it's not necessary to get this in before the beta 3
release tonight.
I will work on an asyncio patch 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:
AFAICT the changes to selectmodule.c have been rolled back, both in the 3.3 and
the 3.4 (default) branches. That takes care of backwards compatibility. :-)
So what we're talking about is whether (a) the selectors module (new in 3.3)
should exp
Guido van Rossum added the comment:
Sorry, I suppose it needs to be backported to 3.3.
If someone wants to do that, please do (I'm afraid I'd mess up the merge).
--
resolution: fixed -> remind
status: closed -> open
___
Pytho
Guido van Rossum added the comment:
I'm fine with this refactoring. The upstream tulip/asyncio repo will keep its
own _overlapped for the purpose of supporting Python 3.3. (I'm not sure what
Victor wants to do with Trollius but probabl
Guido van Rossum added the comment:
I am trying to be conservative in changing existing Tulip APIs, but I hope to
get an exemption from Larry for the "convenience" process API that we are
currently adding in Tulip issue 115
(http://code.google.com/p/tulip/issues/det
Guido van Rossum added the comment:
Well, there were other pty problems on OS X versions before Mavericks (10.9) --
let's just disable this test too using the same approach.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
neologix, you are getting dangerously close to attacking the person instead of
the issue. Can you live with the current state of the code? If so, let us know
(or be silent if you prefer). If you cannot live with it, please show example
code that fails or is
Guido van Rossum added the comment:
Shouldn't this be fixed in the C implementation of the select module or in
selectors.py? It seems likely that the exact range might be different for each
syscall and possibly per OS or even OS ve
Guido van Rossum added the comment:
I guess this is not a total surprise given that OS X derives in some way from
BSD...
I wonder if we just need to make a matrix of which OS versions and which
syscalls can handle PTYs correctly, and either put it in the docs or perhaps
even refuse to accept
Guido van Rossum added the comment:
I guess whenever you have a timeout like that it's the product of a bad
calculation in the app (wouldn't be the first time that someone multiplied by
1000 instead of dividing to go from milliseconds to seconds :-). So it would be
good to cat
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue5404>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Correct, if you want to work on it, see
http://code.google.com/p/tulip/issues/detail?id=114
--
___
Python tracker
<http://bugs.python.org/issue20
Guido van Rossum added the comment:
Go ahead and close it.
--
___
Python tracker
<http://bugs.python.org/issue20029>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
I'd still like there to be a test.
On Feb 6, 2014 6:52 AM, "STINNER Victor" wrote:
>
> STINNER Victor added the comment:
>
> > I'd appreciate help writing a test. (Debugging this already set me back
> enough hours.)
Guido van Rossum added the comment:
>
> Let me state this last point once again: no busy loop can occur now that
> timeouts are rounded up.
>
How sure are you? Suppose I use poll() with a 0.5 msec timeout. This
presumably gets rounded up to 1 msec. But if the system clock has e.
Guido van Rossum added the comment:
OK, this sounds like rounding up is important to avoid busy-wait (but maybe
only when rounding down would give us zero), and we shouldn't have to worry
about a courser timer, it will just make us late and that's always
acceptable.
On Fri, Feb 7, 20
Guido van Rossum added the comment:
In the end I think Charles-Francois is right -- the rounding up in
selectmodule.c (for epoll) and selectors.py (for poll and, redundantly[*], for
epoll) should be sufficient to avoid the busy-wait behavior with delays under
1ms.
We're not promising
Guido van Rossum added the comment:
Yup, I remember feeling a bit guilty doing it this way, but at least the
semantics are correctly, and there were bigger fish to fry. Thanks for the test
code that proves the issue!
I assume it can be fixed by not using _wait() but some custom approach. If
Guido van Rossum added the comment:
BTW, just curious: Glenn, what led you to discover this?
--
___
Python tracker
<http://bugs.python.org/issue20566>
___
___
Guido van Rossum added the comment:
I'm looking into a solution for this. The idea is pretty straightforward:
http://codereview.appspot.com/61210043.
This needs more code to support the optional timeout feature, and it now
returns Futures instead of coroutines (which I think is fine).
B
Guido van Rossum added the comment:
OK, code is ready for review at
http://code.google.com/p/tulip/source/detail?r=674355412f33
--
___
Python tracker
<http://bugs.python.org/issue20
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue4356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
How do you know that the timer used by the select/poll/etc. call has the same
resolution?
The variable 'now' should probably be given a more suitable name.
Can the clock resolution be zero? If not, I recommend adjusting the comparisons
so tha
Guido van Rossum added the comment:
OK, since the resolution is 1 nsec on my Ubuntu and OSX systems and 15.6 msec
on my Windows box, this patch looks fine.
--
___
Python tracker
<http://bugs.python.org/issue20
Guido van Rossum added the comment:
Please, no. This has to stop.
--
___
Python tracker
<http://bugs.python.org/issue20505>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue20495>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19465>
___
___
Python-bugs-
Guido van Rossum added the comment:
Everyone interested, I plan to push the latest version on view in Rietveld
tomorrow: http://codereview.appspot.com/61210043
It's not as drastic a rewrite as my original attempt; Glenn's idea of using a
Queue worked
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg210765
___
Python tracker
<http://bugs.python.org/issue20566>
___
___
Python-bug
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg210715
___
Python tracker
<http://bugs.python.org/issue20566>
___
___
Python-bug
Guido van Rossum added the comment:
Note: The new version does *not* change the semantics as mentioned in
msg210709. Nobody should depend on those semantics anyway.
--
___
Python tracker
<http://bugs.python.org/issue20
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue20526>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20566>
___
___
Python-bugs-
Guido van Rossum added the comment:
Right, that has been my understanding. Larry has said he'd give asyncio a
generous exception because it's all new in 3.4.
On Sunday, February 16, 2014, Yury Selivanov wrote:
>
> Yury Selivanov added the comment:
>
> I think we should j
Guido van Rossum added the comment:
Then again Larry might appreciate a full list of what to cherrypick.
On Sunday, February 16, 2014, Guido van Rossum
wrote:
>
> Guido van Rossum added the comment:
>
> Right, that has been my understanding. Larry has said he'd give asy
4301 - 4400 of 5563 matches
Mail list logo
