[issue1146] TextWrap vs words 1-character shorter than the width

[Quentin Gallet-Gilles]

Quentin Gallet-Gilles added the comment:

The bug is present in trunk and has been there since rev 33955. This
revision contained a fix to an infinite loop when indentation was set
longer than width with long word breaking enabled. In that case, it
would strip off at least one character on every pass. The fix was
however a bit too general, leading to the reported bug.

The added patch makes sure this doesn't happen anymore when indentation
isn't involved.

--
nosy: +quentin.gallet-gilles

__
Tracker <[EMAIL PROTECTED]>

__Index: Lib/textwrap.py
===
--- Lib/textwrap.py	(revision 58153)
+++ Lib/textwrap.py	(working copy)
@@ -173,7 +173,12 @@
 Handle a chunk of text (most likely a word, not whitespace) that
 is too long to fit in any line.
 """
-space_left = max(width - cur_len, 1)
+# Figure out when indent is larger than the specified width, and make
+# sure at least one character is stripped off on every pass
+if self.width > width:
+space_left = max(width - cur_len, 1)
+else:
+space_left = width - cur_len
 
 # If we're allowed to break long words, then do so: put as much
 # of the next chunk onto the current line as will fit.
Index: Lib/test/test_textwrap.py
===
--- Lib/test/test_textwrap.py	(revision 58153)
+++ Lib/test/test_textwrap.py	(working copy)
@@ -398,6 +398,19 @@
  '   o'],
 subsequent_indent = ' '*15)
 
+# bug 1146.  Prevent a long word to be wrongly wrapped when the
+# preceding word is exactly one character shorter than the width
+self.check_wrap(self.text, 12,
+['Did you say ',
+ '"supercalifr',
+ 'agilisticexp',
+ 'ialidocious?',
+ '" How *do*',
+ 'you spell',
+ 'that odd',
+ 'word,',
+ 'anyways?'])
+
 def test_nobreak_long(self):
 # Test with break_long_words disabled
 self.wrapper.break_long_words = 0
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1146] TextWrap vs words 1-character shorter than the width

[Quentin Gallet-Gilles]

Quentin Gallet-Gilles added the comment:

The previous patch is suboptimal and doesn't solve all cases. This one
does. My apologies.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1146] TextWrap vs words 1-character shorter than the width

[Quentin Gallet-Gilles]

Changes by Quentin Gallet-Gilles:


__
Tracker <[EMAIL PROTECTED]>

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

[issue1146] TextWrap vs words 1-character shorter than the width

[Georg Brandl]

Georg Brandl added the comment:

I'll look at this shortly.

--
assignee:  -> georg.brandl
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1159] os.getenv() not updated after external module uses C putenv()

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

> Robert Ancell added the comment:
>
> draghuram, unfortunately while os.putenv() can be fixed to be
> symmetrical any putenv call from a C module cannot, for example:

Hi Robert, I understood the problem from your very first report. I
brought up putenv() not updating os.environ only because you mentioned
in the original report that it does. All you need is a way to get the
current value of an environment variable. The situation is a bit
complicated since a cache is in the picture (os.environ). I would
suggest that you bring up the topic for discussion on python-dev and
once a consensus is reached, some one can come up with a patch (I can
try).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1164] tp_print slots don't release the GIL

[Armin Rigo]

New submission from Armin Rigo:

The tp_print slots, used by 'print' statements, don't release the GIL
while writing into the C-level file.  This is not only a missing
opportunity, but can cause unexpected deadlocks, as shown in the
attached file.

--
components: Interpreter Core
files: deadlock1.py
messages: 55913
nosy: arigo
severity: normal
status: open
title: tp_print slots don't release the GIL
type: behavior

__
Tracker <[EMAIL PROTECTED]>

__import thread, os

read_fd, write_fd = os.pipe()
fread = os.fdopen(read_fd, 'rb')
fwrite = os.fdopen(write_fd, 'wb')

def writer():
print >> fwrite, range(10)
fwrite.flush()

thread.start_new_thread(writer, ())
line = fread.readline()
assert line == str(range(10)) + '\n'
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

[Guido van Rossum]

Guido van Rossum added the comment:

> Should it really, even if the bytes is ascii-encodable?

Yes, really.  We don't want to open up the same can of worms that made
working with Unicode such a pain in 2.x.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest

[Guido van Rossum]

Guido van Rossum added the comment:

This is a good start, but I think that instead of using global variables
and functions, you should try to turn all those into instance variables
(of the ThreadTest class).  That way the tests are truly independent. 
Initialization should be taken care of in setUp().

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1160] Medium size regexp crashes python

[Guido van Rossum]

Guido van Rossum added the comment:

/F?

--
assignee:  -> effbot
nosy: +effbot, gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1156] Suggested change to _exit function description in os module documentation

[Guido van Rossum]

Guido van Rossum added the comment:

> Should "child" be replaced with "parent"?

No.  I'm pretty much I wrote that.  The use case I was thinking of is
the error handling in the child process after the exec fails.  if you
were to use sys.exit() there, which raises SystemExit, you're likely to
hit various exception handlers that were set up in the parent, and you
even run the risk of some main loop continuing *in the child*.  I've had
many a program produce the phenomenon of "double tracebacks" due to this
mistake.

OTOH, in the parent, if you want to exit after forking (e.g. to create a
parent-less daemon process), a regular sys.exit() is usually just fine,
as any exception handlers you might trigger were meant to be triggered.

--
nosy: +gvanrossum
resolution:  -> rejected
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1161] Garbled chars in offending line of SyntaxError traceback

[Guido van Rossum]

Guido van Rossum added the comment:

I can't quite reproduce this, but I do see there's a problem with the
syntax error reporting:

Python 3.0a1 (py3k, Sep 12 2007, 12:23:06) 
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> asd asd
  File "", line 1
>>>

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777530] ctypes on Solaris

[Thomas Heller]

Thomas Heller added the comment:

Fixed in SVN: trunk rev 58155, release25-maint rev 58158.
Thanks.

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

_
Tracker <[EMAIL PROTECTED]>

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

[issue1164] tp_print slots don't release the GIL

[Brett Cannon]

Brett Cannon added the comment:

I quickly handled the GIL for lists and ints in their tp_print functions
and your example still deadlocked.  Don't have time to dig deeper right
now, but what more are you suggesting be done?

--
nosy: +brett.cannon

__
Tracker <[EMAIL PROTECTED]>

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

[issue1156] Suggested change to _exit function description in os module documentation

[Johann Tonsing]

Johann Tonsing added the comment:

Thanks for explaining.

(FWIW I reported this because several examples / recipes I saw elsewhere 
on the net used os._exit() in the parent.  Perhaps they did this because 
they don't want to disrupt resources like file descriptors which the 
child has inherited or something.)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1099] Mac compile fails with pydebug and framework enabled

[Humberto Diogenes]

Humberto Diogenes added the comment:

I'm using these versions:
intel: macosx 10.4.10, xcode 2.4.1 (gcc 4.0.1 build 5367)

Tried again with current revision (58153) and with --enable-universalsdk 
it built just fine. Without it, I still get the same error.

__
Tracker <[EMAIL PROTECTED]>

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

[issue542314] long file name support broken in windows

[Mark Hammond]

Mark Hammond added the comment:

I can confirm the code in question was removed and that long filenames
are possible in 2.5.  Eg:

import os
p = "?\\" + os.getcwdu()
for i in range(10):
p = os.path.join(p, 'x' * 100)
os.mkdir(p)
os.stat(p)
print len(p)

I don't think Python should try and hide this madness, so I'm marking it
as closed.

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


Tracker <[EMAIL PROTECTED]>


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

[issue1135] xview/yview of Tix.Grid is broken

[Hirokazu Yamamoto]

Changes by 
Hirokazu Yamamoto
:


--
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1772851] Decimal and long hash, compatibly and efficiently

[Mark Dickinson]

Mark Dickinson
 added the comment:

Here's a revised patch, that only touches longobject.c and does the minimum 
necessary to alter long.__hash__ from being *almost* completely predictable to 
being completely predictable.  To summarize the effects of this patch:

 - the current long.__hash__ is predictable except for a very small number of 
(unpredictable) inputs;  this patch makes it predictable for all inputs, 
thereby 
making it possible to define an efficient Decimal.__hash__.  To be precise, the 
patched long.__hash__ has the property that it's periodic of period ULONG_MAX 
in 
the ranges [1, infinity) and (-infinity, -1].

 - the value of hash(n) is unchanged for any n that's small enough to be 
representable as an int, and also unchanged for the vast majority of long 
integers n of reasonable size.  (For integers up to 450 digits long, the new 
hash 
value differs from the old for around 1 in every 2500 integers on a 32-bit 
system;  on a 64-bit system the figure is 1 in every 1 billion.)

 - On my test system (Dual Xeon 2.8GHz/SuSE Linux 10.2/gcc 4.1), using
timeit.timeit('hash(n)') there's no measurable slowdown for small integers.  
Unfortunately there *is* slowdown for larger integers:  around 20% slowdown for 
100 digit integers and around 70% extra time for 1000 digit integers, though in 
all cases the times are in fractions of a microsecond.  It doesn't help that 
gcc 
doesn't optimize the inner loop perfectly:  with the -O3 flag, the addition and 
subsequent correction are compiled to (with x in eax and v->ob_digit[i] in edx):

addl%eax, %edx
cmpl%eax, %edx
adcl$0, %edx

and the cmpl here is entirely redundant.  Maybe there's some way of writing the 
C 
code that makes it easier for gcc to pick up on this optimization?

_
Tracker <[EMAIL PROTECTED]>

_Index: Objects/longobject.c
===
--- Objects/longobject.c(revision 58158)
+++ Objects/longobject.c(working copy)
@@ -1937,10 +1937,18 @@
i = -(i);
}
 #define LONG_BIT_SHIFT (8*sizeof(long) - SHIFT)
+   /* The following loop produces a C long x such that (unsigned long)x
+  is congruent to the absolute value of v modulo ULONG_MAX.  The
+  resulting x is nonzero if and only if v is. */
while (--i >= 0) {
/* Force a native long #-bits (32 or 64) circular shift */
x = ((x << SHIFT) & ~MASK) | ((x >> LONG_BIT_SHIFT) & MASK);
x += v->ob_digit[i];
+   /* If the addition above overflowed (thinking of x as
+  unsigned), we compensate by incrementing.  This preserves
+  the value modulo ULONG_MAX. */
+   if ((unsigned long)x < v->ob_digit[i])
+   x++;
}
 #undef LONG_BIT_SHIFT
x = x * sign;
Index: Lib/test/test_hash.py
===
--- Lib/test/test_hash.py   (revision 58158)
+++ Lib/test/test_hash.py   (working copy)
@@ -18,10 +18,21 @@
 
 def test_numeric_literals(self):
 self.same_hash(1, 1L, 1.0, 1.0+0.0j)
+self.same_hash(0, 0L, 0.0, 0.0+0.0j)
+self.same_hash(-1, -1L, -1.0, -1.0+0.0j)
+self.same_hash(-2, -2L, -2.0, -2.0+0.0j)
 
 def test_coerced_integers(self):
 self.same_hash(int(1), long(1), float(1), complex(1),
int('1'), float('1.0'))
+self.same_hash(int(-2**31), long(-2**31), float(-2**31))
+self.same_hash(int(1-2**31), long(1-2**31), float(1-2**31))
+self.same_hash(int(2**31-1), long(2**31-1), float(2**31-1))
+# for 64-bit platforms
+self.same_hash(int(2**31), long(2**31), float(2**31))
+self.same_hash(int(-2**63), long(-2**63), float(-2**63))
+self.same_hash(int(1-2**63), long(1-2**63))
+self.same_hash(int(2**63-1), long(2**63-1))
 
 def test_coerced_floats(self):
 self.same_hash(long(1.23e300), float(1.23e300))
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1772851] Decimal and long hash, compatibly and efficiently

[Mark Dickinson]

Mark Dickinson
 added the comment:

And here's the updated decimal.__hash__ patch that goes with the 
long.__hash__ patch.

_
Tracker <[EMAIL PROTECTED]>

_Index: Lib/decimal.py
===
--- Lib/decimal.py  (revision 58158)
+++ Lib/decimal.py  (working copy)
@@ -770,10 +770,17 @@
 if self._isnan():
 raise TypeError('Cannot hash a NaN value.')
 return hash(str(self))
-i = int(self)
-if self == Decimal(i):
-return hash(i)
-assert self.__nonzero__()   # '-0' handled by integer case
+if not self:
+return 0
+if self._isinteger():
+op = _WorkRep(self.to_integral_value())
+# to make computation feasible for Decimals with large
+# exponent, we use the fact that hash(n) == hash(m) for
+# any two nonzero integers n and m such that (i) n and m
+# have the same sign, and (ii) n is congruent to m modulo
+# 2**64-1.  So we can replace hash((-1)**s*c*10**e) with
+# hash((-1)**s*c*pow(10, e, 2**64-1).
+return hash((-1)**op.sign*op.int*pow(10, op.exp, 2**64-1))
 return hash(str(self.normalize()))
 
 def as_tuple(self):
Index: Lib/test/test_decimal.py
===
--- Lib/test/test_decimal.py(revision 58158)
+++ Lib/test/test_decimal.py(working copy)
@@ -910,6 +910,38 @@
 def test_hash_method(self):
 #just that it's hashable
 hash(Decimal(23))
+
+test_values = [Decimal(sign*(2**m + n))
+   for m in [0, 14, 15, 16, 17, 30, 31, 
+ 32, 33, 62, 63, 64, 65, 66]
+   for n in range(-10, 10)
+   for sign in [-1, 1]]
+test_values.extend([
+Decimal("-0"), # zeros
+Decimal("0.00"),
+Decimal("-0.000"),
+Decimal("0E10"),
+Decimal("-0E12"),
+Decimal("10.0"), # negative exponent 
+Decimal("-23.0"),
+Decimal("1230E100"), # positive exponent
+Decimal("-4.5678E50"),
+# a value for which hash(n) != hash(n % (2**64-1))
+# in Python pre-2.6
+Decimal(2**64 + 2**32 - 1),
+# selection of values which fail with the old (before
+# version 2.6) long.__hash__
+Decimal("1.634E100"),
+Decimal("90.697E100"),
+Decimal("188.83E100"),
+Decimal("1652.9E100"),
+Decimal("56531E100"),
+])
+
+# check that hash(d) == hash(int(d)) for integral values
+for value in test_values:
+self.assertEqual(hash(value), hash(int(value)))
+
 #the same hash that to an int
 self.assertEqual(hash(Decimal(23)), hash(23))
 self.assertRaises(TypeError, hash, Decimal('NaN'))
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com