[issue15544] math.isnan fails with some Decimal NaNs

[Mark Dickinson]

Mark Dickinson added the comment:

Yep, Decimal.__float__ isn't too sophisticated.  Probably it should convert all 
Decimal quiet NaNs (at least) to float NaNs, keeping the sign if possible but 
discarding any payload.

Not so sure about signaling NaNs, though;  I think it would be fine for those 
to continue to raise ValueError (on the basis that doing pretty much anything 
with a signaling NaN should give an exception).

--

___
Python tracker 

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

[issue15543] central documentation for 'universal newlines'

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See issue15204.

--
nosy: +storchaka

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Charles-François Natali]

Charles-François Natali added the comment:

> (gdb) p op
> $12 = (PyObject *) 0x4dc7bc0

Don't you have GDB 7, to decode Python objects ?
You can check the type of the object with :
"""
p op->ob_type.tp_name
"""

>
> thread all apply bt is going to be very long no ? Could you tell me what you 
> want to know that is not in info threads maybe ? I can definitely post it 
> here, but it's going to be a lot of output.

You can add it as an attachment.

--

___
Python tracker 

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

[issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row

[Pierre Le Marre]

Changes by Pierre Le Marre :


--
components: None
nosy: plemarre
priority: normal
severity: normal
status: open
title: sqlite3.Connection.iterdump() does not work with row_factory = 
sqlite3.Row
type: crash
versions: Python 3.2

___
Python tracker 

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

[issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row

[Martin v . Löwis]

New submission from Martin v. Löwis:

Can you please elaborate? Structure your report as follows:

1. this is what I did
2. this is what happened
3. this is what should have happened instead.

--
nosy: +loewis

___
Python tracker 

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

[issue15204] Deprecate the 'U' open mode

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
nosy: +cjerdonek

___
Python tracker 

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

[issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row

[Pierre Le Marre]

Pierre Le Marre added the comment:

I use Python 3.2.3 on GNU/Linux 64bits (openSUSE 12.2).
I have created an in-memory connection with the following code:

conn = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES, 
check_same_thread=False)
conn.row_factory = sqlite3.Row

Then I have filled the database, but when it comes to copy it via 
conn.iterdump(), it crashed with the following message:

File "/usr/lib64/python3.2/sqlite3/dump.py", line 30, in _iterdump
for table_name, type, sql in sorted(schema_res.fetchall()):
TypeError: unorderable types: sqlite3.Row() < sqlite3.Row()

It seems that the error appears because of the use of "sorted()". In fact, if I 
don't change conn.row_factory or if I use a custom class _Row implementing 
__lt__ method (see below) this error does not appear.

class _Row(sqlite3.Row):
def __lt__(self, x):
return False

--

___
Python tracker 

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

[issue15543] central documentation for 'universal newlines'

[Chris Jerdonek]

Chris Jerdonek added the comment:

Since universal newline mode is discouraged and getting deprecated in the 
built-in open() function, the "central" place for describing universal newlines 
should probably not be the documentation for the open() method.  I am leaning 
towards a glossary entry.

The io.TextIOWrapper class is another candidate:

http://docs.python.org/dev/library/io.html#io.TextIOWrapper

--

___
Python tracker 

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

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

[David Beazley]

New submission from David Beazley:

The bz2 library in Python3.3b1 doesn't support iteration for text-mode 
properly.  Example:

>>> f = bz2.open('access-log-0108.bz2')
>>> next(f)   # Works
b'140.180.132.213 - - [24/Feb/2008:00:08:59 -0600] "GET /ply/ply.html HTTP/1.1" 
200 97238\n'

>>> g = bz2.open('access-log-0108.bz2','rt')
>>> next(g)   # Fails
Traceback (most recent call last):
  File "", line 1, in 
StopIteration
>>>

--
components: Library (Lib)
messages: 167299
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Iteration breaks with bz2.open(filename,'rt')
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Steven D'Aprano]

Steven D'Aprano added the comment:

Attached is a patch for decimal.py, and test_decimal.py. I cannot provide a 
patch for the C decimal implementation, sorry.

Following Mark's suggestion, my patch keeps the sign but discards the payload 
for quiet NANs, and raises ValueError for signalling NANs.

(I'm ambivalent about signalling NANs raising ValueError, but I guess that's 
better than having snan silently converted to a quiet nan.)

--
keywords: +patch
Added file: http://bugs.python.org/file26672/decimalnan.patch

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Martin v . Löwis]

Martin v. Löwis added the comment:

> FWIW, with regard to Martin's tangential comment about appropriate  
> use of the tracker, I'm personally fine with using the tracker for  
> 'I found this problem, attempted to fix it (but failed), here's my  
> attempt'.

I don't mind that at all, either. What I dislike is "I have this issue,
here is what I've got, and I will continue to work on it" kind of reports
(when Dave clearly said that his patch is work-in-progress). There is a
worse kind, where people say "I have this issue", followed (after 15 minutes)
with "I found out more", and then going on with that for a while. I feel
that this wastes the reader's time (who may actually start to work on the
issue as well, duplicating efforts) - this is something that submitters
really need to consider. It's not this bad in this issue, since Dave said
from the beginning that it is work-in-progress.

On-topic: what action do you suggest for this issue?

--

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Stefan Krah]

Stefan Krah added the comment:

I think math.isnan('snan') probably should not raise. Decimal('snan').is_nan()
just returns true and I am under the impression that IEEE 754 specifies the 
same. I have to admit though that I just consulted Wikipedia for the latter:

"The predicate isNaN(x) determines if a value is a NaN and never signals an
 exception, even if x is a signaling NaN."

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Stefan Krah]

Stefan Krah added the comment:

Martin v. L??wis  wrote:
> I don't mind that at all, either. What I dislike is "I have this issue,
> here is what I've got, and I will continue to work on it" kind of reports
> (when Dave clearly said that his patch is work-in-progress). There is a
> worse kind, where people say "I have this issue", followed (after 15 minutes)
> with "I found out more", and then going on with that for a while. I feel
> that this wastes the reader's time (who may actually start to work on the
> issue as well, duplicating efforts) - this is something that submitters
> really need to consider. It's not this bad in this issue, since Dave said
> from the beginning that it is work-in-progress.

I think Dave's main issue was: Here's a problem with NumPy/3.3, could we
perhaps remove an assert() to keep NumPy working. That was the one-liner
patch.

The NumPy patches were probably there for illustration. -- It might be unusual
to post patches for third party packages on the tracker, but NumPy is in a
very special situation right now:

Version 1.7 is about to be released and is currently not 3.3 compatible.
As Nick said, NumPy is a blocker for Python-3.3 integration into Fedora.

So, I hope that Travis doesn't mind if people keep pushing the issue a bit.
On the positive side, it's a sign that people care a lot about NumPy.

> On-topic: what action do you suggest for this issue?

As for the action, I think everyone agrees that no changes to Python are
necessary.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +nadeem.vawda

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Antoine Pitrou]

Antoine Pitrou added the comment:

I don't understand the point of your patch. Can you explain?

--
nosy: +pitrou

___
Python tracker 

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

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

[Nadeem Vawda]

Nadeem Vawda added the comment:

I can't seem to reproduce this with an up-to-date checkout from Mercurial:

>>> import bz2
>>> g = bz2.open('access-log-0108.bz2','rt')
>>> next(g)
'140.180.132.213 - - [24/Feb/2008:00:08:59 -0600] "GET /ply/ply.html 
HTTP/1.1" 200 97238\n'

(where 'access-log-0108.bz2' is a file I created with the output above as
its first line, and a couple of other lines of random junk following that)

Would it be possible for you to upload the file you used to trigger this
bug?

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Yes. It's explained in the comment of the two macros:
> 
> "When compiled with GCC, check also that types of x and y are
> compatible at compile time."

I'm sorry, that doesn't explain anything. The C compiler already checks
types for you. So what does it bring? And if it brings anything, why
should it be restricted to Py_MIN and Py_MAX?

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[STINNER Victor]

STINNER Victor added the comment:

> I don't understand the point of your patch. Can you explain?

Yes. It's explained in the comment of the two macros:

"When compiled with GCC, check also that types of x and y are compatible at 
compile time."

So it adds a cheap santity check at compile time.

--

___
Python tracker 

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

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

[David Beazley]

David Beazley added the comment:

File attached.The file can be read in its entirety in binary mode.

--
Added file: http://bugs.python.org/file26673/access-log-0108.bz2

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Mark Dickinson]

Mark Dickinson added the comment:

> 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.isnan are going through __float__, we 
can't keep everyone happy here.

The question for me is really what __float__ should do.  IEEE 754 doesn't help 
here, since it doesn't cover decimal floating-point <-> binary floating-point 
conversions.

--

___
Python tracker 

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

[issue15525] test_multiprocessing failure on Windows XP

[Richard Oudkerk]

Richard Oudkerk added the comment:

Looks like it is fixed.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

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

[STINNER Victor]

New submission from STINNER Victor:

posix_truncate() accepts a file descriptor, so os.ftruncate() can be removed 
from Python 3.3.

memset(&path, 0, sizeof(path));
path.function_name = "truncate";
#ifdef HAVE_FTRUNCATE
path.allow_fd = 1;
#endif
if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&O&:truncate", keywords,
 path_converter, &path,
 _parse_off_t, &length))
return NULL;

--
messages: 167311
nosy: haypo, larry
priority: deferred blocker
severity: normal
status: open
title: Why do we have os.truncate() and os.ftruncate() whereas os.truncate() 
accepts a file descriptor?
versions: Python 3.3

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Martin v . Löwis]

Martin v. Löwis added the comment:

Victor hinted that it would detect errors when combining int and unsigned int. 
To elaborate, see the attached min.c. It gives

[traditional MIN definition]
  [int, pointer]
min.c:18: warning: comparison between pointer and integer
min.c:18: warning: pointer/integer type mismatch in conditional expression
[static assert]
  [int, unsigned int]
min.c:20: error: size of array ‘type name’ is negative
  [int, double]
min.c:21: error: size of array ‘type name’ is negative
  [int, pointer]
min.c:22: error: size of array ‘type name’ is negative
min.c:22: warning: comparison between pointer and integer
min.c:22: warning: pointer/integer type mismatch in conditional expression

So compared to the traditional type checks:
a) this gives a hard compile error, whereas the existing check would only 
produce warnings
b) the existing min happily combines (int,unsigned) giving unsigned and (int, 
double) giving double; the new code will will reject such code.

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.

The only downside of the patch is that it uses a language extension. We should 
strive to reduce usage of language extensions, not increase it.

I also have a personal dislike of fanciness in code. Code should be clean, not 
cute.

--
Added file: http://bugs.python.org/file26674/min.c

___
Python tracker 

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

[issue15514] Correct __sizeof__ support for cpu_set

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15514] Correct __sizeof__ support for cpu_set

[Roundup Robot]

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 -> closed

___
Python tracker 

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

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

[STINNER Victor]

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 maybe a mistake 
because these functions can also fail in the directory of the destination does 
not exist.

--
keywords: +patch
Added file: http://bugs.python.org/file26675/oserror_filename.patch

___
Python tracker 

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

[issue15512] Correct __sizeof__ support for parser

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

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

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +georg.brandl

___
Python tracker 

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

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

[STINNER Victor]

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 Python 3.3? At 
least to check that the What's New in Python 3.3 is complete.

I would like to have the full list to check that new functions are consistent. 
See for example the issue #15547.

--
assignee: docs@python
components: Documentation
messages: 167315
nosy: docs@python, georg.brandl, haypo, larry, rhettinger
priority: normal
severity: normal
status: open
title: Mention all new os functions in What's New in Python 3.3
versions: Python 3.3

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Mark Dickinson]

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 should signal 
when given an sNaN (6.2: "Signaling NaNs shall be reserved operands that, under 
default exception handling, signal the invalid operation exception (see 7.2) 
for every general-computational and signaling-computational operation except 
for the conversions described in 5.12. For non-default treatment, see 8.").  It 
feels to me as though decimal -> binary conversions should follow the same 
pattern.

--

___
Python tracker 

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

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

[STINNER Victor]

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 

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

[issue15512] Correct __sizeof__ support for parser

[Roundup Robot]

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 parser
http://hg.python.org/cpython/rev/91884d04de06

New changeset f7248550059c by Jesus Cea in branch 'default':
MERGE: Closes #15512: Correct __sizeof__ support for parser
http://hg.python.org/cpython/rev/f7248550059c

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Antoine Pitrou]

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 silence them.

> 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 very
productive, especially if it's only done in a single pair of macros.
If we think that implicit type conversions are too laxist, we should
probably use a different set of compiler options.

--

___
Python tracker 

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

[issue15469] Correct __sizeof__ support for deque

[Roundup Robot]

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
http://hg.python.org/cpython/rev/b0725c1b3068

New changeset b80a780514dd by Jesus Cea in branch 'default':
MERGE: Closes #15469: Correct __sizeof__ support for deque
http://hg.python.org/cpython/rev/b80a780514dd

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue15512] Correct __sizeof__ support for parser

[Antoine Pitrou]

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 

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

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

[Ross Lagerwall]

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 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Steven D'Aprano]

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.isnan are going through __float__,
> we can't keep everyone happy here.

Is it necessarily a given that math.isnan *must* go through __float__? If it 
were written in Python, it would be a simple matter of including

if isinstance(x, Decimal) and x.isnan(): return True

before the conversion to float. By I have no idea whether that is practical in 
the math module.

> The question for me is really what __float__ should do.  IEEE 754 doesn't
> help here, since it doesn't cover decimal floating-point<->  binary
> floating-point conversions.

Until such time that floats officially support snans, I think ValueError is 
the right behaviour.

--

___
Python tracker 

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

[issue15512] Correct __sizeof__ support for parser

[Serhiy Storchaka]

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 

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

[issue15473] importlib no longer uses imp.NullImporter

[Brett Cannon]

Changes by Brett Cannon :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue15512] Correct __sizeof__ support for parser

[Serhiy Storchaka]

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 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Mark Dickinson]

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 
with floats.  *Some* of the math module functions have been made more generic, 
like floor and ceil (which look for special __floor__ and __ceil__ methods), 
but isnan isn't one of those:  like most of the math module functions, it 
simply converts whatever it's given to float, then passes it on to the system 
library and returns whatever it gets back.

Changing that would be feature request targeted at 3.4 or later;  I'm not 
saying that it shouldn't be considered, but it doesn't belong in this issue.

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Ondřej Čertík]

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 testing some byte swapping 
issues and they do produce an invalid unicode in the process --- this is a bug 
and we need to fix it in NumPy.

--

___
Python tracker 

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

[issue15512] Correct __sizeof__ support for parser

[Roundup Robot]

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.org/cpython/rev/0bda3f00b60a

New changeset 593eba5e867c by Jesus Cea in branch 'default':
MERGE: #15512: Remove remnants of debugging code
http://hg.python.org/cpython/rev/593eba5e867c

New changeset c5bf5a82a3f2 by Jesus Cea in branch '2.7':
#15512: Declarations reorganization
http://hg.python.org/cpython/rev/c5bf5a82a3f2

--

___
Python tracker 

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

[issue15513] Correct __sizeof__ support for pickle

[Serhiy Storchaka]

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 

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

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

[R. David Murray]

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 I can check on it this weekend.

--

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Antoine Pitrou]

Antoine Pitrou added the comment:

Why not add a is_nan() method to float numbers instead?

--
nosy: +pitrou

___
Python tracker 

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

[issue15512] Correct __sizeof__ support for parser

[Serhiy Storchaka]

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 

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

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

[R. David Murray]

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 

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

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

[R. David Murray]

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 

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

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

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Ondřej Čertík]

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 

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

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

[Cory Mintz]

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.

  Major changes between OpenSSL 0.9.8l and OpenSSL 0.9.8m:
  ...
  o Support for RFC5746 TLS renegotiation extension.
  ...
  Major changes between OpenSSL 0.9.8k and OpenSSL 0.9.8l:

  o Temporary work around for CVE-2009-3555: disable renegotiation.

Can the OpenSSL version be updated to at least OpenSSL 0.9.8m so renegotiation 
is supported?

--
components: Windows
messages: 167336
nosy: cory.mintz
priority: normal
severity: normal
status: open
title: openssl version in windows builds does not support renegotiation
type: enhancement
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15550] Trailing white spaces

[Serhiy Storchaka]

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 source file, their presence 
I believe mistake. Easier once we remove all spaces and then prevent the 
appearance of new, than constantly face to unrelated changes. I'm not attaching 
a patch (it is too big, over 5 MB), anyone can create it by the following 
commands:

hg status -cn | tr '\n' '\0' | xargs -0 sed -i -re 's/[ \t]+$//'

It would be good if the Mercurial would had hook, which automatically remove 
trailing spaces or prohibit to commit patches that contain trailing spaces.

--
messages: 167337
nosy: storchaka
priority: normal
severity: normal
status: open
title: Trailing white spaces
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Travis Oliphant]

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 native machine
> 
> So is there ever a need to byte-swap Unicode strings? I can see how *numeric*
> data are stored using the internal representation on disk; this is a common
> technique. For strings, there is the notion of encodings which makes the
> relationship between internal and disk representations. So if NumPy applies
> the numeric concept to string data, then this is a flaw.

Apologies for not using correct terminology.   I had to spend a lot of time 
getting to know Unicode when I wrote NumPy, but am rusty on the key points and 
so I may communicate incorrectly.   The NumPy representation of Unicode strings 
is always UTF-32BE or UTF-32LE (depending on the data-type of the array).
The question is what to do when extracting this data into an array-scalar 
(which for Unicode objects has exactly the same representation as a 
PyUnicodeObject).  In fact, the NumPy Unicode array scalar is a C-sub-type of 
PyUnicodeObject and inherits from both the PyUnicodeObject and the NumPy 
"Character" interface --- a likely rare example of dual-inheritance at the 
C-level.  

> 
> It may be that people really do store text data in the same memory blob
> as numeric data and dump it to a file, but they really should think of this
> data as "UTF-16-BE" or "UTF-32-LE" and the like, not in terms of byte  
> swapping.
> You can use PyUnicode_Decode to create a Unicode object given a void*,
> a length, and a codec name. The concept "native Unicode representation"
> does not exist - people use all of two-byte, four-byte and UTF-8  
> representations
> in memory, on a single processor architecture and operating system.

I understand all the representations of Unicode data.   There is, however, a 
native byte-order and that's what I was talking about. 

> 
>> The byte-swapping must be done prior to conversion to a Python  
>> Unicode-Object when selecting data out of the array.
> 
> So if the byte swapping is done before the Unicode object is created:
> why did Dave and Ondřej run into problems then?

There were at least  2 issues:   1) a bad test that was written by someone who 
didn't understand you shouldn't have "byte-swapped" unicode strings as 
"strings" and 2) a mis-understanding of what was happening going from the data 
stored in a NumPy array and the Python "scalar" object that was being created.  
 
.
Thank you for your explanations.   It's very helpful.   Also, thank you for the 
PEP and improvements in Python 3.3.   The situation is *much* nicer now as 
NumPy is doing all kinds of hackery to support both narrow and wide builds.
This hackery could likely be improved even pre Python 3.3, but it's more clear 
how to handle the situation now in Python 3.3

> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +loewis

___
Python tracker 

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

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

[Jesús Cea Avión]

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

___
Python tracker 

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

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

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
stage:  -> patch review

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Jason Baker]

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: Unit tests that return generators silently fail
versions: Python 2.7

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I think this is a bug.

Do you have any argument?

--

___
Python tracker 

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

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

[Larry Hastings]

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 

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

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

[Dominique Leuenberger]

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, with a set of commonly used 
applications translations bundled in one 'Please translate my system to LANG' 
RPM. Again: for the Live CD, we do bundle a limited set of language files (thus 
installing a subset of all .mo files provided by all packages).

=> now as rpm does not like a file at the same location to be owned by two 
packages, the bundle-lang- package 'moves' it's own .mo files to 
/usr/share/locale-bundle, wheras the -lang rpm installs the .mo files 
under /usr/share/locale (default path).

Now, the issue is gettext.py checks the path proposed by the calling app using 
bindtextdomain(domain,[path]).

If path is defined, it's being used, otherwise /usr/share/locale is being used.

The attached patch extends the logic to:
- If path is being used
  - If path = _default_localedir
- Check for .mo in _default_bundlelocaledir
- if not found in bundle, check in _default_localedir
  - Use path
- if path is not defined
  - use _default_bundlelocaledir
- if not found, use _default_localedir

=> so in any case, if default_bundlelocaledir is not used, it falls back to 
_default_localedir, and as such I'd argue is unintrusive and keeping the patch 
in upstream codebase (instead of downstream package) would make sense.

Best regards,

--
components: Library (Lib)
files: python-bundle-lang.patch
keywords: patch
messages: 167343
nosy: Dominique.Leuenberger
priority: normal
severity: normal
status: open
title: gettext: if looking for .mo in default locations, also look in 
locale-bundle location
versions: Python 2.7
Added file: http://bugs.python.org/file26679/python-bundle-lang.patch

___
Python tracker 

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

[issue15464] ssl: add set_msg_callback function

[Antoine Pitrou]

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).

--
stage:  -> patch review

___
Python tracker 

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

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

[Georg Brandl]

Georg Brandl added the comment:

Victor: try "make changes".

--

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Stefan Krah]

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
InvalidOperation like with Decimal('snan').to_integral(), but that's
probably confusing in the context of the math module.

--

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Stefan Krah]

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.

--

___
Python tracker 

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

[issue15544] math.isnan fails with some Decimal NaNs

[Antoine Pitrou]

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 construction get an
implementation that's correct for x's type. If x is a float, it would
obviously re-use math.isnan() (or have a similar implementation).

--

___
Python tracker 

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

[issue15550] Trailing white spaces

[Serhiy Storchaka]

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 

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

[issue15550] Trailing white spaces

[Ned Deily]

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 before they are pushed.

--
nosy: +ned.deily

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Ned Deily]

Changes by Ned Deily :


--
nosy: +ezio.melotti, michael.foord

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Michael Foord]

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: open -> closed

___
Python tracker 

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

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

[Ethan Furman]

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 

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

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

[Ethan Furman]

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 

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

[issue15551] Unit tests that return generators silently fail

[Jason Baker]

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 
an error to have a generator function as a test method, the test I gave should 
fail.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

> an empty list is not a list of lines

Really?

>>> "".splitlines()
[]

--

___
Python tracker 

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

[issue15550] Trailing white spaces

[Antoine Pitrou]

Antoine Pitrou added the comment:

Or you can use "make patchcheck" which will (hopefully) warn you of such issues.

--
nosy: +pitrou

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Michael Foord]

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 

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

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

[Ethan Furman]

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 

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

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

[Ethan Furman]

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('   ')
[]

So if you have code that loops over the return and prints it out:

for line in wrap(blah):
 print(line)

you will have different output with [] than with [''].

--

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Jason Baker]

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 

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

[issue15551] Unit tests that return generators silently fail

[Michael Foord]

Michael Foord added the comment:

It's the expected behaviour according to the unittest specification.

--

___
Python tracker 

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

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

[Antoine Pitrou]

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.
Whether or not split() behaves differently is irrelevant.

> So if you have code that loops over the return and prints it out:
> 
> for line in wrap(blah):
>  print(line)
> 
> you will have different output with [] than with [''].

Indeed, which is a good reason *not* to change textwrap.wrap's
behaviour. The current behaviour is as reasonable as any other, and
changing it would break compatibility.

--

___
Python tracker 

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

[issue15551] Unit tests that return generators silently fail

[Jason Baker]

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 

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

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

[STINNER Victor]

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 

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

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

[Ethan Furman]

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 empty list, therefore textwrap.wrap() is not exotic in its behaviour.
> Whether or not split() behaves differently is irrelevant.

Not at all -- it's a warning to think "Why does this shortcut function 
exist?  How is it different?"  Something I will pay more attention to.  ;)

>> So if you have code that loops over the return and prints it out:
>>
>> for line in wrap(blah):
>>  print(line)
>>
>> you will have different output with [] than with [''].
> 
> Indeed, which is a good reason *not* to change textwrap.wrap's
> behaviour. The current behaviour is as reasonable as any other, and
> changing it would break compatibility.

For an empty string, sure -- for a string with nothing but white space, no:

--> wrap('   ')
[]
--> ''.splitlines()
['']

--

___
Python tracker 

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

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

[Antoine Pitrou]

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 of lines. That's perfectly logical.

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Martin v . Löwis]

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 very
> productive, especially if it's only done in a single pair of macros.

What do you disagree with? That "combining different types in MIN and MAX
is flawed"? Or that "asking for an explicit cast is not asking too much"?

Whether or not the patch is an appropriate measure is only the second
question - what I said is that the kind of code that it detects is indeed
flawed. If you disagree, can you kindly give an example where mixing types
in min and max would be legitimate?

For the specific case of mixing signed and unsigned, there is wide-spread
agreement that people should avoid it, and some compilers detect the flawed
code quite well. Some cases are defined to have undefined behavior; other
cases do have well-defined behavior, but many C developers are unaware of
what the exact semantics is.

Mixing integers with pointers is already detected by compilers sufficiently.

Mixing integers with floating point isn't really an issue in Python's
source code, so I don't worry about this.

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Antoine Pitrou]

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 seem very
> > productive, especially if it's only done in a single pair of macros.
> 
> What do you disagree with? That "combining different types in MIN and MAX
> is flawed"? Or that "asking for an explicit cast is not asking too much"?

The former. If C allows it then what's the point of special-casing
Py_MIN and Py_MAX to disallow it? It will only catch a very small
fraction of cases anyway.

Again, if this is a serious issue (which I don't think it is), it would
be better handled by choosing the appropriate compiler options.

--

___
Python tracker 

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

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

[Nadeem Vawda]

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, it needs to read more of the compressed stream to make progress.

It would seem that BZ2File cannot satisfy the contract of the read1() method - 
we
can't guarantee that a single call to the read() method of the underlying file 
will
allow us to return a non-empty result, whereas returning b"" is reserved for the
case where we have reached EOF.

Simply removing the read1() method would simply trade this problem for a bigger 
one
(resurrecting issue 10791), so I propose amending BZ2File.read1() to make as 
many reads
from the underlying file as necessary to return a non-empty result.

Antoine, what do you think of this?

--
nosy: +pitrou

___
Python tracker 

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

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

[Antoine Pitrou]

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 there is still data 
available is wrong.

--

___
Python tracker 

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

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

[Chris Jerdonek]

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 left with an empty text, meaning 
> an empty list of lines. That's perfectly logical.

I wouldn't say that it is "perfectly" logical.  String methods that drop 
characters from the beginning or end of a string return an empty string for 
empty text.

>>> "   ".strip()
''

> Furthermore, by "fixing" this, you may break existing software.

Issue 1859 is an arguably larger change that will also break existing software, 
and that issue has been kept open.

One scenario to consider: if we agree to fix issue 1859 in some versions, might 
that change whether we should address this issue in those versions as well?

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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

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

[Antoine Pitrou]

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 whitespace is as much trailing as
leading, after all :)

> I wouldn't say that it is "perfectly" logical.  String methods that
> drop characters from the beginning or end of a string return an empty
> string for empty text.
> 
> >>> "   ".strip()
> ''

I'm not sure I see the relevance. strip() returns an empty string
because its return type is a string, what else could it return?

> > Furthermore, by "fixing" this, you may break existing software.
> 
> Issue 1859 is an arguably larger change that will also break existing
> software, and that issue has been kept open.

Agreed. I'm gonna post on that issue too.

--

___
Python tracker 

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

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

[Antoine Pitrou]

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 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Martin v . Löwis]

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 compilers do raise signals in the cases
where they are allowed to.

I'd rather not have code in the Python implementation that raises
implementation-defined signals on some systems and gives
implementation-defined results on other systems.

> Again, if this is a serious issue (which I don't think it is)

I agree.

> it would be better handled by choosing the appropriate compiler options.

It might well be that this *is* the appropriate compiler option (even
though it's not a compiler command line flag, but a compiler language
extension).

In any case, there seems to be agrement that this is not a serious
issue (Victor said he didn't catch any new errors when using this),
so I'm rejecting the patch.

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

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

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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