[issue15530] Enhance Py_MIN and Py_MAX

Meador Inge added the comment: I am indifferent with respect to the use of the GCC extensions, but getting rid of the umpteen different implementations of MIN/MAX is a nice , albeit very minor, cleanup. -- ___ Python tracker

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: See also: f17a1410ebe5 -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue15543] central documentation for 'universal newlines'

Antoine Pitrou added the comment: > Since universal newline mode is discouraged and getting deprecated in > the built-in open() function There may (or may not :-)) be a misunderstanding. Universal newlines are not discouraged; it's the legacy "U" flag which is deprecated. -- _

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: > I am indifferent with respect to the use of the GCC extensions, but > getting rid of the umpteen different implementations of MIN/MAX is a > nice , albeit very minor, cleanup. I think that's a different issue from the one we have here, though (which speci

[issue13119] Newline for print() is \n on Windows, and not \r\n as expected

Roundup Robot added the comment: New changeset c55dbb84f3b4 by Victor Stinner in branch 'default': Close #13119: use "\r\n" newline for sys.stdout/err on Windows http://hg.python.org/cpython/rev/c55dbb84f3b4 -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status:

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: > There may (or may not :-)) be a misunderstanding. Universal newlines are not > discouraged; it's the legacy "U" flag which is deprecated. Already understood. :) (I said "in the built-in open() function" above and meant "mode" as in "flag".) I nosied you on

[issue1859] textwrap doesn't linebreak on "\n"

Chris Jerdonek added the comment: > After discussing issue15510, I think this should probably be left as-is, or > be implemented in a separate function so as to avoid breaking compatibility. Note that this issue can be addressed without affecting backwards compatibility in the documented suppo

[issue12605] Enhancements to gdb 7 debugging hooks

Changes by Antoine Pitrou : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13119] Newline for print() is \n on Windows, and not \r\n as expected

Roundup Robot added the comment: New changeset 09408b990ca5 by Victor Stinner in branch '3.2': Close #13119: use "\r\n" newline for sys.stdout/err on Windows http://hg.python.org/cpython/rev/09408b990ca5 -- ___ Python tracker

[issue10841] binary stdio

STINNER Victor added the comment: For the record, this change (always set stdout and stderr in binary mode on Windows) introduced (at least???) the following regressions: - #11272: "input() has trailing carriage return on windows", fixed in Python 3.2.1 - #11395: "print(s) fails on Windows w

[issue15510] textwrap.wrap('') returns empty list

Chris Jerdonek added the comment: > > wrapping, "leading whitespace in the first line is always preserved, > > though." > Ok, then it's a bit fuzzy. That whitespace is as much trailing as > leading, after all :) That's why the word "always" is there. :) > I'm not sure I see the relevance. strip

[issue15510] textwrap.wrap('') returns empty list

Antoine Pitrou added the comment: Le samedi 04 août 2012 à 00:05 +, Chris Jerdonek a écrit : > Chris Jerdonek added the comment: > > > > wrapping, "leading whitespace in the first line is always preserved, > > > though." > > Ok, then it's a bit fuzzy. That whitespace is as much trailing as >

[issue15510] textwrap.wrap('') returns empty list

Antoine Pitrou added the comment: Le samedi 04 août 2012 à 00:32 +, Chris Jerdonek a écrit : > But I feel this criterion was not applied to issue 1859. wrap()'s > behavior on newlines is broken to the point that multi-paragraph input > is acknowledged as not working. Additionally, because o

[issue12655] Expose sched.h functions

STINNER Victor added the comment: I'm sorry, I missed this issue. I just saw its API and I have remarks on the cpu_set type: * Why not reusing the set type for input parameters and the result of sched_getaffinity? * Method names of cpu_set are very different than names of the set type * Why

[issue15510] textwrap.wrap('') returns empty list

Chris Jerdonek added the comment: > As far as these changes don't fix obvious bugs, no, they shouldn't. People certainly rely on the current behaviour, and they will start getting extraneous newlines if you change it (because they will call '\n'.join(...)). That line of reasoning is acceptable t

[issue12655] Expose sched.h functions

Antoine Pitrou added the comment: > Is it possible to get the number of CPU to be able to convert a Python > set to a cpu_set? sched_getaffinity returns EINVAL if the cpu_set is too small, so it should be easy enough to iterate. I agree the API should be changed for something saner, and before

[issue15543] central documentation for 'universal newlines'

Antoine Pitrou added the comment: > I nosied you only because you copy and pasted information about > universal newlines that might benefit from a glossary entry or some > such about universal newlines. Yes, it might benefit from a glossary entry. On the other hand, the details of the *newline*

[issue15553] Segfault in test_6_daemon_threads() of test_threading, on Mac OS X Lion

New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20Lion%203.2/builds/80/steps/test/logs/stdio [ 54/355/1] test_threading test_acquire_contended (test.test_threading.LockTests) ... ok test_acquire_destroy (test.test_threading.LockTests) ... ok test_acquire_release

[issue15510] textwrap.wrap('') returns empty list

Chris Jerdonek added the comment: > Ok, I probably read the issue too quickly. Feel free to ignore my > comment then :-) Thanks. I will prepare another patch for this issue with documentation and test cases of existing behavior. The discussion can of course continue if anyone would like to w

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: > On the other hand, the details of the *newline* argument should probably > remain in the API descriptions themselves. Correct. It would be a high-level entry for "universal newlines" -- independent of any API and suitable for linking to wherever universal n

[issue15554] correct and clarify str.splitlines() documentation

New submission from Chris Jerdonek: The documentation for str.splitlines()-- http://docs.python.org/dev/library/stdtypes.html#str.splitlines includes a statement that is not quite correct: "Unlike split(), if the string ends with line boundary characters the returned list does not have an emp

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow added the comment: Meador, is this still a problem? There was a flurry of activity in this area. -- ___ Python tracker ___

[issue12655] Expose sched.h functions

Benjamin Peterson added the comment: Using a Python set is fine. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15546] Iteration breaks with bz2.open(filename,'rt')

Serhiy Storchaka added the comment: I encountered this when implemented bzip2 support in zipfile (issue14371). I solved this also by rewriting read and read1 to make as many reads from the underlying file as necessary to return a non-empty result. -- nosy: +storchaka _

<    1   2