[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 _

[issue12655] Expose sched.h functions

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

[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 ___

[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

[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

[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

[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

[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*

[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

[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

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

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

[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

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

[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

[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

[issue12605] Enhancements to gdb 7 debugging hooks

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

[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

[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

[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:

[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

[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. -- _

[issue15543] central documentation for 'universal newlines'

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

[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

[issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue15530] Enhance Py_MIN and Py_MAX

Changes by Martin v. Löwis : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: > The former. If C allows it then what's the point of special-casing > Py_MIN and Py_MAX to disallow it? "C allows it" includes cases like "C allows an the result to be implementation-defined, or an implementation-defined signal to be raised", and indeed, some

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

Antoine Pitrou 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. -- nosy: +pitrou ___ Python tracker

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

Antoine Pitrou added the comment: > > That's because wrap() suppresses extra whitespace by default. > > But the documentation for drop_whitespace clearly states that, after > wrapping, "leading whitespace in the first line is always preserved, > though." Ok, then it's a bit fuzzy. That whitesp

[issue15530] Enhance Py_MIN and Py_MAX

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

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

Chris Jerdonek added the comment: > That's because wrap() suppresses extra whitespace by default. But the documentation for drop_whitespace clearly states that, after wrapping, "leading whitespace in the first line is always preserved, though." > Once extra whitespace is suppressed, you are l

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

Antoine Pitrou added the comment: > I propose amending BZ2File.read1() to make as many reads > from the underlying file as necessary to return a non-empty result. Agreed. IMO, read1()'s contract should be read as a best-effort thing, not an absolute guarantee. Returning an empty string when the

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

Nadeem Vawda added the comment: The cause of this problem is that BZ2File.read1() sometimes returns b"", even though the file is not at EOF. This happens when the underlying BZ2Decompressor cannot produce any decompressed data from just the block passed to it in _fill_buffer(); in this case, i

[issue15530] Enhance Py_MIN and Py_MAX

Antoine Pitrou added the comment: > >> I think the feature is somewhat desirable; I agree code combining > >> different types in MIN or MAX is flawed - if it is intentional, asking > >> for an explicit cast is not asking too much. > > > > I don't agree. Trying to battle with C's semantics doesn't

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: >> I think the feature is somewhat desirable; I agree code combining >> different types in MIN or MAX is flawed - if it is intentional, asking >> for an explicit cast is not asking too much. > > I don't agree. Trying to battle with C's semantics doesn't seem ver

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

Antoine Pitrou added the comment: > For an empty string, sure -- for a string with nothing but white space, > no: > --> wrap(' ') > [] That's because wrap() suppresses extra whitespace by default. Once extra whitespace is suppressed, you are left with an empty text, meaning an empty list o

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

Ethan Furman added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> Really. >> >> --> ''.split('\n') >> [''] > > You claimed that an empty list is not a list of lines. I countered that > splitlines(), which *by definition* returns a list of lines, can return > an empt

[issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor?

STINNER Victor added the comment: Oh, I see: os.ftruncate() is present in Python 3.2; but os.truncate() was added to Python 3.3. Ok, it's an excellent reason to not remove os.ftruncate() ;-) -- ___ Python tracker _

[issue15551] Unit tests that return generators silently fail

Jason Baker added the comment: I would like to verify this. Link the specification, and highlight where it says that the expected behavior for a test method that is a generator function is to do nothing. -- ___ Python tracker

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

Antoine Pitrou added the comment: > Really. > > --> ''.split('\n') > [''] You claimed that an empty list is not a list of lines. I countered that splitlines(), which *by definition* returns a list of lines, can return an empty list, therefore textwrap.wrap() is not exotic in its behaviour. Whet

[issue15551] Unit tests that return generators silently fail

Michael Foord added the comment: It's the expected behaviour according to the unittest specification. -- ___ Python tracker ___ ___ Py

[issue15551] Unit tests that return generators silently fail

Jason Baker added the comment: Who expects this behavior? Can you give me an example of when someone would rely upon a generator test to do nothing? -- ___ Python tracker ___ _

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

Ethan Furman added the comment: Ethan Furman wrote: >> Antoine Pitrou added the comment: >> > "".splitlines() >> [] > > --> ''.split('\n') > [''] I see the docs have been fixed in 3 to explain the not present last empty line. However, sure this is still not correct? --> wrap(' ') [] S

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

Ethan Furman added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> an empty list is not a list of lines > > Really? > "".splitlines() > [] Really. --> ''.split('\n') [''] -- ___ Python tracker

[issue15551] Unit tests that return generators silently fail

Michael Foord added the comment: It's not a game. Have a test method as a generator function is clearly programmer error. Doing nothing is the expected behaviour. -- ___ Python tracker

[issue15550] Trailing white spaces

Antoine Pitrou added the comment: Or you can use "make patchcheck" which will (hopefully) warn you of such issues. -- nosy: +pitrou ___ Python tracker ___ ___

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

Antoine Pitrou added the comment: > an empty list is not a list of lines Really? >>> "".splitlines() [] -- ___ Python tracker ___ __

[issue15551] Unit tests that return generators silently fail

Jason Baker added the comment: I can play this game too! Since generator functions do nothing when used as a unittest test method, there is no value in having a test method that is a generator function. Therefore, it is an error to give a test method that is a generator function. Since it is

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

Ethan Furman added the comment: Not sure I would worry about fixing it in 2.7, although I don't have strong feelings about that. -- ___ Python tracker ___ __

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

Ethan Furman added the comment: The documentation says, "Returns a list of output lines"; an empty list is not a list of lines. -- nosy: +stoneleaf ___ Python tracker ___ __

[issue15551] Unit tests that return generators silently fail

Michael Foord added the comment: unittest calls test methods to execute tests. Generator functions do nothing (except create a generator) when you call them. Test methods as generators therefore do nothing in unittest. -- resolution: -> invalid stage: -> committed/rejected status: op

[issue15551] Unit tests that return generators silently fail

Changes by Ned Deily : -- nosy: +ezio.melotti, michael.foord ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue15550] Trailing white spaces

Ned Deily added the comment: There already is a hook in place for the main python.org repository that checks for and rejects changesets that include files with space issues: http://hg.python.org/hooks/file/bd04c6b37749/checkwhitespace.py You can add it to your local repo to check patches befor

[issue15550] Trailing white spaces

Serhiy Storchaka added the comment: Because CPython repository contains binary files too, they should be reverted: hg diff | sed -nre 's/^Binary file (.*) has changed/\1/p' | tr '\n' '\0' | xargs -0 hg revert -- ___ Python tracker

[issue15544] math.isnan fails with some Decimal NaNs

Antoine Pitrou added the comment: > > Why not add a is_nan() method to float numbers instead? > > Do you mean replacing math.isnan(x) by x.is_nan() to avoid the issue > altogether? I'm not sure that's possible given that math just wraps > the C library. Yup. By calling x.is_nan() you would by c

[issue15544] math.isnan fails with some Decimal NaNs

Stefan Krah added the comment: > Why not add a is_nan() method to float numbers instead? Do you mean replacing math.isnan(x) by x.is_nan() to avoid the issue altogether? I'm not sure that's possible given that math just wraps the C library. -- ___ Py

[issue15544] math.isnan fails with some Decimal NaNs

Stefan Krah added the comment: > OTOH, IEEE 754 *does* cover floating-point to int conversions (5.4.1, 5.8): > those fall under 'general-computational operations', and as such should > signal when given an sNaN. That sounds good. Let's keep the ValueError then. We could consider InvalidOperat

[issue15548] Mention all new os functions in What's New in Python 3.3

Georg Brandl added the comment: Victor: try "make changes". -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15464] ssl: add set_msg_callback function

Antoine Pitrou added the comment: Thiébaud, I haven't reviewed the patch in detail, but why does the callback only receive the buffer contents? At the minimum, I think it should also receive write_p (whether the packet is an incoming or outgoing message is a rather useful piece of information)

[issue15552] gettext: if looking for .mo in default locations, also look in locale-bundle location

New submission from Dominique Leuenberger: Coming from openSUSE, might be a bit special, but worthy the discussion. Background: - Language files are per design split off from the main application rpm (package-lang). Rational is 'space concerns for live CDs' - We offer bundle-lang- packages, wi

[issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor?

Larry Hastings added the comment: Because both functions were available in 3.2, and we can't remove old functions without a full deprecation cycle. -- resolution: -> wont fix stage: -> committed/rejected status: open -> closed ___ Python tracker <

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

Antoine Pitrou added the comment: > I think this is a bug. Do you have any argument? -- ___ Python tracker ___ ___ Python-bugs-list m

[issue15551] Unit tests that return generators silently fail

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue15551] Unit tests that return generators silently fail

New submission from Jason Baker: The following test will pass silently: class SomeTest(unittest.TestCase): def testSomething(self): yield 1 self.fail() -- components: None messages: 167340 nosy: Jason.Baker priority: normal severity: normal status: open title

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

Changes by Jesús Cea Avión : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

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

Jesús Cea Avión added the comment: I think this is a bug. The question to ponder is backwards compatibility, specially if this is going to be backported to 2.7/3.2. Chris, could you possibly ask for opinions in python-dev and/or python-list? -- stage: patch review ->

[issue15549] openssl version in windows builds does not support renegotiation

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

[issue15540] Python 3.3 and numpy

Travis Oliphant added the comment: On Aug 3, 2012, at 1:35 AM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> This is a mis-understanding of what NumPy does and why.There is >> a need to byte-swap only when the data is stored on disk in the >> reverse order from the

[issue15487] Correct __sizeof__ support for buffered I/O

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15425] Another strange Tracebacks with importlib

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15550] Trailing white spaces

New submission from Serhiy Storchaka: My editors are configured to remove trailing spaces (this is useful for removing artifacts of indentation). The flip side of this is that my patches sometimes contain unrelated trailing spaces fixes. Trailing spaces are not significant in any CPython sourc

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15549] openssl version in windows builds does not support renegotiation

New submission from Cory Mintz: The Python 2.7.3 and 2.6.8 Windows builds are both built against "OpenSSL 0.9.8l 5 Nov 2009". This specific version of OpenSSL had renegotiation removed due a security vulnerability. Except from http://svn.python.org/projects/external/openssl-0.9.8x/NEWS. Ma

[issue15540] Python 3.3 and numpy

Ondřej Čertík added the comment: Here is my new patch: https://github.com/numpy/numpy/pull/372 It implements what I was talking about (and fixes the NumPy tests bug). -- ___ Python tracker ___

[issue15494] Move test/support.py into a test.support subpackage

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue15492] textwrap.wrap expand_tabs does not behave as expected

R. David Murray added the comment: I think that expanding them before wrapping is correct. Any lining up would be true only for the original unwrapped input text. -- nosy: +r.david.murray ___ Python tracker _

[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior

R. David Murray added the comment: I want the opposite: a way to say I don't care what the mode is as long as it exists. Currently there is no way to do that, as far as I remember. -- ___ Python tracker _

[issue15512] Correct __sizeof__ support for parser

Serhiy Storchaka added the comment: Compilation of 2.7 under Windows is successful: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/77 -- status: open -> closed ___ Python tracker __

[issue15544] math.isnan fails with some Decimal NaNs

Antoine Pitrou added the comment: Why not add a is_nan() method to float numbers instead? -- nosy: +pitrou ___ Python tracker ___ ___

[issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib

R. David Murray added the comment: This is an interesting idea and should at least improve matters. I'm wondering, though...I seem to remember writing code that fished the wrapped error out using one of those attributrs...but I'm not at a computer where I can try to check on that. Hopefully

[issue15513] Correct __sizeof__ support for pickle

Serhiy Storchaka added the comment: In any case do not commit the patch for the time being. Probably it should be improved to include the size of the internal Python objects (see discussion in issue15490). -- ___ Python tracker

[issue15512] Correct __sizeof__ support for parser

Roundup Robot added the comment: New changeset 0827fef8652d by Jesus Cea in branch '2.7': #15512: Remove remnants of debugging code http://hg.python.org/cpython/rev/0827fef8652d New changeset 0bda3f00b60a by Jesus Cea in branch '3.2': #15512: Remove remnants of debugging code http://hg.python.or

[issue15540] Python 3.3 and numpy

Ondřej Čertík added the comment: Martin, > So if the byte swapping is done before the Unicode object is created: > why did Dave and Ondřej run into problems then? As I wrote above (http://bugs.python.org/msg167280), this happened because of wrong NumPy tests, that need to be fixed. They are te

[issue15544] math.isnan fails with some Decimal NaNs

Mark Dickinson added the comment: > before the conversion to float. By I have no idea whether that is > practical in the math module. That's a much bigger discussion: as it is, most of the math module functions just provide simple wrappers around the system math library, which deals purely wi

[issue15512] Correct __sizeof__ support for parser

Serhiy Storchaka added the comment: > Compilation of 2.7 under Windows is broken: Here is a patch for declarations reorganizing. -- Added file: http://bugs.python.org/file26678/parser_methods_declaration_move-2.7.patch ___ Python tracker

[issue15473] importlib no longer uses imp.NullImporter

Changes by Brett Cannon : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue15512] Correct __sizeof__ support for parser

Serhiy Storchaka added the comment: Oops, I forgot to remove the remnants of debugging code. Here's the patch. Sorry. -- Added file: http://bugs.python.org/file26677/parser_sizeof_cleanup.patch ___ Python tracker

[issue15544] math.isnan fails with some Decimal NaNs

Steven D'Aprano added the comment: On 03/08/12 22:06, Mark Dickinson wrote: > >> Decimal('snan').is_nan() just returns true and I am under the impression >> that IEEE 754 specifies the same. > > Sure, but IEEE 754 also specifies that math.sqrt() should > signal. Since both math.sqrt and math.isn

[issue15548] Mention all new os functions in What's New in Python 3.3

Ross Lagerwall added the comment: Attached is a diff between dir(os) in 3.2 and 3.3 -- keywords: +patch nosy: +rosslagerwall Added file: http://bugs.python.org/file26676/oschanges.diff ___ Python tracker __

[issue15512] Correct __sizeof__ support for parser

Antoine Pitrou added the comment: Compilation of 2.7 under Windows is broken: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/75 -- assignee: -> jcea nosy: +pitrou status: closed -> open ___ Python tracker

[issue15469] Correct __sizeof__ support for deque

Roundup Robot added the comment: New changeset a3d49f1de893 by Jesus Cea in branch '2.7': Closes #15469: Correct __sizeof__ support for deque http://hg.python.org/cpython/rev/a3d49f1de893 New changeset b0725c1b3068 by Jesus Cea in branch '3.2': Closes #15469: Correct __sizeof__ support for deque

[issue15530] Enhance Py_MIN and Py_MAX

Antoine Pitrou added the comment: Le vendredi 03 août 2012 à 12:15 +, Martin v. Löwis a écrit : > So compared to the traditional type checks: > a) this gives a hard compile error, whereas the existing check would > only produce warnings Warnings are quite visible already, and we try to silen

[issue15512] Correct __sizeof__ support for parser

Roundup Robot added the comment: New changeset aceb975c4832 by Jesus Cea in branch '2.7': Closes #15512: Correct __sizeof__ support for parser http://hg.python.org/cpython/rev/aceb975c4832 New changeset 91884d04de06 by Jesus Cea in branch '3.2': Closes #15512: Correct __sizeof__ support for pars

[issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor?

STINNER Victor added the comment: To check if os.truncate() supports file description, "os.truncate in os.supports_fd" checek can be used. -- ___ Python tracker ___

[issue15544] math.isnan fails with some Decimal NaNs

Mark Dickinson added the comment: > IEEE 754 doesn't help here, since it doesn't cover decimal > floating-point <-> binary floating-point conversions. OTOH, IEEE 754 *does* cover floating-point to int conversions (5.4.1, 5.8): those fall under 'general-computational operations', and as such sh

[issue15548] Mention all new os functions in What's New in Python 3.3

New submission from STINNER Victor: The os module has a lot of new functions in Python 3.3. It looks like only a few are documented in What's New in Python 3.3. Examples : truncate(), ftruncate() and sync() are not mentionned. Does Sphinx have a function to list of new functions added to Pytho

[issue15547] Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor?

Changes by STINNER Victor : -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue15512] Correct __sizeof__ support for parser

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename

STINNER Victor added the comment: Attached patch modifies all functions of the os module taking filenames to keep the filename unmodified in OSError.filename. The patch changes also os.link(), os.rename() and os.replace() to use the source, not the destination, in the error message. It is mayb

[issue15514] Correct __sizeof__ support for cpu_set

Roundup Robot added the comment: New changeset 463d3ad22cdb by Jesus Cea in branch 'default': Closes #15514: Correct __sizeof__ support for cpu_set http://hg.python.org/cpython/rev/463d3ad22cdb -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> close

  1   2   >