On Mar 17, 2014 12:53 PM, "Jurko Gospodnetić"
wrote:
>
> Hi.
>
>
> On 17.3.2014. 19:03, Ian Kelly wrote:
>>
>> So yes, despite the lack of true concurrency, a thread can continue to
>> run after its _stop has been called.
>
>
> Actually 'true' or 'false' concurrency does not matter here.
>
>
Hi.
On 17.3.2014. 19:03, Ian Kelly wrote:
So yes, despite the lack of true concurrency, a thread can continue to
run after its _stop has been called.
Actually 'true' or 'false' concurrency does not matter here.
CPython supports multiple threads and implements them using
underlying nati
On Tue, Mar 18, 2014 at 5:13 AM, Felix Yan wrote:
> On Tuesday, March 18, 2014 05:08:20 Chris Angelico wrote:
>> I've posted comments on both the issues you linked to. My guess based
>> on a cursory look at paramiko is that it's a test suite watchdog,
>> which would be much better implemented with
On Tuesday, March 18, 2014 05:08:20 Chris Angelico wrote:
> I've posted comments on both the issues you linked to. My guess based
> on a cursory look at paramiko is that it's a test suite watchdog,
> which would be much better implemented with a subprocess; I may be
> wrong, though. In any case, if
On Tue, Mar 18, 2014 at 4:59 AM, Felix Yan wrote:
> For now I just skipped the test suites for paramiko to get the packaging done
> (since the test suites themselves are passed without a problem, just the test
> script made something wrong). I'll try to follow up the issue for paramiko :)
I've po
On Mon, Mar 17, 2014 at 11:40 AM, Chris Angelico wrote:
> Antoine says that this doesn't even stop the thread
> (I can't say; I've never used _stop(), for obvious reasons), so this
> code was doubly broken.
I was curious about that -- after all, Python's threads aren't truly
concurrent, so perhap
On Monday, March 17, 2014 17:33:09 Antoine Pitrou wrote:
> Hi,
>
> Felix Yan gmail.com> writes:
> > A minimized snippet to reproduce:
> >
> > #!/usr/bin/python
> > import threading
> >
> > def stale():
> > import time
> > time.sleep(1000)
> >
> > t = threading.Thread(target=stale)
> >
On Tue, Mar 18, 2014 at 4:18 AM, Felix Yan wrote:
> I noticed a behavior change on Thread._stop() with Python 3.4.
>
> I know the method is an undocumented "feature" itself, but some projects are
> using it, and now they fail.
>
> I know trying to forcefully stop a thread is not really a good prac
Hi,
Felix Yan gmail.com> writes:
>
> A minimized snippet to reproduce:
>
> #!/usr/bin/python
> import threading
> def stale():
> import time
> time.sleep(1000)
> t = threading.Thread(target=stale)
> t.start()
> t._stop()
>
> This works correctly with Python 3.3, the program exits imme
Hi list,
I noticed a behavior change on Thread._stop() with Python 3.4.
I know the method is an undocumented "feature" itself, but some projects are
using it, and now they fail.
A minimized snippet to reproduce:
#!/usr/bin/python
import threading
def stale():
import time
time.sleep(100
10 matches
Mail list logo
