[issue1580] Use shorter float repr when possible

[Noam Raphael]

Noam Raphael added the comment:

I think that we can give up float(repr(x)) == x across different
platforms, since we don't guarantee something more basic: We don't
guarantee that the same program doing only floating point operations
will produce the same results across different 754 platforms, because
in the compilation process we rely on the system's decimal to binary
conversion. In other words, using the current repr(), one can pass a
value x from platform A platform B and be sure to get the same value.
But if he has a python function f, he can't be sure that f(x) on
platform A will result in the same value as f(x) on platform B. So the
cross-platform repr() doesn't really matter.

I like eval(repr(x)) == x because it means that repr(x) captures all
the information about x, not because it lets me pass x from one
platform to another. For communication, I use other methods.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Christian Heimes]

Christian Heimes added the comment:

Tim Peters wrote:
> This has nothing to do with what will or won't satisfy me, either.  I'm
> happy with what Python currently does, which is to rely on #3 above. 
> That's explainable (what's hard about understanding "%.17g"?), and
> relies only on what the 754 standard requires.
> 
> There is no easy way around this, period.  If you're willing to give up
> on float(repr(x)) == x cross-754-platform in some cases (and are willing
> to be unable to spell out /which/ cases), then many easy alternates exist.
> 
> Maybe this is a missing fact:  I don't care whether float(repr(x)) == x.
>  It would, for example, be fine by me if Python used a plain %.8g format
> for str and repr.  But I'm not indulging wishful thinking about the
> difficulties in ensuring float(repr(x)) == x either ;-)

Time is right.

The only way to ensure that it works on all platforms is a full and
mathematical correct proof of the algorithm and all functions used by
the algorithms. In the mean time *we* are going to release Python 40k
while *you* are still working on the proof. *scnr* :)

I like to propose a compromise. The patch is about making the
representation of a float nicer when users - newbies and ordinary people
w/o mathematical background - work on a shell or do some simple stuff.
They want a pretty and short representation of

2.2
>>> "My value is %s" % (11./5.)
'My value is 2.2'

The latter already prints 2.2 without the patch but the former prints
2.2002 on my machine. Now here comes the interesting part.
In 2.6 the shell uses PyObject_Print and the tp_print slot to print a
float. We can overwrite the str() and tp_print slot to use the new
algorithm while keeping the old algorithm for repr().

Unfortunately the tp_print slot is no longer used in Python 3.0. It
could be resurrected for this purpose (object.c:internal_print()).

str(1.) -> new code
repr(1.) -> old and good representation
>>> 1. -> new code

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1648] add new function, sys.gettrace

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +patch
priority:  -> normal
type: behavior -> rfe

__
Tracker <[EMAIL PROTECTED]>

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

[issue1647] IDLE messes around with sys.exitfunc

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +py3k
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1600] str.format() produces different output on different platforms (Py30a2)

[Mark Summerfield]

Mark Summerfield added the comment:

On 2007-12-17, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> Hi Mark!
>
> In general the patch is fine but it has some small issues.
>
> * Your patches are all reversed. They remove (-) the new lines instead
> of adding (+) them. Why aren't you using svn diff > file.patch?

I didn't know about that. Have now used it.

> * You are mixing tabs with spaces. All 2.6 C files and most 3.0 C files
> are still using tabs.

Okay, have now switched to tabs.

> * You forgot about %f. For large values the format characters f and F
> are using the exponent display, too "%f" % 1e60 == '1e+60'

Good point; I now search for 'e' or 'E' in any number.

> * You cannot assume that char is unsigned. Use Py_CHARMAP(char) instead.
> I think that you can make the code more readable when you do format_char
> = tolower(Py_CHARMAP(format_char)); first.

I don't refer to format_char any more.

> * The code is not C89 conform. The standards dictate that you cannot
> declare a var in the middle of a block. New var must be declared right
> after the {

I didn't know that. I've now moved the variable declarations.

I've attached the diff you asked for, plus a diff for the test_float.py
file -- and I've done the changes in relation to 2.6 trunk since there's
nothing 3.0-specific.

Hope this is now okay.

Added file: http://bugs.python.org/file8983/pystrtod.c.diff
Added file: http://bugs.python.org/file8984/test_float.py.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Python/pystrtod.c
===
--- Python/pystrtod.c	(revision 59545)
+++ Python/pystrtod.c	(working copy)
@@ -238,6 +238,30 @@
 		}
 	}
 
+	/* Ensure that the exponent is at least 3 digits,
+	   providing the buffer is large enough for the extra zeros. */
+	p = buffer;
+	while (*p && *p != 'e' && *p != 'E')
+		++p;
+	if (*p && (*(p + 1) == '-' || *(p + 1) == '+')) {
+		char *start = p + 2;
+		int exponent_digit_count = 0;
+		int zeros = 0;
+		p += 2;
+		while (*p && isdigit((unsigned char)*p)) {
+			++p;
+			++exponent_digit_count;
+		}
+		zeros = 3 - exponent_digit_count;
+		if (exponent_digit_count && zeros > 0 &&
+		start + zeros + exponent_digit_count + 1
+		< buffer + buf_len) {
+			p = start;
+			memmove(p + zeros, p, exponent_digit_count + 1);
+			memset(p, '0', zeros);
+		}
+	}
+
 	return buffer;
 }
 

Index: Lib/test/test_float.py
===
--- Lib/test/test_float.py	(revision 59545)
+++ Lib/test/test_float.py	(working copy)
@@ -129,12 +129,29 @@
 floats_file.close()
 
 
+class StrFormatETestCase(unittest.TestCase):
+def test_str_format_e(self):
+self.assertEqual("1.234e+009", "%.3e" %1.23405e+9)
+self.assertEqual("1.234e-009", "%.3e" %1.23405e-9)
+self.assertEqual("1.234E+009", "%.3E" %1.23405e+9)
+self.assertEqual("1.234E-009", "%.3E" %1.23405e-9)
+self.assertEqual("1.234e+027", "%.3e" %1.23405e+27)
+self.assertEqual("1.234e-027", "%.3e" %1.23405e-27)
+self.assertEqual("1.234E+027", "%.3E" %1.23405e+27)
+self.assertEqual("1.234E-027", "%.3E" %1.23405e-27)
+self.assertEqual("1.234e+132", "%.3e" %1.23405e+132)
+self.assertEqual("1.234e-132", "%.3e" %1.23405e-132)
+self.assertEqual("1.234E+132", "%.3E" %1.23405e+132)
+self.assertEqual("1.234E-132", "%.3E" %1.23405e-132)
+
+
 def test_main():
 test_support.run_unittest(
 FormatFunctionsTestCase,
 UnknownFormatTestCase,
 IEEEFormatTestCase,
-#ReprTestCase
+#ReprTestCase,
+StrFormatETestCase,
 )
 
 if __name__ == '__main__':

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

[issue1648] add new function, sys.gettrace

[Brett Cannon]

Changes by Brett Cannon:


--
assignee:  -> brett.cannon

__
Tracker <[EMAIL PROTECTED]>

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

[issue1649] IDLE error: dictionary changed size during iteration

[Christian Heimes]

New submission from Christian Heimes:

This happens when I press on X to close idle:

c:\dev\python\trunk\PCbuild9>python ../Lib/idlelib/idle.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\dev\python\trunk\lib\lib-tk\Tkinter.py", line 1403, in __call__
return self.func(*args)
  File "c:\dev\python\trunk\lib\lib-tk\Tkinter.py", line 498, in callit
func(*args)
  File "c:\dev\python\trunk\lib\idlelib\PyShell.py", line 945, in close2
return EditorWindow.close(self)
  File "c:\dev\python\trunk\lib\idlelib\EditorWindow.py", line 825, in close
self._close()
  File "c:\dev\python\trunk\lib\idlelib\PyShell.py", line 961, in _close
EditorWindow._close(self)
  File "c:\dev\python\trunk\lib\idlelib\EditorWindow.py", line 841, in
_close
self.per.close()
  File "c:\dev\python\trunk\lib\idlelib\Percolator.py", line 20, in close
self.redir.close(); self.redir = None
  File "c:\dev\python\trunk\lib\idlelib\WidgetRedirector.py", line 43,
in close
for operation in self._operations:
RuntimeError: dictionary changed size during iteration

Windows XP, Python 2.6 trunk, Tcl 8.4.16 (corrected build).

--
assignee: kbk
components: IDLE, Windows
messages: 58730
nosy: kbk, tiran
priority: normal
severity: normal
status: open
title: IDLE error: dictionary changed size during iteration
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

[issue1580] Use shorter float repr when possible

[Raymond Hettinger]

Raymond Hettinger added the comment:

ISTM shorter repr's are inherently misleading and will make it more 
harder to diagnose why 1.1 * 3 != 3.3 or why round(1.0 % 0.1, 1) == 0.1 
which is *very* far-off of what you might expect. 

The 17 digit representation is useful in that it suggests where the 
problem lies.  In contrast, showing two numbers with reprs of different 
lengths will strongly suggest that the shorter one is exactly 
represented.  Currently, that is a useful suggestion, 10.25 shows as 
10.25 while 10.21 shows as 10.211 (indicating that the 
latter is not exactly represented).  If you start showing 1.1 as 1.1, 
then you've lost both benefits.

FWIW, I prefer the current 17 digit behavior, its speed, its cross-754 
round-trip guarantees, and it psychological cues about exactness.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1649] IDLE error: dictionary changed size during iteration

[Raymond Hettinger]

Changes by Raymond Hettinger:


--
priority: normal -> high

__
Tracker <[EMAIL PROTECTED]>

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

[issue1650] IDLE: help() displays output on the wrong shell

[Christian Heimes]

New submission from Christian Heimes:

On Python 3.0 IDLE shows the output of help() on the system shell that
started IDLE and not inside the IDLE window.

--
assignee: kbk
components: IDLE, Windows
messages: 58732
nosy: kbk, tiran
priority: normal
severity: normal
status: open
title: IDLE: help() displays output on the wrong shell
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1601] IDLE not working correctly on Windows (Py30a2/IDLE30a1)

[Christian Heimes]

Changes by Christian Heimes:


--
priority:  -> high
resolution:  -> fixed
status: open -> pending

__
Tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Noam Raphael]

Noam Raphael added the comment:

2007/12/18, Raymond Hettinger <[EMAIL PROTECTED]>:
> The 17 digit representation is useful in that it suggests where the
> problem lies.  In contrast, showing two numbers with reprs of different
> lengths will strongly suggest that the shorter one is exactly
> represented.  Currently, that is a useful suggestion, 10.25 shows as
> 10.25 while 10.21 shows as 10.211 (indicating that the
> latter is not exactly represented).  If you start showing 1.1 as 1.1,
> then you've lost both benefits.

Currently, repr(1.3) == '1.3', suggesting that it is exactly
represented, which isn't true. I think that unless you use an
algorithm that will truncate zeros only if the decimal representation
is exact, the suggested algorithm is less confusing than the current
one, in that it doesn't suggest that 1.3 is exactly stored and 1.1
isn't.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1629] Py_Size() should be named Py_SIZE()

[Christian Heimes]

Christian Heimes added the comment:

I tried a simple find | xargs sed replace and it worked well.

find -name '*.c' -or -name '*.h' -or -name '*.rst' | xargs sed -i
s/Py_Size\(/Py_SIZE\(/g

__
Tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Raymond Hettinger]

Raymond Hettinger added the comment:

Right, there are plenty of exceptions to the suggestion of exactness. 
Still, I find the current behavior to be more helpful than not 
(especially when trying to explain the examples I gave in the previous 
post).

I'm concerned that the tone of the recent discussion shows a strong 
desire to just get something checked-in despite dubious benefits and 
despite long standing invariants.

It is a bit cavalier to declare "we can give up float(repr(x)) == x 
across different platforms."  Our NumPy friends might not be amused. If 
a PEP on this were circulated, I'm sure we would receive some frank and 
specific feedback.

Likewise, I find it questionable that shorter reprs are helpful. Is 
there any evidence supporting that assertion?  My arguments above 
suggest short reprs are counter-productive because they mask the cause 
of problems that might otherwise be self-evident.  Of course, it's 
possible that both could be true, short reprs may help in some cases 
(by masking oddities) and may hurt in other cases (by masking the 
underlying cause of an oddity or by making a false psychological 
suggestion).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1601] IDLE not working correctly on Windows (Py30a2/IDLE30a1)

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I don't think this check is necessary.

Some users may want to target specific windows versions, and compile
their own modules with a higher WINVER.
OTOH, python.org should compile with WINVER=0x0500, so that distributed
binaries can run on most win32 platforms.

--
priority: high -> 
resolution: fixed -> 
status: pending -> open

__
Tracker <[EMAIL PROTECTED]>

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

[issue1623] Implement PEP-3141 for Decimal

[Facundo Batista]

Facundo Batista added the comment:

The PEP is not approved yet. This look interesting, will take a look
again in the future after the PEP approval.

Thanks for the work!

Regards,

--
resolution:  -> postponed
status: open -> pending

__
Tracker <[EMAIL PROTECTED]>

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

[issue1631035] SyntaxWarning for backquotes

[Christian Heimes]

Christian Heimes added the comment:

Warnings for <> and `` were added a while ago.

--
nosy: +tiran
resolution:  -> out of date
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

[issue1337] Tools/msi/msi.py does not work with PCBuild8

[Christian Heimes]

Christian Heimes added the comment:

Python 2.6 and 3.0 are using PCbuild9.

--
resolution: later -> out of date
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

[issue1565037] use LSB version information to detect a platform

[Christian Heimes]

Christian Heimes added the comment:

An user has written a parser for the LSB files in /etc/ for the GHOP
project. It will be merged soon.

--
nosy: +tiran
resolution:  -> out of date
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

[issue1675118] Epoll wrapper

[Christian Heimes]

Christian Heimes added the comment:

I think it's a very useful addition to the select module. But I see a
license problem. Have you written the tests and code yourself and are
you willing to relicense the code under the Python license?

--
nosy: +tiran
priority: normal -> high
type:  -> rfe
versions: +Python 3.0

_
Tracker <[EMAIL PROTECTED]>

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

[issue1669539] Change (fix!) os.path.isabs() semantics on Win32

[Christian Heimes]

Christian Heimes added the comment:

The problem should be addressed and fixed before the next alpha release.

--
nosy: +tiran
priority: normal -> high
type:  -> behavior
versions: +Python 3.0

_
Tracker <[EMAIL PROTECTED]>

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

[issue1651] Limit the max size of PyUnicodeObject->defenc?

[Christian Heimes]

New submission from Christian Heimes:

I think that the cached default encoding version of the unicode object
should be limited in size. It's probably a bad idea to cache a 100MB of
data. For large amount strings and unicode objects the user should do
explicit caching if required.

--
components: Interpreter Core
keywords: patch, py3k
messages: 58744
nosy: tiran
priority: high
severity: normal
status: open
title: Limit the max size of PyUnicodeObject->defenc?
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1590352] The "lazy strings" patch

[Christian Heimes]

Christian Heimes added the comment:

I'm raising the level to draw more attention to this featue. It should
either be considered for inclusion or closed.

--
nosy: +tiran
priority: normal -> high
type:  -> rfe

_
Tracker <[EMAIL PROTECTED]>

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

[issue1700467] stack size of python_d.exe on VC6

[Christian Heimes]

Christian Heimes added the comment:

Is the patch still required? VS 6 is old and we have moved to VC9 / VS 2008.

--
nosy: +tiran
resolution:  -> out of date
status: open -> pending

_
Tracker <[EMAIL PROTECTED]>

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

[issue1526367] str.__iter__ and unicode.__iter__

[Christian Heimes]

Christian Heimes added the comment:

Raymond, can this entry be closed? In py3k PyString and PyUnicode have
an iterator view.

--
components: +Interpreter Core -None
nosy: +tiran
resolution:  -> rejected
status: open -> pending

_
Tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Noam Raphael]

Noam Raphael added the comment:

About the educational problem. If someone is puzzled by "1.1*3 !=
3.3", you could always use '%50f' % 1.1 instead of repr(1.1). I don't
think that trying to teach people that floating points don't always do
what they expect them to do is a good reason to print uninteresting
and visually distracting digits when you don't have to.

About the compatibility problem: I don't see why it should matter to
the NumPy people if the repr() of some floats is made shorter. Anyway,
we can ask them, using a PEP or just the mailing list.

About the benefit: If I have data which contains floats, I'm usually
interested about their (physical) value, not about their last bits.
That's why str(f) does what it does. I like repr(x) to be one-to-one,
as I explained in the previous message, but if it can be made more
readable, why not make it so?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1641] asyncore delayed calls feature

[Daniel Arbuckle]

Changes by Daniel Arbuckle:


--
nosy: +djarb

__
Tracker <[EMAIL PROTECTED]>

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

[issue1640] Enhancements for mathmodule

[Mark Dickinson]

Mark Dickinson added the comment:

Unfortunately, implementing asinh, acosh, atanh correctly is not as simple as 
just using the formulas 
(this is one of the reasons that it's useful to be able to get at the library 
definitions).  For 
example, the formula

asinh(x) = log(x + sqrt(1.+(x*x)))

has significant error (i.e. much more than just a few ulps) when x is small (so 
that the argument of 
the log is close to 1), and when x is large and negative (so that the addition 
involves adding two 
numbers of almost equal magnitude but opposite sign).  It also overflows 
unnecessarily at around 
1e154 (on an IEEE754 system), as a result of the intermediate calculation x*x 
overflowing, and it 
fails to give the correct signs on zero arguments.  (asinh(0.) = 0., asinh(-0.) 
= -0.)

So either some serious work is required here, or code should be borrowed in an 
appropriately legal 
fashion from some other library, or those few people who don't have asinh, 
acosh, etc. already in 
libm will have to live without.

Mark

__
Tracker <[EMAIL PROTECTED]>

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

[issue1652] subprocess should have an option to restore SIGPIPE to default action

[Colin Watson]

New submission from Colin Watson:

On Unix, Python sets SIGPIPE to SIG_IGN on startup, because it prefers
to check every write and raise an IOError exception rather than taking
SIGPIPE. This is all well and good for Python itself. However,
non-Python Unix subprocesses generally expect to have SIGPIPE set to the
default action, since that's what will happen if they're started from a
normal shell. If this is not the case, then rather than taking SIGPIPE
when a write fails due to the reading end of a pipe having been closed,
write will return EPIPE and it's up to the process to check that. Many
programs are lazy and fail to check for write errors, but in the
specific case of pipe closure they are fine when invoked from a normal
shell because they rely on taking the signal. Even correctly written
programs that diligently check for write errors will typically produce
different (and confusing) output when SIGPIPE is ignored. For instance,
an example only very slightly adapted from one in the subprocess
documentation:

  $ dd if=/dev/zero of=bigfile bs=1024 seek=1 count=1
  1+0 records in
  1+0 records out
  1024 bytes (1.0 kB) copied, 0.000176709 seconds, 5.8 MB/s
  $ cat bigfile | head -n0
  $ cat t.py
  from subprocess import Popen, PIPE
  p1 = Popen(["cat", "bigfile"], stdout=PIPE)
  p2 = Popen(["head", "-n0"], stdin=p1.stdout, stdout=PIPE)
  output = p2.communicate()[0]
  $ python t.py
  cat: write error: Broken pipe

In some cases this problem can be much more significant. For instance,
it is very common for shell scripts to rely on SIGPIPE's default action
in order to behave correctly. A year or two ago I ran into this in OS
installer code I was writing in Python, which called some underlying
utility code in shell and C to deal with disk partitioning. In the event
that the Python code failed to handle an exception, the shell script
being run in a subprocess would spiral out of control rather than
cleanly exiting at the first sign of trouble. This actually caused
massive data loss on several testers' systems and required a quick
release to fix
(https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/40464 and
https://wiki.ubuntu.com/DapperBeta/PartitionTableCorruption). Now
obviously this was ultimately my fault for failing to catch the
exceptional condition in testing, but this misdesign in Python and the
lack of any documentation of this gotcha really didn't help at the time.
For the record, the fix was to call this in a preexec_fn:

  signal.signal(signal.SIGPIPE, signal.SIG_DFL)

This is an area of Unix that's very easy to get wrong. I've written my
own subprocess handling library in C for another project, and I still
found it non-trivial to track this down when it bit me. Since it
essentially arises due to an implementation detail of the Python
language, I think it should also be Python's responsibility to fix it up
when subprocesses are involved.

There are many ways to invoke subprocesses in Python, but the new,
all-singing, all-dancing one is of course the subprocess module. I think
it would be sufficient for that to do the right thing, or at least have
an option to do so, and it's certainly the easiest place to add the
option. I'm attaching a suggested patch which adds a restore_sigpipe
option and documents it in what seem to be all the relevant places.

Note that nearly all the examples end up with restore_sigpipe enabled.
In some future release of Python, I think this should be the default.
I'm not entirely familiar with migration plan processes in Python; how
should this be done?

--
components: Library (Lib)
files: subprocess-sigpipe.patch
messages: 58750
nosy: cjwatson
severity: normal
status: open
title: subprocess should have an option to restore SIGPIPE to default action
versions: Python 2.5
Added file: http://bugs.python.org/file8986/subprocess-sigpipe.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Doc/library/subprocess.rst
===
--- Doc/library/subprocess.rst	(revision 59547)
+++ Doc/library/subprocess.rst	(working copy)
@@ -30,7 +30,7 @@
 This module defines one class called :class:`Popen`:
 
 
-.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0)
+.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_sigpipe=False)
 
Arguments are:
 
@@ -112,6 +112,12 @@
underlying CreateProcess() function.  They can specify things such as appearance
of the main window and priority for the new process.  (Windows only)
 
+   On UNIX: If *restore_sigpipe* is true, :const:`SIGPIPE` will be rest

[issue1526367] str.__iter__ and unicode.__iter__

[Raymond Hettinger]

Changes by Raymond Hettinger:


--
status: pending -> closed

_
Tracker <[EMAIL PROTECTED]>

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

[issue1653] a couple of documentation issues

[Joseph Armbruster]

New submission from Joseph Armbruster:

I added an option to msi.py (and a support script) that allows the user
to optionally decompile the python30.chm post installation.  In doing
so, I was testing out help() from the interpreter and stumbled upon a
few things that I think are issues.  One of the ways I experimented, was
by typing the following commands at the interpreter, to see what I could
pull up on the global statement:
   help()
   keywords
   global

I had run into the following issues on my way.  Additional eyes /
insight would definitely be helpful.  Just a couple forewords:
- os.environ.get("PYTHONDOCS") returns 'C:\\Python30\\Doc'
- my version of the installer decompiled the Python30.chm as dictated by
pydoc.  So that, c:\Python30\Doc has folders c-api, data, distutils, etc..

If I missed anything basic with these, my apologies in advanced. 

Issue 1: PYTHONDOCS does not appear to be respected.

  * I generated python-3.0.13865.msi and installed
  * post-install I set PYTHONDOCS to C:\python30\doc
  * I fired up a new command prompt
  * Fire up Python3k interpreter and attempt the help() session listed
above.
  * I had to hack at pydoc.py, since the #windows statement never gets
reached.

join = os.path.join
if sys.platform=='win32':   #hack
self.docdir=join(execdir,'doc') #...
else:   #...
for dir in [os.environ.get('PYTHONDOCS'),
homedir and os.path.join(homedir, 'doc'),
join(execdir, 'doc'), # for Windows

Issue 2: pydoc.py class Helper member keywords contain several invalid
paths.  For instance:

'global': ('ref/global', 'NAMESPACES'),

Most of the keywords appear to have the ref/ prefixes.

Issue 3:  formatter.py will throw an exception within push_margin /
pop_margin on the lines where a len(fstack) is attempted.  The two lines
look like this:

self.writer.new_margin(margin, len(fstack))

I do not have a patch for this, since i'm still wandering about through
the whole installer generation stuffs.  When I get home, I will examine
further.

Thoughts?

--
components: Documentation, Windows
messages: 58751
nosy: JosephArmbruster, loewis, tiran
severity: normal
status: open
title: a couple of  documentation issues
type: crash
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1653] a couple of documentation issues

[Joseph Armbruster]

Joseph Armbruster added the comment:

I left out some important info and made a typo:

url: http://svn.python.org/projects/python/branches/py3k
rev: 59543

For Issue 1:  The two test ifs at lines 1674 and 1678 never are
satisfied, not the #windows statement never gets reached...

__
Tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Guido van Rossum]

Guido van Rossum added the comment:

[Tim: when I said "bugs" I just meant non-correct rounding. Sorry.]

On the educational issue: it's still embarrassingly easy to run into
situations where *arithmetic* using floats produces "educational"
results.  Simplest case I could find quickly: 0.1+0.2 != 0.3.

But I think this is separate from the more directly baffling

>>> 0.1
0.10001
>>> 

I propose the following set of changes:

(1) Get rid of doubledigits.c.  IMO it is evil because it uses static
global variables.

(2) Change pickle.py, cPickle.c and marshal.c to use "%.17g" instead of
repr.  This means that these serialization protocols are not affected by
incorrectly-rounding atof() implementations since the IEEE-754 standard
guarantees that 17 digits input will produce the correct value
regardless of rounding correctness.

(3) change repr(float) so as to use "%.16g" if the result roundtrips
using atof() and "%.17g" if not.  (*)

This means that platforms where atof() is not correctly rounding may
produce incorrect results when the input was produced by repr() -- even
when the repr() was run on a platform whose atof() rounds correctly, IIU
Tim correctly.  I'm okay with that.  It's still better than changing
repr() to always use %.16g or even %.12g, which would really turn the
educational issue into an educational nightmare, trying to explain why
two numbers both print the same but compare unequal (and God forbid
anyone proposes adding fuzz to float ==).

(*) If atof() is much slower than "%.17g", we could compute "%.17g" and
"%.16g" first and if they are the same string avoid the atof() call
altogether.  We could even avoid the "%.16g" if the "%17g" step produced
at least one (suppressed) trailing zero.  OTOH if atof() is about the
same speed as "%.17g" or faster, it makes more sense to try "%.16g" and
atof() first, and if this doesn't roundtrip, fall back to "%.17g".

__
Tracker <[EMAIL PROTECTED]>

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

[issue1642] segfault when deleting value member in ctypes types

[Thomas Heller]

Thomas Heller added the comment:

Fixed in rev. 59549 (trunk) and rev. 59550 (release25-maint).

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

[issue1646] Make socket support TIPC.

[Guido van Rossum]

Guido van Rossum added the comment:

I'm okay with adding this, it doesn't add much code and is properly
safeguarded by #ifdefs and has a configure.in patch.

I haven't reviewed the code though.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1651] Limit the max size of PyUnicodeObject->defenc?

[Guido van Rossum]

Guido van Rossum added the comment:

I don't see a patch. And I think you cannot do this without compromising
correctness, since _PyUnicode_AsDefaultEncodedString() returns the
cached value without incrementing its refcount.  (The only refcount that
keeps it alive is the cache entry.)

--
keywords:  -patch
nosy: +gvanrossum
priority: high -> normal
resolution:  -> rejected

__
Tracker <[EMAIL PROTECTED]>

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

[issue1629] Py_Size() should be named Py_SIZE()

[Guido van Rossum]

Changes by Guido van Rossum:


--
resolution:  -> accepted

__
Tracker <[EMAIL PROTECTED]>

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

[issue1631] Send output from subprocess.Popen objects to any object with a write() method

[Guido van Rossum]

Changes by Guido van Rossum:


--
status: pending -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1632] email cannot be imported

[Guido van Rossum]

Guido van Rossum added the comment:

Let's not waste time in the bug tracker debugging some user's broken
setup.  Let him contact Panda3D's customer support.

--
nosy: +gvanrossum
resolution:  -> invalid
status: pending -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1640] Enhancements for mathmodule

[Guido van Rossum]

Guido van Rossum added the comment:

i suggest abandoning any attempts at implementing math ourselves.  I
also suggest not combining this with #1635 but reviewing and
(eventually) applying the latter first.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Guido van Rossum]

Guido van Rossum added the comment:

Mostly looks good.  Here are some nits.

(1) You shouldn't have to add pystrcmp.c to the VC project files since
on Windows it isn't used, right?

(2) Will the Windows input routine still accept the *old*
representations for INF and NAN?  IMO that's important (a) so as to be
able to read old pickles or marshalled data, (b) so as to be able to
read data files written by C programs.

(3) Shouldn't you be using Py_HUGE_VAL instead of HUGE_VAL in the chunk
starting at line 187 in floatobject.c?

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1636] Execfile unable to take arguments beyond 255!

[Guido van Rossum]

Guido van Rossum added the comment:

This comes from line 1845 in ast.c.

It has nothing to do with execfile(), it's just a constraint on the
generated bytecode.

Fixing this would be quite complex, and referring to "this day and age"
isn't going to raise its priority.  However, I'd be happy to accept a
patch that does away with this limit or at least raises it considerably.

--
nosy: +gvanrossum
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

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

[issue1637] urlparse.urlparse misparses URLs with query but no path

[Guido van Rossum]

Guido van Rossum added the comment:

Would you mind submitting a proper patch for Python 2.5 and/or 2.6
generated by "svn diff" relative to an (anonymous) checkout, and adding
a unit test?  Then I'd be happy to accept this and if it makes it in
time for the 2.5.2 release we'll fix it there.

--
nosy: +gvanrossum
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1638] %zd configure test fails on Linux

[Guido van Rossum]

Guido van Rossum added the comment:

Please backport.

--
assignee:  -> tiran
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1641] asyncore delayed calls feature

[Guido van Rossum]

Guido van Rossum added the comment:

If you want attention, please post to python-dev if you didn't already.
 Or widen the audience to python-list if you want to.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1645] Fix socketmodule.c:sock_recvfrom_guts() comment.

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 59551.

--
nosy: +gvanrossum
resolution:  -> accepted
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

[issue1649] IDLE error: dictionary changed size during iteration

[Guido van Rossum]

Guido van Rossum added the comment:

You can fix this yourself:

 for operation in list(self._operations.keys()):

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1648] add new function, sys.gettrace

[Guido van Rossum]

Guido van Rossum added the comment:

Why not do the same for its cousin sys.setprofile()?

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1648] add new function, sys.gettrace

[Brett Cannon]

Brett Cannon added the comment:

On Dec 18, 2007 12:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum added the comment:
>
> Why not do the same for its cousin sys.setprofile()?

If Titus' code works out I was going to just copy it and tweak it for
profile functions.  Obviously if Titus wants to do that as well I
won't object.  =)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Tim Peters]

Tim Peters added the comment:

[Guido]
> ...
> (2) Will the Windows input routine still accept the *old*
> representations for INF and NAN?  IMO that's important (a) so as to be
> able to read old pickles or marshalled data, (b) so as to be able to
> read data files written by C programs.

Ha!  You're such an optimist ;-)  The remarkable truth is that Windows
has never been able to read its own representations for INF and NAN:

'1.#INF'
>>> float(_)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for float(): 1.#INF
>>> repr(nan)
'-1.#IND'
>>> float(_)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for float(): -1.#IND

This has nothing to do with Python -- same thing from C, etc.

--
nosy: +tim_one

__
Tracker <[EMAIL PROTECTED]>

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

[issue1654] HTTPSConnection is not IPv6-capable

[Derek Morr]

New submission from Derek Morr:

httplib.HTTPSConnection is not IPv6-capable, even though
httplib.HTTPConnection is. HTTPSConnection has its own connect() method
which does not call socket.getaddrinfo().

--
components: Library (Lib)
messages: 58769
nosy: dmorr
severity: normal
status: open
title: HTTPSConnection is not IPv6-capable
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1640] Enhancements for mathmodule

[Christian Heimes]

Christian Heimes added the comment:

Guido van Rossum wrote:
> Guido van Rossum added the comment:
> 
> i suggest abandoning any attempts at implementing math ourselves.  I
> also suggest not combining this with #1635 but reviewing and
> (eventually) applying the latter first.

How do you like a compromise? I rip out the new functions for the math
module except isnan(), isinf() and sign(). The new patch would contain
the inf and nan roundtrip plus the helper methods.

Mark is right. My naive functions are a numerical nightmare for small
and large numbers. I copied them from my math handbook 'cause I couldn't
find solid implementations in my numerical handbook. It contains all
sort of algorithms for approximations, ODE, PDE, FFT but no sample of
the inverse hyperbolic functions.

We could reuse the functions from the BSD libm. They are used in
numerous C runtime libraries (BSD, Mac OS X, uclibc).
http://packages.e.kth.se/common/src/os/NetBSD/1.3.2/lib/libm/src/

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Christian Heimes]

Christian Heimes added the comment:

Guido van Rossum wrote:
> (1) You shouldn't have to add pystrcmp.c to the VC project files since
> on Windows it isn't used, right?

It was the easiest way to test the functions in pystrcmp. Linux doesn't
have stricmp but it also doesn't require the additional code to mangle
1.#INF into inf.

> (2) Will the Windows input routine still accept the *old*
> representations for INF and NAN?  IMO that's important (a) so as to be
> able to read old pickles or marshalled data, (b) so as to be able to
> read data files written by C programs.

See Tim's answer.
Pickles and other C programs aren't an issue. Internally NaNs and INFs
are represented with a special bit pattern (all bits of the exponent are
set). As long as users don't use str() or repr() on floats it still
works. The pickle module uses struct.

> (3) Shouldn't you be using Py_HUGE_VAL instead of HUGE_VAL in the chunk
> starting at line 187 in floatobject.c?

I missed the spot, thanks.

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1638] %zd configure test fails on Linux

[Christian Heimes]

Christian Heimes added the comment:

Backported to 2.5 in r59552

--
status: pending -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1636] Execfile unable to take arguments beyond 255!

[Martin v. Löwis]

Martin v. Löwis added the comment:

While you can't modify the MIB, I'm sure it would be possible to change
the generator code that compiles the MIB into Python source code, to
work around the restrictions in the byte code.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1653] a couple of documentation issues

[Martin v. Löwis]

Martin v. Löwis added the comment:

I think it's bad to mix separate issues in a single report, as it makes
it difficult to track which of them had been resolved.

As for the paths - I am not surprised it is broken now, as pydoc hasn't
been updated ever since the documentation had been switched to rst (AFAICT).

As for uncompressing the documentation at installation time - I think
this is a bad idea. Instead, pydoc should properly open the chm file so
that it navigates to the right position directly. If you uncompresses,
it more-than-doubles the space, and you need to deal with removing the
files at uninstallation time.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1655] imaplib is not IPv6-capable

[Derek Morr]

New submission from Derek Morr:

imaplib.IMAP4 and IMAP4_SSL do not use IPv6-capable name resolution
APIs. Attached is a patch (lifted from httplib) that enables IPv6 in
their open() methods.

--
components: Library (Lib)
files: imaplib_ipv6.patch
messages: 58775
nosy: dmorr
severity: normal
status: open
title: imaplib is not IPv6-capable
versions: Python 2.5
Added file: http://bugs.python.org/file8987/imaplib_ipv6.patch

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1654] HTTPSConnection is not IPv6-capable

[Christian Heimes]

Changes by Christian Heimes:


--
assignee:  -> janssen
nosy: +janssen
priority:  -> normal
versions: +Python 2.6 -Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1649] IDLE error: dictionary changed size during iteration

[Christian Heimes]

Christian Heimes added the comment:

Thanks Guido, I didn't read the code before I created this bug report.

Fixed in r59554

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

[issue1655] imaplib is not IPv6-capable

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +patch
priority:  -> normal
type:  -> rfe
versions: +Python 2.6 -Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1654] HTTPSConnection is not IPv6-capable

[Bill Janssen]

Bill Janssen added the comment:

Considering that HTTPSConnection uses the exact same code as
HTTPConnection to interpret the specified address, I think we need more
diagnosis in order to determine whether this is a real issue or not.  If
it is, what's going wrong?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1627] Problem with httplib and Content-Length: -1

[Christian Heimes]

Christian Heimes added the comment:

Your proposed fixed is not correct:

length = self.msg.getheader("content-length")
if length and not self.chunked:
try:
self.length = int(length)
except ValueError:
pass
# patch
if self.length < 0:
self.length = None

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue1654] HTTPSConnection is not IPv6-capable

[Bill Janssen]

Changes by Bill Janssen:


--
assignee: janssen -> 

__
Tracker <[EMAIL PROTECTED]>

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

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Tim Peters]

Tim Peters added the comment:

Historical note:  Guido is probably thinking of "the old" pickle and
marshal here, which did have problems with inf and NaN on Windows (as in
they didn't work at all).  Michael Hudson changed them to use special
bit patterns instead, IIRC for Python 2.5.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Guido van Rossum]

Guido van Rossum added the comment:

I suggest you check this in (with the Py_HUGE_VAL fix) and then see how
much of #1640 we still need.

--
resolution:  -> accepted

__
Tracker <[EMAIL PROTECTED]>

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

[issue1653] a couple of documentation issues

[Joseph Armbruster]

Joseph Armbruster added the comment:

>I think it's bad to mix separate issues in a single report, as it makes
>it difficult to track which of them had been resolved.

Martin, agreed.  Please close this issue and I will generate new issues
(with patches) for each item as encountered.

> As for the paths - I am not surprised it is broken now, as pydoc 
> hasn't been updated ever since the documentation had been switched to 
> rst (AFAICT).

I will generate a new issues for these as well.

> As for uncompressing the documentation at installation time - I think
> this is a bad idea. Instead, pydoc should properly open the chm file 
> so that it navigates to the right position directly. If you
> uncompresses, it more-than-doubles the space, and you need to deal 
> with removing the files at un-installation time.

Ok, I just figured rather than the user go through the whole hh utility
manually, this could alleviate that.  Seems like your approach would
definitely save some space.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Guido van Rossum]

Guido van Rossum added the comment:

> Historical note:  Guido is probably thinking of "the old" pickle and
> marshal here, which did have problems with inf and NaN on Windows (as in
> they didn't work at all).  Michael Hudson changed them to use special
> bit patterns instead, IIRC for Python 2.5.

In pickle.py, protocol 0 (still the default in 2.6) uses repr(x) to
write a float and float(s) to convert that back to input. Maybe you're
thinking of marshal, which is more sophisticated.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1549] Regression with __hash__ definition and rich comparison operators

[Guido van Rossum]

Changes by Guido van Rossum:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1549] Regression with __hash__ definition and rich comparison operators

[Guido van Rossum]

Changes by Guido van Rossum:


--
priority: high -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1654] HTTPSConnection is not IPv6-capable

[Derek Morr]

Derek Morr added the comment:

My apologies. This should have been filed against Python 2.3. I see it
was fixed with checkin 54546. Go ahead and close this bug.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1583] Patch for signal.set_wakeup_fd

[Guido van Rossum]

Guido van Rossum added the comment:

Here's an updated patch that applies smoothly to the current trunk.

--
components: +Extension Modules
Added file: http://bugs.python.org/file8988/python2.6-set_wakeup_fd4.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Doc/library/signal.rst
===
--- Doc/library/signal.rst	(revision 59557)
+++ Doc/library/signal.rst	(working copy)
@@ -110,6 +110,20 @@
:manpage:`signal(2)`.)
 
 
+.. function:: set_wakeup_fd(fd)
+
+   Set the wakeup fd to *fd*.  When a signal is received, a ``'\0'`` byte is
+   written to the fd.  This can be used by a library to wakeup a poll or select
+   call, allowing the signal to be fully processed.
+
+   The old wakeup fd is returned.  *fd* must be non-blocking.  It is up to the
+   library to remove any bytes before calling poll or select again.
+
+   When threads are enabled, this function can only be called from the main thread;
+   attempting to call it from other threads will cause a :exc:`ValueError`
+   exception to be raised.
+
+
 .. function:: signal(signalnum, handler)
 
Set the handler for signal *signalnum* to the function *handler*.  *handler* can
Index: Lib/test/test_signal.py
===
--- Lib/test/test_signal.py	(revision 59557)
+++ Lib/test/test_signal.py	(working copy)
@@ -165,12 +165,59 @@
 self.assertRaises(TypeError, signal.signal,
   signal.SIGUSR1, None)
 
+class WakeupSignalTests(unittest.TestCase):
+TIMEOUT_FULL = 10
+TIMEOUT_HALF = 5
+
+def test_wakeup_fd_early(self):
+import select
+
+signal.alarm(1)
+before_time = time.time()
+# We attempt to get a signal during the sleep,
+# before select is called
+time.sleep(self.TIMEOUT_FULL)
+mid_time = time.time()
+self.assert_(mid_time - before_time < self.TIMEOUT_HALF)
+select.select([self.read], [], [], self.TIMEOUT_FULL)
+after_time = time.time()
+self.assert_(after_time - mid_time < self.TIMEOUT_HALF)
+
+def test_wakeup_fd_during(self):
+import select
+
+signal.alarm(1)
+before_time = time.time()
+# We attempt to get a signal during the select call
+self.assertRaises(select.error, select.select,
+[self.read], [], [], self.TIMEOUT_FULL)
+after_time = time.time()
+self.assert_(after_time - before_time < self.TIMEOUT_HALF)
+
+def setUp(self):
+import fcntl
+
+self.alrm = signal.signal(signal.SIGALRM, lambda x,y:None)
+self.read, self.write = os.pipe()
+flags = fcntl.fcntl(self.write, fcntl.F_GETFL, 0)
+flags = flags | os.O_NONBLOCK
+fcntl.fcntl(self.write, fcntl.F_SETFL, flags)
+self.old_wakeup = signal.set_wakeup_fd(self.write)
+
+def tearDown(self):
+signal.set_wakeup_fd(self.old_wakeup)
+os.close(self.read)
+os.close(self.write)
+signal.signal(signal.SIGALRM, self.alrm)
+
+
 def test_main():
 if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
 raise test_support.TestSkipped("Can't test signal on %s" % \
sys.platform)
 
-test_support.run_unittest(BasicSignalTests, InterProcessSignalTests)
+test_support.run_unittest(BasicSignalTests, InterProcessSignalTests,
+WakeupSignalTests)
 
 
 if __name__ == "__main__":
Index: Modules/signalmodule.c
===
--- Modules/signalmodule.c	(revision 59557)
+++ Modules/signalmodule.c	(working copy)
@@ -12,6 +12,8 @@
 
 #include 
 
+#include 
+
 #ifndef SIG_ERR
 #define SIG_ERR ((PyOS_sighandler_t)(-1))
 #endif
@@ -75,6 +77,8 @@
 PyObject *func;
 } Handlers[NSIG];
 
+static sig_atomic_t wakeup_fd = -1;
+
 /* Speed up sigcheck() when none tripped */
 static volatile sig_atomic_t is_tripped = 0;
 
@@ -113,6 +117,7 @@
 static void
 signal_handler(int sig_num)
 {
+	const char dummy_byte = '\0';
 #ifdef WITH_THREAD
 #ifdef WITH_PTH
 	if (PyThread_get_thread_ident() != main_thread) {
@@ -128,6 +133,8 @@
cleared in PyErr_CheckSignals() before .tripped. */
 		is_tripped = 1;
 		Py_AddPendingCall(checksignals_witharg, NULL);
+		if (wakeup_fd != -1)
+			write(wakeup_fd, &dummy_byte, 1);
 #ifdef WITH_THREAD
 	}
 #endif
@@ -267,6 +274,39 @@
 anything else -- the callable Python object used as a handler");
 
 
+static PyObject *
+signal_set_wakeup_fd(PyObject *self, PyObject *args)
+{
+	struct stat buf;
+	int fd, old_fd;
+	if (!PyArg_ParseTuple(args, "i:set_wakeup_fd", &fd))
+		return NULL;
+#ifdef WITH_THREAD
+	if (PyThread_get_thread_ident() != main_thread) {
+		PyErr_SetString(PyExc_ValueError,
+"set_wakeup_fd only works in main thread");
+		return NULL;
+	}

[issue1635] Float patch for inf and nan on Windows (and other platforms)

[Christian Heimes]

Christian Heimes added the comment:

Applied in r59558 to the trunk

--
resolution: accepted -> 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

[issue1640] Enhancements for mathmodule

[Christian Heimes]

Christian Heimes added the comment:

The trunk_math_sign_inf_nan patch contains just three new method
isnan(), isinf() and sign(). It also fixes a minor numerical issue with
one function that did small / (small / large) instead of small * (large
/ small).

Added file: http://bugs.python.org/file8989/trunk_math_sign_inf_nan.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Lib/test/test_math.py
===
--- Lib/test/test_math.py	(revision 59558)
+++ Lib/test/test_math.py	(working copy)
@@ -203,6 +203,31 @@
 self.ftest('tanh(0)', math.tanh(0), 0)
 self.ftest('tanh(1)+tanh(-1)', math.tanh(1)+math.tanh(-1), 0)
 
+def testSign(self):
+self.assertEqual(math.sign(0), 0)
+self.assertEqual(math.sign(-2), -1)
+self.assertEqual(math.sign(+2), 1)
+self.assertEqual(math.sign(0.), 1)
+self.assertEqual(math.sign(-0.), -1)
+self.assertEqual(math.sign(-2.), -1)
+self.assertEqual(math.sign(+2.), 1)
+
+def testIsnan(self):
+self.assert_(math.isnan(float("nan")))
+self.assert_(math.isnan(float("inf")* 0.))
+self.failIf(math.isnan(float("inf")))
+self.failIf(math.isnan(0.))
+self.failIf(math.isnan(1.))
+
+def testIsinf(self):
+self.assert_(math.isinf(float("inf")))
+self.assert_(math.isinf(float("-inf")))
+self.assert_(math.isinf(1E400))
+self.assert_(math.isinf(-1E400))
+self.failIf(math.isinf(float("nan")))
+self.failIf(math.isinf(0.))
+self.failIf(math.isinf(1.))
+
 # RED_FLAG 16-Oct-2000 Tim
 # While 2.0 is more consistent about exceptions than previous releases, it
 # still fails this part of the test on some platforms.  For now, we only
@@ -247,3 +272,4 @@
 
 if __name__ == '__main__':
 test_main()
+
Index: Modules/mathmodule.c
===
--- Modules/mathmodule.c	(revision 59558)
+++ Modules/mathmodule.c	(working copy)
@@ -277,9 +277,8 @@
 PyDoc_STRVAR(math_log10_doc,
 "log10(x) -> the base 10 logarithm of x.");
 
-/* XXX(nnorwitz): Should we use the platform M_PI or something more accurate
-   like: 3.14159265358979323846264338327950288 */
-static const double degToRad = 3.141592653589793238462643383 / 180.0;
+static const double degToRad = Py_MATH_PI / 180.0;
+static const double radToDeg = 180.0 / Py_MATH_PI;
 
 static PyObject *
 math_degrees(PyObject *self, PyObject *arg)
@@ -287,7 +286,7 @@
 	double x = PyFloat_AsDouble(arg);
 	if (x == -1.0 && PyErr_Occurred())
 		return NULL;
-	return PyFloat_FromDouble(x / degToRad);
+	return PyFloat_FromDouble(x * radToDeg);
 }
 
 PyDoc_STRVAR(math_degrees_doc,
@@ -305,6 +304,76 @@
 PyDoc_STRVAR(math_radians_doc,
 "radians(x) -> converts angle x from degrees to radians");
 
+static PyObject *
+math_isnan(PyObject *self, PyObject *arg)
+{
+	double x = PyFloat_AsDouble(arg);
+	if (x == -1.0 && PyErr_Occurred())
+		return NULL;
+	return PyBool_FromLong((long)Py_IS_NAN(x));
+}
+
+PyDoc_STRVAR(math_isnan_doc,
+"isnan(x) -> bool\n\
+Checks if float x is not a number (NaN)");
+
+static PyObject *
+math_isinf(PyObject *self, PyObject *arg)
+{
+	double x = PyFloat_AsDouble(arg);
+	if (x == -1.0 && PyErr_Occurred())
+		return NULL;
+	return PyBool_FromLong((long)Py_IS_INFINITY(x));
+}
+
+PyDoc_STRVAR(math_isinf_doc,
+"isinf(x) -> bool\n\
+Checks if float x is infinite (positive or negative)");
+
+static PyObject *
+math_sign(PyObject *self, PyObject *arg)
+{
+	int result = -2;
+	if (PyInt_Check(arg)) {
+		long l = PyInt_AsLong(arg);
+		if (l == -1.0 && PyErr_Occurred())
+			return NULL;
+		result = l > 0 ? 1 :
+l < 0 ? -1 : 0;
+		
+	}
+	if (PyLong_Check(arg)) {
+		result = _PyLong_Sign(arg);
+	}
+	else if (PyFloat_Check(arg)) {
+		double x = PyFloat_AsDouble(arg);
+		if (x == -1.0 && PyErr_Occurred())
+			return NULL;
+#ifdef HAVE_COPYSIGN
+		result = (int)copysign(1., x);
+#elif defined(MS_WINDOWS)
+		result = (int)_copysign(1.0, x);
+#else
+		result = x > 0.0 ? 1 :
+x < 0.0 ? -1 : 0;
+#endif
+	}
+	if (result == -2) {
+		PyErr_Format(PyExc_TypeError,
+			 "sign() expected int, long or float, found %s",
+			 Py_Type(arg)->tp_name);
+		return NULL;
+	}
+	return PyInt_FromLong((long)result);
+}
+
+PyDoc_STRVAR(math_sign_doc,
+"sign(x) -> +1 / 0 / -1\n\
+Return the sign of an int, long or float. On platforms with full IEEE 754\n\
+semantic sign(0.) returns +1 and sign(-0.) returns -1. On other platforms\n\
+sign(0.) always returns 0.");
+
+
 static PyMethodDef math_methods[] = {
 	{"acos",	math_acos,	METH_O,		math_acos_doc},
 	{"asin",	math_asin,	METH_O,		math_asin_doc},
@@ -320,12 +389,15 @@
 	{"fmod",	math_fmod,	METH_VARARGS,	math_fmod_doc},
 	{"frexp",	math_frexp,	METH_O,		math_frexp_doc},
 	{"hypot",	math_hypot,	METH_VARARGS,	math_hypot_doc},
+	{"isinf",	math_isinf,	MET

[issue1580] Use shorter float repr when possible

[Skip Montanaro]

Skip Montanaro added the comment:

Guido> ... trying to explain why two numbers both print the same but
Guido> compare unequal ...

This is not a Python-specific issue.  The notion of limited precision was
pounded into our heads in the numerical analysis class I took in college,
1980-ish.  I'm pretty sure that was before both Python and IEEE-754.  I'm
pretty sure I programmed for that class in Fortran.

Guido> ... (and God forbid anyone proposes adding fuzz to float ==).

Is it possible to produce a FuzzyFloat class which is a subclass of float
that people could use where they needed it?  Its constructor could take a
tolerance arg, or it could be initialized from a global default.  I'm not
suggesting that suchh a class replace float in the core, but that it might
be useful to have it available in some contexts (available via PyPI, of
course).  I'm offline at the moment or I'd poke around before asking.

Skip

--
nosy: +skip.montanaro

__
Tracker <[EMAIL PROTECTED]>

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

[issue1653] a couple of documentation issues

[Martin v. Löwis]

Martin v. Löwis added the comment:

Closing as requested.

--
resolution:  -> out of date
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

[issue1179] [CVE-2007-4965] Integer overflow in imageop module

[Jim Panetta]

Jim Panetta added the comment:

Is this final yet?  Our system security group is a little paranoid about
buffer overflows of any sort and are starting to make noises.  I can
confirm that the Oct 20 patch applies against Python 2.5.1 on RHEL4, and
that the string length error is generated when running poc.py.

--
nosy: +jhpanetta

__
Tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Tim Peters]

Tim Peters added the comment:

Guido, right, for that to work reliably, double->str and str->double
must both round correctly on the platform doing the repr(), and
str->double must round correctly on the platform reading the string.

It's quite easy to understand why at a high level:  a simple (but
tedious) pigeonhole argument shows that there are more representable
doubles than there are possible 16-digit decimal outputs.  Therefore
there must exist distinct doubles (say, x and y) that map to the same
16-digit decimal output (in fact, there are cases where 7 consecutive
doubles all map to the same correctly-rounded 16-digit decimal string).
 When reading that back in, there's no room for error in deciding which
of {x, y} was /intended/ -- the str->double conversion has to be
flawless in deciding which of {x, y} is closest to the 16-digit decimal
input, and in case x and y are equally close, has to apply 754's
round-to-nearest/even rule correctly.  This can require exact
multi-thousand bit arithmetic in some cases, which is why the 754
standard doesn't require it (thought to be impractically expensive at
the time).

> which would really turn the educational issue into an educational
> nightmare, trying to explain why two numbers both print the same
> but compare unequal

Well, newbies see that in, e.g., spreadsheets every day.  You generally
have to work to get a spreadsheet to show you "all the digits"; in some
spreadsheets it's not even possible.  "Not all digits are displayed"
should be within the grasp of must students without suffering nightmares ;-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1654] HTTPSConnection is not IPv6-capable

[Bill Janssen]

Changes by Bill Janssen:


--
resolution:  -> invalid
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

[issue1623] Implement PEP-3141 for Decimal

[Guido van Rossum]

Guido van Rossum added the comment:

Sorry, the PEP was approved, just not yet marked as such.  :-)  Will do
so now.

--
nosy: +gvanrossum
resolution: postponed -> 
status: pending -> open

__
Tracker <[EMAIL PROTECTED]>

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

[issue1656] Make math.{floor,ceil}(float) return ints per PEP 3141

[Jeffrey Yasskin]

New submission from Jeffrey Yasskin:

See
http://python.org/dev/peps/pep-3141/#changes-to-operations-and-magic-methods

--
components: Library (Lib)
files: floorceil_return_int.patch
messages: 58792
nosy: jyasskin
severity: normal
status: open
title: Make math.{floor,ceil}(float) return ints per PEP 3141
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8990/floorceil_return_int.patch

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1629] Py_Size() should be named Py_SIZE()

[Christian Heimes]

Christian Heimes added the comment:

I've renamed the three macros and added the old names for b/w compatibility.

--
resolution: accepted -> 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

[issue1648] add new function, sys.gettrace

[Titus Brown]

Titus Brown added the comment:

Added getprofile + tests, docs, as per reasonable request ;)

Added file: http://bugs.python.org/file8991/gettrace+getprofile.diff

__
Tracker <[EMAIL PROTECTED]>

__

gettrace+getprofile.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1657] [patch] select.epoll wrapper for Linux 2.6 epoll()

[Christian Heimes]

New submission from Christian Heimes:

The patch implements Linux's epoll interface
(http://linux.die.net/man/4/epoll). My patch doesn't introduce a new
module like http://bugs.python.org/issue1675118 and it wraps the epoll
control fd in an object like Twisted's _epoll.pyd interface.

My interface is almost identical to Twisted's API except for some names.
I named my control function "control" instead of "_control" and the
constants are all named "select.EPOLL_SPAM" instead of "SPAM".

Missing:
Documentation

--
assignee: tiran
files: trunk_select_epoll.patch
keywords: patch, py3k
messages: 58795
nosy: tiran
priority: normal
severity: normal
status: open
title: [patch] select.epoll wrapper for Linux 2.6 epoll()
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8992/trunk_select_epoll.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: configure
===
--- configure	(Revision 59563)
+++ configure	(Arbeitskopie)
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 59533 .
+# From configure.in Revision: 59558 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.61 for python 2.6.
 #
@@ -5416,13 +5416,14 @@
 
 
 
+
 for ac_header in asm/types.h conio.h curses.h direct.h dlfcn.h errno.h \
 fcntl.h grp.h \
 io.h langinfo.h libintl.h ncurses.h poll.h process.h pthread.h \
 shadow.h signal.h stdint.h stropts.h termios.h thread.h \
 unistd.h utime.h \
-sys/audioio.h sys/bsdtty.h sys/file.h sys/loadavg.h sys/lock.h sys/mkdev.h \
-sys/modem.h \
+sys/audioio.h sys/bsdtty.h sys/epoll.h sys/file.h sys/loadavg.h sys/lock.h \
+sys/mkdev.h sys/modem.h \
 sys/param.h sys/poll.h sys/select.h sys/socket.h sys/statvfs.h sys/stat.h \
 sys/time.h \
 sys/times.h sys/types.h sys/un.h sys/utsname.h sys/wait.h pty.h libutil.h \
@@ -15644,7 +15645,57 @@
 fi
 
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ echo "$as_me:$LINENO: checking for epoll" >&5
+echo $ECHO_N "checking for epoll... $ECHO_C" >&6; }
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include 
+int
+main ()
+{
+void *x=epoll_create
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try="$ac_compile"
+case "(($ac_try" in
+  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+  *) ac_try_echo=$ac_try;;
+esac
+eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
+  (eval "$ac_compile") 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && {
+	 test -z "$ac_c_werror_flag" ||
+	 test ! -s conftest.err
+   } && test -s conftest.$ac_objext; then
 
+cat >>confdefs.h <<\_ACEOF
+#define HAVE_EPOLL 1
+_ACEOF
+
+  { echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6; }
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+	{ echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6; }
+
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
 # On some systems (eg. FreeBSD 5), we would find a definition of the
 # functions ctermid_r, setgroups in the library, but no prototype
 # (e.g. because we use _XOPEN_SOURCE). See whether we can take their
Index: configure.in
===
--- configure.in	(Revision 59563)
+++ configure.in	(Arbeitskopie)
@@ -1100,8 +1100,8 @@
 io.h langinfo.h libintl.h ncurses.h poll.h process.h pthread.h \
 shadow.h signal.h stdint.h stropts.h termios.h thread.h \
 unistd.h utime.h \
-sys/audioio.h sys/bsdtty.h sys/file.h sys/loadavg.h sys/lock.h sys/mkdev.h \
-sys/modem.h \
+sys/audioio.h sys/bsdtty.h sys/epoll.h sys/file.h sys/loadavg.h sys/lock.h \
+sys/mkdev.h sys/modem.h \
 sys/param.h sys/poll.h sys/select.h sys/socket.h sys/statvfs.h sys/stat.h \
 sys/time.h \
 sys/times.h sys/types.h sys/un.h sys/utsname.h sys/wait.h pty.h libutil.h \
@@ -2358,7 +2358,12 @@
   AC_MSG_RESULT(yes),
   AC_MSG_RESULT(no)
 )
-
+AC_MSG_CHECKING(for epoll)
+AC_TRY_COMPILE([#include ], void *x=epoll_create,
+  AC_DEFINE(HAVE_EPOLL, 1, Define if you have the 'epoll' functions.)
+  AC_MSG_RESULT(yes),
+  AC_MSG_RESULT(no)
+)
 # On some systems (eg. FreeBSD 5), we would find a definition of the
 # functions ctermid_r, setgroups in the library, but no prototype
 # (e.g. because we use _XOPEN_SOURCE). See whether we can take their
Index: Lib/test/test_epoll.py
===
--- Lib/test/test_epoll.py	(Revision 0)
+++ Lib/test/test_epoll.py	(Revision 0)
@@ -0,0 +1,167 @@
+"""
+Tests for epoll wrapper.
+"""
+import socket, errno, time, select
+
+import unittest
+
+
+
+class EPoll(unittest.TestCase):

[issue1675118] Epoll wrapper

[Christian Heimes]

Christian Heimes added the comment:

I've created my own interface modeled after the Twisted interface: #1657

I prefer to wrap the epoll control fd in an object, just like poll.

--
priority: high -> normal
resolution:  -> duplicate
status: open -> closed
superseder:  -> [patch] select.epoll wrapper for Linux 2.6 epoll()

_
Tracker <[EMAIL PROTECTED]>

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