[issue23251] mention in time.sleep() docs that it does not block other Python threads

2016-04-18 Thread Berker Peksag

Changes by Berker Peksag :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-25 Thread Akira Li

Akira Li added the comment:

I've removed mentioning of GIL and uploaded a new patch.

--
Added file: 
http://bugs.python.org/file37850/docs-time.sleep-other-threads-are-not-blocked-2.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-25 Thread R. David Murray

R. David Murray added the comment:

Oops, typoed the issue number.

New changeset 3a9b1e5fe179 by R David Murray in branch '3.4':
#23215: reflow paragraph.
https://hg.python.org/cpython/rev/3a9b1e5fe179

New changeset 52a06812d5da by R David Murray in branch 'default':
Merge: #23215: note that time.sleep affects the current thread only.
https://hg.python.org/cpython/rev/52a06812d5da

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-25 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 55ad65c4f9e2 by R David Murray in branch '3.4':
#23251: Note that time.sleep affects the calling thread only.
https://hg.python.org/cpython/rev/55ad65c4f9e2

New changeset 5e01c68cabbf by R David Murray in branch '2.7':
#23251: note that time.sleep affects the current thread only.
https://hg.python.org/cpython/rev/5e01c68cabbf

New changeset 5db28a3199b2 by R David Murray in branch '2.7':
#23251: Reflow paragraph.
https://hg.python.org/cpython/rev/5db28a3199b2

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-25 Thread R. David Murray

R. David Murray added the comment:

Thanks, Akira, but I did not use your patch, since it still had the paragraph 
reflow in it.

--
resolution:  - fixed
stage: commit review - resolved

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-18 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Please let's stop it. Mentioning the GIL in every place in the documentation 
will only make people more worried and confused about something they shouldn't 
be confused or worried about.

If you think some docs should discuss the GIL and its effect on running threads 
then I suggest writing a separate document (a HOWTO for example, like the 
Unicode HOWTO).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-18 Thread Akira Li

Akira Li added the comment:

 Only if the behaviour was unintuitive (i.e. if it *didn't* release the
 GIL) would it make sense to document it.

There is no intuitive interface, not even the nipple. It's all learned. [1]

 Yes, on consideration I agree with Antoine.  That last sentence should
 be deleted.  Otherwise we'd need to mention that the gil was released
 every place that the gil was released, which would be very redundant.

Whether or not other places mention it is unrelated to the current
issue.

Though the documentation should mention it more. Many programmers are
convinced that Python threads can't be executed in parallel.

 The general rule is that anything that blocks in python releases the
 GIL, therefore as Antoine says the only time we need to document GIL
 behavior is when that *doesn't* happen.

The reader of Python documentation is intelegent but not all-knowing.

Blocking is the first and only job for time.sleep() function.
GIL blocks Python code.
You can't understand what time.sleep does without knowing what happens
to GIL.

Ask yourself who and why reads the time.sleep() documentation (novice
and/or exprerienced Python user). Put yourself into the mind of the
reader.


[1] http://www.greenend.org.uk/rjk/misc/nipple.html

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-18 Thread Georg Brandl

Georg Brandl added the comment:

Agreed. of the current thread is a good addition.  The sleep() docs are 
already longer than I would like.

--
nosy: +georg.brandl

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-18 Thread Andrew Svetlov

Andrew Svetlov added the comment:

I'm with Antoine.

Yes, GIL is extremely important but please don't put GIL mentions everywhere.

On Sun, Jan 18, 2015 at 4:39 PM, Antoine Pitrou rep...@bugs.python.org wrote:

 Antoine Pitrou added the comment:

 Please let's stop it. Mentioning the GIL in every place in the documentation 
 will only make people more worried and confused about something they 
 shouldn't be confused or worried about.

 If you think some docs should discuss the GIL and its effect on running 
 threads then I suggest writing a separate document (a HOWTO for example, like 
 the Unicode HOWTO).

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue23251
 ___

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-17 Thread R. David Murray

R. David Murray added the comment:

Yes, on consideration I agree with Antoine.  That last sentence should be 
deleted.  Otherwise we'd need to mention that the gil was released every place 
that the gil was released, which would be very redundant.  The general rule is 
that anything that blocks in python releases the GIL, therefore as Antoine says 
the only time we need to document GIL behavior is when that *doesn't* happen.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-17 Thread Antoine Pitrou

Antoine Pitrou added the comment:

I think it's superfluous to mention the GIL here, since it has no impact on the 
function.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-17 Thread Akira Li

Akira Li added the comment:

 I think it's superfluous to mention the GIL here, since it has no impact on 
 the function.

If GIL is not released then all Python code in other threads is 
effectively blocked.
It is worth mentioning explicitly that it is guaranteed to be released
during the sleep.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-17 Thread Antoine Pitrou

Antoine Pitrou added the comment:

 If GIL is not released then all Python code in other threads is 
 effectively blocked.

But that would be a stupid implementation of sleep(). It is not desirable to 
clutter the docs with such mentions: most calls to the OS in the stdlib release 
the GIL.

Only if the behaviour was unintuitive (i.e. if it *didn't* release the GIL) 
would it make sense to document it.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread Akira Li

New submission from Akira Li:

There is the corresponding StackOverflow question with 60K view 
time.sleep — sleeps thread or process? [1]

The documentation patch is attached.

[1] http://stackoverflow.com/questions/92928/time-sleep-sleeps-thread-or-process

--
assignee: docs@python
components: Documentation
files: docs-time.sleep-other-threads-are-not-blocked.diff
keywords: patch
messages: 234135
nosy: akira, docs@python
priority: normal
severity: normal
status: open
title: mention in time.sleep() docs that it does not block other Python threads
type: enhancement
versions: Python 3.5
Added file: 
http://bugs.python.org/file37730/docs-time.sleep-other-threads-are-not-blocked.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread R. David Murray

R. David Murray added the comment:

Can you re-upload the patch without reflowing the paragraph?  I think the only 
thing needed is the addition of the word thread, to mirror the equivalent unix 
man page phrasing, and I think that's what you've done, but I can't easily tell 
from the provided patch.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread Martin Panter

Martin Panter added the comment:

There is also a new sentence about the GIL at the end, but leaving the 
inbetween lines as they were would verify this

--
nosy: +vadmium

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread Akira Li

Akira Li added the comment:

I do not understand. Have you tried to look at the patch in Rietveld?

The new content is highlighted in a darker green. It is clearly
visible. I've tested on Chromium, Firefox, Safari.

If I won't reflow then the first line will be longer than the
recommended 80 in devguide:

 The maximum line length is 80 characters for normal text, but
 tables, deeply indented code samples and long links may extend
 beyond that.

I've set *fill-column* to 80 in emacs. Do you suggest other settings?

Anyway, it doesn't affect how the final text is shown in a web
browser.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread Andrew Svetlov

Andrew Svetlov added the comment:

I guess R. David Murray asked you to make the least minimal change,
even it breaks the formatting rules.

Paragraph reflow is safe when it's done by the Core Developer but it
requires additional check (and probably mercurial conflict errors on
merging the change with default branch if the last has changes also).

In your case I see no problems though, but the final decision is on R.
David Murray

On Sat, Jan 17, 2015 at 12:56 AM, Akira Li rep...@bugs.python.org wrote:

 Akira Li added the comment:

 I do not understand. Have you tried to look at the patch in Rietveld?

 The new content is highlighted in a darker green. It is clearly
 visible. I've tested on Chromium, Firefox, Safari.

 If I won't reflow then the first line will be longer than the
 recommended 80 in devguide:

 The maximum line length is 80 characters for normal text, but
 tables, deeply indented code samples and long links may extend
 beyond that.

 I've set *fill-column* to 80 in emacs. Do you suggest other settings?

 Anyway, it doesn't affect how the final text is shown in a web
 browser.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue23251
 ___
 ___
 docs mailing list
 d...@python.org
 https://mail.python.org/mailman/listinfo/docs

--
nosy: +asvetlov

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread Martin Panter

Martin Panter added the comment:

What I have sometimes done in this situation is just break the overly long line 
into two short lines

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23251] mention in time.sleep() docs that it does not block other Python threads

2015-01-16 Thread R. David Murray

R. David Murray added the comment:

I actually didn't know that reitveld was smart enough to highlight just the 
text changes in a reflowed paragraph.

Nevertheless, for ease of looking at diff in the repository using the hg 
command (which is not that smart), I prefer to commit doc changes without the 
reflow, then do the reflow in a separate commit.  I don't know if other 
developers do this or not.

I think the patch is fine.

--
stage:  - commit review
versions: +Python 2.7, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23251
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com