[issue1580] Use shorter float repr when possible

[Tim Peters]

Tim Peters added the comment:

It's not a question of bugs.  Call the machine writing the string W and
the machine reading the string R.  Then there are 4 ways R can get back
the double W started with when using the suggested algorithm:

1. W and R are the same machine.  This is the way that's most obvious.

The rest apply when W and R are different machines (by which I really
mean both use 754 doubles, but use different C libraries for
double<->string conversions):

2. W and R both do correct-rounding string->double.  This is obvious too
 (although it may not be obvious that it's /not/ also necessary that W
do correct-rounding double->string).

3. W and R both conform to the 754 standard, and W did produce 17
significant digits (or fewer if trailing zeroes were chopped).  This one
is neither obvious nor non-obvious:  that "it works" is something the
754 standard requires.

4. W produced fewer than 17 significant digits, and W and/or R do not do
correct rounding.  Then it works, or fails, by luck, and this has
nothing to do whether the double<->string algorithms have bugs.  There
are countless ways to code such routines that will fail in some cases --
doing correct rounding in all cases is the only way that won't fail in
some cases of producing fewer than 17 significant digits (and exactly
which cases depend on all the details of the specific
non-correct-rounding algorithms W and/or R implement).

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

BTW, about http://www.cant.ua.ac.be/ieeecc754.html:  passing that test
does not guarantee the platform does correct rounding.  It uses a fixed
set of test cases that were in fact obtained from running the algorithm
I invented for efficiently finding "hard" cases in the early 90s (and
implemented by Vern Paxson, and then picked up by the authors of the
test suite you found).  It's "very likely" that an implementation that
doesn't do correct rounding will fail on at least one of those cases,
but not certain.  Exhaustive testing is impossible (too many cases).

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

New submission from Titus Brown:

Currently there is no way to retrieve the current trace function; this
patch adds 'gettrace' to the sys module.

This behavior is very useful for helping to control code coverage
analysis tools.

--
components: Library (Lib)
files: gettrace.diff
messages: 58725
nosy: brett.cannon, titus
severity: minor
status: open
title: add new function, sys.gettrace
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8982/gettrace.diff

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1643] Add group() to itertools

[Raymond Hettinger]

Raymond Hettinger added the comment:

Sorry, I'm not interested in adding this to the module.  Discussions to-
date on the subject seem to show more interest in playing with grouper 
variants than in actual use cases.  While the recipe given in the docs 
is somewhat opaque, it runs at C-speed (zero trips around the eval-
loop) and it is encapsulated in a re-usable function. Writing this in C 
does nothing to improve the situation.  Also, when people like to play 
with variants, there is no general agreement on useful requirements 
(like fill-in behavior or raising an exception on uneven length 
inputs). Trying to write option to meet all needs (n=2, step=1) makes 
the code more difficult to learn and use -- see several variants in 
Alex's Python Cookbook.  Another issue is that we have to be very 
selective about adding tools to the module.  Each addition makes the 
overall toolset harder to use -- it is better to have a good set of 
basic building blocks.

--
components: +Extension Modules -Library (Lib)
nosy: +rhettinger
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

[issue1623] Implement PEP-3141 for Decimal

[Jeffrey Yasskin]

Jeffrey Yasskin added the comment:

Re math.{floor,ceil}(float): oops, that's definitely a bug. I'll fix it.

Re backporting: yes, and I believe trunc() should be backported too.

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

New submission from Christian Heimes:

Is it necessary to alter or remove the exit function?

c:\dev\python\trunk\PCbuild9>python ..\Lib\idlelib\idle.py
Traceback (most recent call last):
  File "c:\dev\python\trunk\lib\idlelib\run.py", line 83, in main
exit()
  File "c:\dev\python\trunk\lib\idlelib\run.py", line 209, in exit
del sys.exitfunc
AttributeError: exitfunc

--
assignee: kbk
components: IDLE
messages: 58722
nosy: kbk, tiran
severity: normal
status: open
title: IDLE messes around with sys.exitfunc
versions: Python 2.6, 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

[issue1646] Make socket support TIPC.

[Christian Heimes]

Changes by Christian Heimes:


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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1644] Patch submission guidelines outdated

[Christian Heimes]

Changes by Christian Heimes:


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

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

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +patch
priority:  -> normal

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

[Alberto Bertogli]

New submission from Alberto Bertogli:

TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.

The attached patch (against trunk) adds optional Linux-only support for
TIPC in the socket module.

If you want me to make one against 3.0 or any other branch, just let me
know.

Thanks,
Alberto

--
components: Library (Lib)
files: 0002-Make-socket-support-TIPC.patch
messages: 58721
nosy: albertito
severity: normal
status: open
title: Make socket support TIPC.
versions: Python 2.6
Added file: http://bugs.python.org/file8981/0002-Make-socket-support-TIPC.patch

__
Tracker <[EMAIL PROTECTED]>

__From: Alberto Bertogli <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:39:18 -0300
Subject: [PATCH] Make socket support TIPC.

TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.

This patch adds optional Linux-only support for TIPC in the socket module.
---
 Modules/socketmodule.c |  154 +++-
 Modules/socketmodule.h |4 +
 configure.in   |2 +-
 3 files changed, 158 insertions(+), 2 deletions(-)

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -7,7 +7,8 @@ This module provides an interface to Berkeley socket IPC.
 Limitations:
 
 - Only AF_INET, AF_INET6 and AF_UNIX address families are supported in a
-  portable manner, though AF_PACKET and AF_NETLINK are supported under Linux.
+  portable manner, though AF_PACKET, AF_NETLINK and AF_TIPC are supported
+  under Linux.
 - No read/write operations (use sendall/recv or makefile instead).
 - Additional restrictions apply on some non-Unix platforms (compensated
   for by socket.py).
@@ -52,6 +53,25 @@ Module interface:
   the Ethernet protocol number to be received. For example:
   ("eth0",0x1234).  Optional 3rd,4th,5th elements in the tuple
   specify packet-type and ha-type/addr.
+- an AF_TIPC socket address is expressed as
+ (addr_type, v1, v2, v3 [, scope]); where addr_type can be one of:
+	TIPC_ADDR_NAMESEQ, TIPC_ADDR_NAME, and TIPC_ADDR_ID;
+  and scope can be one of:
+	TIPC_ZONE_SCOPE, TIPC_CLUSTER_SCOPE, and TIPC_NODE_SCOPE.
+  The meaning of v1, v2 and v3 depends on the value of addr_type:
+	if addr_type is TIPC_ADDR_NAME:
+		v1 is the server type
+		v2 is the port identifier
+		v3 is ignored
+	if addr_type is TIPC_ADDR_NAMESEQ:
+		v1 is the server type
+		v2 is the lower port number
+		v3 is the upper port number
+	if addr_type is TIPC_ADDR_ID:
+		v1 is the node
+		v2 is the ref
+		v3 is ignored
+
 
 Local naming conventions:
 
@@ -1094,6 +1114,39 @@ makesockaddr(int sockfd, struct sockaddr *addr, int addrlen, int proto)
 	}
 #endif
 
+#ifdef HAVE_LINUX_TIPC_H
+	case AF_TIPC:
+	{
+		struct sockaddr_tipc *a = (struct sockaddr_tipc *) addr;
+		if (a->addrtype == TIPC_ADDR_NAMESEQ) {
+			return Py_BuildValue("I",
+	a->addrtype,
+	a->addr.nameseq.type,
+	a->addr.nameseq.lower,
+	a->addr.nameseq.upper,
+	a->scope);
+		} else if (a->addrtype == TIPC_ADDR_NAME) {
+			return Py_BuildValue("I",
+	a->addrtype,
+	a->addr.name.name.type,
+	a->addr.name.name.instance,
+	a->addr.name.name.instance,
+	a->scope);
+		} else if (a->addrtype == TIPC_ADDR_ID) {
+			return Py_BuildValue("I",
+	a->addrtype,
+	a->addr.id.node,
+	a->addr.id.ref,
+	0,
+	a->scope);
+		} else {
+			PyErr_SetString(PyExc_TypeError,
+	"Invalid address type");
+			return NULL;
+		}
+	}
+#endif
+
 	/* More cases here... */
 
 	default:
@@ -1379,6 +1432,56 @@ getsockaddrarg(PySocketSockObject *s, PyObject *args,
 	}
 #endif
 
+#ifdef HAVE_LINUX_TIPC_H
+	case AF_TIPC:
+	{
+		unsigned int atype, v1, v2, v3;
+		unsigned int scope = TIPC_CLUSTER_SCOPE;
+		struct sockaddr_tipc *addr;
+
+		if (!PyTuple_Check(args)) {
+			PyErr_Format(
+PyExc_TypeError,
+"getsockaddrarg: "
+"AF_TIPC address must be tuple, not %.500s",
+Py_Type(args)->tp_name);
+			return 0;
+		}
+
+		if (!PyArg_ParseTuple(args,
+	"|I;Invalid TIPC address format",
+	&atype, &v1, &v2, &v3, &scope))
+			return 0;
+
+		addr = (struct sockaddr_tipc *) addr_ret;
+		memset(addr, 0, sizeof(struct sockaddr_tipc));
+
+		addr->family = AF_TIPC;
+		addr->scope = scope;
+		addr->addrtype = atype;
+
+		if (atype == TIPC_ADDR_NAMESEQ) {
+			addr->addr.nameseq.type = v1;
+			addr->addr.nameseq.lower = v2;
+			addr->addr.nameseq.upper = v3;
+		} else if (atype == TIPC_ADDR_NAME) {
+			addr->addr.name.name.type = v1;
+			addr->addr.name.name.instance = v2;
+		} else if (atype == TIPC_ADDR_ID) {
+			addr->addr.id.node = v1;
+			addr->addr.id.ref = v2;
+		} else {
+			/* Shouldn't happe

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

[Alberto Bertogli]

New submission from Alberto Bertogli:

The comment above sock_recvfrom_guts() was copied from sock_recv_guts() and
referenced recv() and recv_into() when it should be talking about recvfrom()
and recvfrom_into().

The attached patch (against trunk) fixes it.

--
components: Library (Lib)
files: 0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch
messages: 58720
nosy: albertito
severity: minor
status: open
title: Fix socketmodule.c:sock_recvfrom_guts() comment.
versions: Python 2.6
Added file: 
http://bugs.python.org/file8980/0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch

__
Tracker <[EMAIL PROTECTED]>

__From: Alberto Bertogli <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 15:53:35 -0300
Subject: [PATCH] Fix socketmodule.c:sock_recvfrom_guts() comment.

The comment above sock_recvfrom_guts() was copied from sock_recv_guts() and
referenced recv() and recv_into() when it should be talking about recvfrom()
and recvfrom_into().
---
 Modules/socketmodule.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -2358,12 +2358,12 @@ See recv() for documentation about the flags.");
 
 
 /*
- * This is the guts of the recv() and recv_into() methods, which reads into a
- * char buffer.  If you have any inc/def ref to do to the objects that contain
- * the buffer, do it in the caller.  This function returns the number of bytes
- * succesfully read.  If there was an error, it returns -1.  Note that it is
- * also possible that we return a number of bytes smaller than the request
- * bytes.
+ * This is the guts of the recvfrom() and recvfrom_into() methods, which reads
+ * into a char buffer.  If you have any inc/def ref to do to the objects that
+ * contain the buffer, do it in the caller.  This function returns the number
+ * of bytes succesfully read.  If there was an error, it returns -1.  Note
+ * that it is also possible that we return a number of bytes smaller than the
+ * request bytes.
  *
  * 'addr' is a return value for the address object.  Note that you must decref
  * it yourself.
-- 
1.5.4.rc0.1096.gcd2a6

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

[issue1644] Patch submission guidelines outdated

[Alberto Bertogli]

New submission from Alberto Bertogli:

The FAQ section 5.4, "How to submit a patch?", points to
http://www.python.org/patches/, which looks really outdated
(plus the sf page seems to be restricted to members only).

Thanks,
Alberto

--
components: Documentation
messages: 58719
nosy: albertito
severity: normal
status: open
title: Patch submission guidelines outdated

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

Christian Heimes added the comment:

Christian Heimes wrote:
> Is 0x0500 fine for Windows 2000? Should we add WINVER=0x0500 to the
> Python project files, too?

http://msdn2.microsoft.com/en-us/library/aa383745.aspx

Minimum system required Minimum value for _WIN32_WINNT and WINVER
Windows Server 2008 0x0600
Windows Vista   0x0600
Windows Server 2003 SP1, Windows XP SP2 0x0502
Windows Server 2003, Windows XP 0x0501
Windows 20000x0500

0x0500 is fine for Windows 2000.

Should we add something like this to PC/pyconfig.h to ensure that our
build uses only Win2k compatible features and that the user is using at
least 2k to compile Python?

#ifdef WINVER
#  if WINVER < 0x0400
#error "Windows 2000 or newer is required"
#  endif
#  define WINVER 0x0500
#  define _WIN32_WINNT 0x0500
#endif

Christian

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

Christian Heimes added the comment:

Amaury Forgeot d'Arc wrote:
> I found that the huge font in menus is due to an error in the call to
> SystemParametersInfo.
> Digging more, vc2008 defines WINVER=0x0600, which corresponds to Windows
> Vista, and is too high for Windows XP: this value activates the
> definition of extra fields in the NONCLIENTMETRICS structure, and
> SystemParametersInfo on Windows XP will not accept a sizeof() greater
> than expected.

Wow, you are a genius! :)

> I recompiled tk, adding WINVER=0x500 to the command line:
> nmake /f makefile.vc COMPILERFLAGS=-DWINVER=0x0500
> And the menu is correctly displayed.
> I suggest to add this to the build_tkinter script.

Is 0x0500 fine for Windows 2000? Should we add WINVER=0x0500 to the
Python project files, too?

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1643] Add group() to itertools

[Kirk McDonald]

New submission from Kirk McDonald:

One question which is asked with surprising frequency in #python is how
to yield multiple objects at a time from an iterable object. That is,
given [1, 2, 3, 4, 5, 6], get [(1, 2), (3, 4), (5, 6)]. 

The "grouper" function in the itertools recipes page provides one
pattern for this. A similar function (which behaves differently when the
length of the iterable is not evenly divisible by n) looks like this:

def group(iterable, n=2):
return itertools.izip(*(iter(iterable),)*n)

This code is fairly opaque to the novice. It is ugly, and takes a bit of
head-scratching to realize exactly what it is doing. Because this
operation is asked for with some frequency, and because this general
implementation is so ugly, I believe it belongs in the library.

There is a related function which is asked for much less frequently, but
which is a more general case of the group() function listed above. This
other function has a third "step" argument. This argument controls how
far each group is in advance of the previous group. For example:

list(group([1, 2, 3, 4], n=2, step=1)) -> [(1, 2), (2, 3), (3, 4)]

The original function is equivalent to this function when step is equal
to n.

Please find attached a patch with implementation, documentation, and tests.

--
components: Library (Lib)
files: itertools.group.patch
messages: 58716
nosy: KirkMcDonald
severity: normal
status: open
title: Add group() to itertools
versions: Python 2.6
Added file: http://bugs.python.org/file8979/itertools.group.patch

__
Tracker <[EMAIL PROTECTED]>

__

itertools.group.patch
Description: Binary data
___
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 found that the huge font in menus is due to an error in the call to
SystemParametersInfo.
Digging more, vc2008 defines WINVER=0x0600, which corresponds to Windows
Vista, and is too high for Windows XP: this value activates the
definition of extra fields in the NONCLIENTMETRICS structure, and
SystemParametersInfo on Windows XP will not accept a sizeof() greater
than expected.

I recompiled tk, adding WINVER=0x500 to the command line:
nmake /f makefile.vc COMPILERFLAGS=-DWINVER=0x0500
And the menu is correctly displayed.
I suggest to add this to the build_tkinter script.

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue1607] Patch for TCL 8.5 support

[Kurt B. Kaiser]

Kurt B. Kaiser added the comment:

Good to hear; thanks for the info!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1607] Patch for TCL 8.5 support

[Christian Heimes]

Christian Heimes added the comment:

Kurt B. Kaiser wrote:
> I do have an XP on multiboot.  I'm not very enthusiatic about learning 
> MS tools; the last time I built Python on W. was with VC5 in the days 
> when IDLE had a small C extension, later incorporated into Python.  If 
> the Tk 8.5/Tkinkter problem doesn't get fixed I suppose I'lll have to 
> attempt 
> it again.  Thanks for the link.

In the past it was a real pain in the ... to set up a build env. Since I
have created the PCbuild9 directory for VS 2008 and we decided to build
new builds with VS 2008 it is dead easy. You *just* need to install VS
2008 and no more extra SDKs. The free Express Edition of VS c++ 2008 is
sufficient.

All extra dependencies are in Python's SVN repository.

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1772673] Replacing char* with const char*

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

There was once a rather long discussion about "const" in
PyArg_ParseTupleAndKeywords:
http://mail.python.org/pipermail/python-dev/2006-February/060689.html

If you don't read it to the end, here is the conclusion:
"""
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back.  We'll fix it when C fixes its
const rules .
"""

"const char*" was accepted without opposition, though.

--
nosy: +amaury.forgeotdarc

_
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Gregory P. Smith]

Gregory P. Smith added the comment:

heh if thats the only warning gcc -Wstrict-overflow gives then I've
mistitled the bug.  Fixed.  It'll take some manual code review. 

Anyone know if the commercial analysis tools we've run the code base
through in the past can find these for us?

--
title: Python should compile with -Wstrict-overflow when using gcc -> Do not 
assume signed integer overflow behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue1350] IDLE - CallTips enhancement - show full doc-string in new window

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser:


Removed file: http://bugs.python.org/file8957/IDLE_CallTips.071214.patch

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

This is what I was thinking of before, although I'd use "%.16g"%f and
"%.17g"%f instead of str(f) and repr(f), and I'd use float() instead
of eval().

I suspect that it doesn't satisfy Tim Peters though, because this may
depend on a rounding bug in the local platform's input function.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1350] IDLE - CallTips enhancement - show full doc-string in new window

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser:


Removed file: 
http://bugs.python.org/file8958/IDLE_CallTips.071214.incremental.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1772673] Replacing char* with const char*

[Gustavo J. A. M. Carneiro]

Gustavo J. A. M. Carneiro added the comment:

I was about to submit the very same patch :-)
I missed PyErr_NewException, but you missed the PyMapping_* methods ;)

Please look into this matter.  GCC 4.2 has arrived and it has a new
warning.  The code:

 char* kwlist[] = { "target", "encoding", NULL };

now gives a warning like:

"warning: deprecated conversion from string constant to ‘char*’"

at least when compiling in C++ mode...

This means that people have to declare it as "const char* kwlist", which
will then trigger another warning when calling
PyArg_ParseTupleAndKeywords with such a variable, because the prototype is:

PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *,
  const char *, char **,
...);

The "char **" should be "const char **".  ext-, any chance you could fix
that too?

--
nosy: +gustavo

_
Tracker <[EMAIL PROTECTED]>

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

[issue1607] Patch for TCL 8.5 support

[Kurt B. Kaiser]

Kurt B. Kaiser added the comment:

I do have an XP on multiboot.  I'm not very enthusiatic about learning 
MS tools; the last time I built Python on W. was with VC5 in the days 
when IDLE had a small C extension, later incorporated into Python.  If 
the Tk 8.5/Tkinkter problem doesn't get fixed I suppose I'lll have to 
attempt 
it again.  Thanks for the link.

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

Ok, I think I have a solution!

We don't really need always the shortest decimal representation. We just
want that for most floats which have a nice decimal representation, that
representation will be used. 

Why not do something like that:

def newrepr(f):
r = str(f)
if eval(r) == f:
return r
else:
return repr(f)

Or, in more words:

1. Calculate the decimal representation of f with 17 precision digits,
s1, using the system's routines.
2. Create a new string, s2, by rounding the resulting string to 12
precision digits.
3. Convert the resulting rounded string to a new double, g, using the
system's routines.
4. If f==g, return s2. Otherwise, return s1.

It will take some more time than the current repr(), because of the
additional decimal to binary conversion, but we already said that if
speed is extremely important one can use "'%f.17' % f". It will
obviously preserve the eval(repr(f)) == f property. And it will return a
short representation for almost any float that has a short representation.

This algorithm I will be glad to implement.

What do you think?

__
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

[Christian Heimes]

Changes by Christian Heimes:


--
assignee:  -> theller
nosy: +theller
priority:  -> normal
versions: +Python 2.6, 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

[issue1642] segfault when deleting value member in ctypes types

[Carl Friedrich Bolz]

New submission from Carl Friedrich Bolz:

When trying to delete the .value member of ctypes simple types my python
interpreter segfaults:

$ python
Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import c_long
>>> c = c_long(1)
>>> c.value
1
>>> del c.value
Segmentation fault (core dumped)


Admittedly there is no good usecase for this, but it should raise an
exception and not segfault.

--
components: Extension Modules
messages: 58705
nosy: cfbolz
severity: normal
status: open
title: segfault when deleting value member in ctypes types
type: crash
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

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

[Christian Heimes]

Christian Heimes added the comment:

I'm posting a combined patch for all features at #1640.

--
superseder:  -> Enhancements for mathmodule

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

Adam Olsen wrote:
> You have:
> #define Py_NAN Py_HUGE_VAL * 0
> I think this would be safer as:
> #define Py_NAN (Py_HUGE_VAL * 0)
> 
> For instance, in code that may do "a / Py_NAN".

You are right! Fixed

> Those manual string copies (*cp++ = 'n';) are ugly.  Can't you use
> strcpy() instead?

Done

Christian

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

Mark Dickinson wrote:
> Mark Dickinson added the comment:
> 
> Cool! If there's a move to add functions to the math module, there are 
> some others that are part of C99 (but not C89), would be good to have, and 
> that I'd consider more fundamental than the Bessel, error, gamma 
> functions;  for example, the inverse hyperbolic trig functions (acosh, 
> asinh, atanh), log1p, expm1, copysign.

I've added the inverse hyperbolic, log1p and expm1. copysign is too low
level but I've added sign(x) -> -1/0/+1. It uses copysign() where
available so you can emulate copysign(x, y) with sign(x) * y.

Do you want some more functions?
http://www.dinkumware.com/manuals/?manual=compleat&page=math.html

Feel free to provide a patch :)

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue546558] Windows getpass bug

[Joseph Armbruster]

Joseph Armbruster added the comment:

For the record, I tested this out with:

url: http://svn.python.org/projects/python/branches/py3k:
rev: 59540
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600

The following snippet appeared to behave as intended (i input "secret"
them "something else"):

>>> import getpass
>>> def x():
...secret = getpass.getpass('Tell me a secret: ')
...stuff = input('Tell me something else: ')
...print('The user told me the secret was "%s" and the other thing
was "%s"' % (secret, stuff))
...
>>> x()
Tell me a secret:
Tell me something else: something else
The user told me the secret was "secret" and the other thing was
"something else
"
>>>

--
nosy: +JosephArmbruster


Tracker <[EMAIL PROTECTED]>


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

[issue1609] test_re.py fails

[Guido van Rossum]

Guido van Rossum added the comment:

Focus on how using --with-wctype-functions changes things and how this
could affect the regex implementation. (I wouldn't be surprised if the
other failing tests were to to the regex bugs.)

__
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

[Adam Olsen]

Adam Olsen added the comment:

Minor typo.  Should be IEEE:
"Return the sign of an int, long or float. On platforms with full IEE
754\n\"

--
nosy: +rhamphoryncus

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

Cool! If there's a move to add functions to the math module, there are 
some others that are part of C99 (but not C89), would be good to have, and 
that I'd consider more fundamental than the Bessel, error, gamma 
functions;  for example, the inverse hyperbolic trig functions (acosh, 
asinh, atanh), log1p, expm1, copysign.

--
nosy: +marketdickinson

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

[Adam Olsen]

Adam Olsen added the comment:

You have:
#define Py_NAN Py_HUGE_VAL * 0
I think this would be safer as:
#define Py_NAN (Py_HUGE_VAL * 0)

For instance, in code that may do "a / Py_NAN".

Those manual string copies (*cp++ = 'n';) are ugly.  Can't you use
strcpy() instead?

--
nosy: +rhamphoryncus

__
Tracker <[EMAIL PROTECTED]>

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

[issue1722225] Build on QNX 6

[Matt Kraai]

Matt Kraai added the comment:

I'm not interested in QNX 4, as that's not what I use.  I'd be willing
to supporting threads on QNX 6.

--
title: Build on QNX -> Build on QNX 6

_
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

[Giampaolo Rodola']

Changes by Giampaolo Rodola':


Added file: http://bugs.python.org/file8977/asyncore.py

__
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

[Giampaolo Rodola']

Changes by Giampaolo Rodola':


Added file: http://bugs.python.org/file8976/patch.diff

__
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

[Giampaolo Rodola']

New submission from Giampaolo Rodola':

Hi,
I post this message here in the hope someone using asyncore could review
this.
Since the thing I miss mostly in asyncore is a system for calling a
function after a certain amount of time, I spent the last 3 days trying
to implement this with the hopes that this could be included in asyncore
in the the future.
The logic consists in calling a certain function (the "scheduler") at
every loop to check if it is the proper time to call one or more
scheduled functions.
Such functions are scheduled by the new delayed_call class which is very
similar to the DelayedCall class defined in /twisted/internet/base.py I
drew on.
It provides a basic API which can be used for setting, resetting and
canceling the scheduled functions.
For better performance I used an heap queue structure. This way the
scheduler() only needs to check the scheduled functions due to expire
soonest.

The following code sample implements an idle-timeout capability using
the attached modified asyncore library.

--- code snippet ---
import asyncore, asynchat, socket

class foo(asynchat.async_chat):

   def __init__(self, conn=None):
   asynchat.async_chat.__init__(self, conn)
   self.set_terminator(None)
   self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
   self.connect(('127.0.0.1', 21))
   self.scheduled_timeout = self.call_later(120, self.handle_timeout)

   def collect_incoming_data(self, data):
   self.scheduled_timeout.reset()
   # do something with the data...

   def handle_timeout(self):
   self.push("500 Connection timed out.\r\n")
   self.close_when_done()
   
   def close(self):
   if not self.scheduled_timeout.cancelled:
   self.scheduled_timeout.cancel()
   asyncore.dispatcher.close(self)

foo()
asyncore.loop()
--- /code snippet ---


Today I played a little more with it and I tried to add bandwidth
throttling capabilities to the base asynchat.py.
The code could be surely improved but it's just an example to show
another useful feature which wouldn't be possible to implement without
having a "call_later" function under the hood:


--- code snippet ---
class throttled_async_chat(asynchat.async_chat):
# maximum number of bytes to transmit in a second (0 == no limit)
read_limit = 100 * 1024
write_limit = 100 * 1024

# smaller the buffers, the less bursty and smoother the throughput
ac_in_buffer_size = 2048
ac_out_buffer_size  = 2048

def __init__(self, conn=None):
asynchat.async_chat.__init__(self, conn)
self.read_this_second = 0
self.written_this_second = 0
self.r_timenext = 0
self.w_timenext = 0
self.r_sleep = False
self.w_sleep = False
self.delayed_r = None
self.delayed_w = None

def readable(self):
return asynchat.async_chat.readable(self) and not self.r_sleep

def writable(self):
return asynchat.async_chat.writable(self) and not self.w_sleep

def recv(self, buffer_size):
chunk = asyncore.dispatcher.recv(self, buffer_size)
if self.read_limit:
self.read_this_second += len(chunk)
self.throttle_read()
return chunk

def send(self, data):
num_sent = asyncore.dispatcher.send(self, data)
if self.write_limit:
self.written_this_second += num_sent
self.throttle_write()
return num_sent

def throttle_read(self):
if self.read_this_second >= self.read_limit:
self.read_this_second = 0
now = time.time()
sleepfor = self.r_timenext - now
if sleepfor > 0:
# we've passed bandwidth limits
self.r_sleep = True
def unthrottle():
self.r_sleep = False
self.delayed_r = self.call_later((sleepfor * 2), unthrottle)
self.r_timenext = now + 1

def throttle_write(self):
if self.written_this_second >= self.write_limit:
self.written_this_second = 0
now = time.time()
sleepfor = self.w_timenext - now
if sleepfor > 0:
# we've passed bandwidth limits
self.w_sleep = True
def unthrottle():
self.w_sleep = False
self.delayed_w = self.call_later((sleepfor * 2), unthrottle)
self.w_timenext = now + 1

def close(self):
if self.delayed_r and not self.delayed_r.cancelled:
self.delayed_r.cancel()
if self.delayed_w and not self.delayed_w.cancelled:
self.delayed_w.cancel()
asyncore.dispatcher.close(self)
--- /code snippet ---


I don't know if there's a better way to implement this "call_later" feature.
Maybe someone experienced with Twisted could provide a better approach.
I would ask someone using asyncore to review this since, IMHO, it would
fill a very big gap.

--
components: Library (L

[issue1640] Enhancements for mathmodule

[Christian Heimes]

Changes by Christian Heimes:


--
dependencies: +Float patch for inf and nan on Windows (and other platforms)

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

New submission from Christian Heimes:

The patch adds several small enhancements to the math module and pyport.h.

* Py_MATH_PI and Py_MATH_E in long double precision
* Py_IS_NAN and Py_IS_INFINITY use isnan() and isinf() functions were
available (checked by configure)
* isnan and isinf for the math module
* Bessel (1st and 2nd kind), erf, erfc, lgamma function for math module.
They are defined in almost (or all?) math libraries.

Together with http://bugs.python.org/issue1635 it implements most of PEP
754.

--
components: Extension Modules
files: trunk_mathmodule.patch
keywords: patch
messages: 58694
nosy: tiran
priority: normal
severity: normal
status: open
title: Enhancements for mathmodule
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8975/trunk_mathmodule.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: configure
===
--- configure	(Revision 59539)
+++ configure	(Arbeitskopie)
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 59484 .
+# From configure.in Revision: 59533 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.61 for python 2.6.
 #
@@ -20368,6 +20368,9 @@
 fi
 
 
+# 
+# * Check for mathematical functions *
+# 
 # check for hypot() in math library
 LIBS_SAVE=$LIBS
 LIBS="$LIBS $LIBM"
@@ -20473,6 +20476,113 @@
 done
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+for ac_func in copysign erf erfc isnan isinf j0 j1 jn lgamma_r y0 y1 yn
+do
+as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
+{ echo "$as_me:$LINENO: checking for $ac_func" >&5
+echo $ECHO_N "checking for $ac_func... $ECHO_C" >&6; }
+if { as_var=$as_ac_var; eval "test \"\${$as_var+set}\" = set"; }; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+/* Define $ac_func to an innocuous variant, in case  declares $ac_func.
+   For example, HP-UX 11i  declares gettimeofday.  */
+#define $ac_func innocuous_$ac_func
+
+/* System header to define __stub macros and hopefully few prototypes,
+which can conflict with char $ac_func (); below.
+Prefer  to  if __STDC__ is defined, since
+ exists even on freestanding compilers.  */
+
+#ifdef __STDC__
+# include 
+#else
+# include 
+#endif
+
+#undef $ac_func
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char $ac_func ();
+/* The GNU C library defines this for functions which it implements
+to always fail with ENOSYS.  Some functions are actually named
+something starting with __ and the normal name is an alias.  */
+#if defined __stub_$ac_func || defined __stub___$ac_func
+choke me
+#endif
+
+int
+main ()
+{
+return $ac_func ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (ac_try="$ac_link"
+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_link") 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_exeext &&
+   $as_test_x conftest$ac_exeext; then
+  eval "$as_ac_var=yes"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+	eval "$as_ac_var=no"
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
+  conftest$ac_exeext conftest.$ac_ext
+fi
+ac_res=`eval echo '${'$as_ac_var'}'`
+	   { echo "$as_me:$LINENO: result: $ac_res" >&5
+echo "${ECHO_T}$ac_res" >&6; }
+if test `eval echo '${'$as_ac_var'}'` = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define `echo "HAVE_$ac_func" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+done
+
+
 LIBS=$LIBS_SAVE
 
 # check for wchar.h
Index: Include/pyport.h
===
--- Include/pyport.h	(Revision 59539)
+++ Include/pyport.h	(Arbeitskopie)
@@ -349,6 +349,17 @@
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* High precision defintion of pi and e (Euler)
+ * The values are taken from libc6's math.h.
+ */
+#ifndef Py_MATH_PI
+#define Py_MATH_PI 3.1415926535897932384626433832795029L
+#endif
+
+#ifndef Py_MATH_E
+#define Py_MATH_E 2.7182818284590452353602874713526625L
+#endif
+
 /* Py_IS_NAN(X)
  * Return 1 if float or double arg is a NaN, else 0.
  * Caution:
@@ -358,8 +369,12 @@
  *  

[issue1639] Low ascii 12 characters found in source.

[Christian Heimes]

Changes by Christian Heimes:


--
resolution:  -> wont fix
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

[issue1639] Low ascii 12 characters found in source.

[Joseph Armbruster]

Joseph Armbruster added the comment:

I apparently missed this one.  Disregard this issue.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1639] Low ascii 12 characters found in source.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

In pep8 there is:
"""
Python accepts the control-L (i.e. ^L) form feed character as
whitespace; Many tools treat these characters as page separators, so you
may use them to separate pages of related sections of your file.
"""

Why do you want to remove them?

--
nosy: +amaury.forgeotdarc

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

[Christian Heimes]

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?
* You are mixing tabs with spaces. All 2.6 C files and most 3.0 C files
are still using tabs.
* You forgot about %f. For large values the format characters f and F
are using the exponent display, too "%f" % 1e60 == '1e+60'
* 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.
* 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 {

__
Tracker <[EMAIL PROTECTED]>

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

[issue1639] Low ascii 12 characters found in source.

[Joseph Armbruster]

Joseph Armbruster added the comment:

url: http://svn.python.org/projects/python/trunk
rev: 59539
files:
  stringobject.c

Added file: http://bugs.python.org/file8974/ascii12sPyTrunk.patch

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1639] Low ascii 12 characters found in source.

[Joseph Armbruster]

New submission from Joseph Armbruster:

There were various files in the source tree that contained low ascii 12
characters throughout.  The list includes:

url: http://svn.python.org/projects/python/branches/py3k
rev: 59539
files:
  _ctypes.c
  cfield.c
  _tkinter.c
  stringobject.c

--
components: Interpreter Core
files: ascii12sPy3k.patch
messages: 58689
nosy: JosephArmbruster
severity: normal
status: open
title: Low ascii 12 characters found in source.
versions: Python 3.0
Added file: http://bugs.python.org/file8973/ascii12sPy3k.patch

__
Tracker <[EMAIL PROTECTED]>

__

ascii12sPy3k.patch
Description: Binary data
___
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

[Mark Dickinson]

Mark Dickinson added the comment:

Cool!  Works for me.

I agree that it's not 100% clear that round(large_decimal) should return an 
integer rather 
than raising an exception.  But, rightly or wrongly, this is what 
int(large_decimal) does at 
the moment, and it would be surprising to have int and round behave differently 
in this 
respect.  The current behaviour also fits with the way that int(large_float) 
and 
round(large_float) behave, with a valid integer result returned even if that 
integer is
larger than 2**53.

There is of course a problem here that's not present for floats, namely that 
someone can 
write round(Decimal("1e100")) and then wonder why his/her computer takes so 
long to give 
an answer.  I don't really see any way around this, other than perhaps a note 
in the docs.

I notice that math.floor(large_float) and math.ceil(large_float) return floats 
at the 
moment.  Is this something that would change under PEP 3141?  If not, should 
floor(large_decimal) and ceil(large_decimal) return Decimal instances instead 
of integers?

One last thing:  would it be worth backporting some of this to Python 2.6, just 
to avoid 
unnecessary divergence of the Decimal code between 2.x and 3.0?  I guess the 
trunc() 
function calls would have to be replaced by calls to the __trunc__ 
method---would this be a 
problem?

Mark

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

My C is rusty! Attached is new pystrtod.c & diff, this time using
memset() instead of looping to padd with zeros.

Added file: http://bugs.python.org/file8971/pystrtod.c
Added file: http://bugs.python.org/file8972/pystrtod.diff

__
Tracker <[EMAIL PROTECTED]>

__/* -*- Mode: C; c-file-style: "python" -*- */

#include 
#include 

/* ascii character tests (as opposed to locale tests) */
#define ISSPACE(c)  ((c) == ' ' || (c) == '\f' || (c) == '\n' || \
 (c) == '\r' || (c) == '\t' || (c) == '\v')
#define ISDIGIT(c)  ((c) >= '0' && (c) <= '9')
#define ISXDIGIT(c) (ISDIGIT(c) || ((c) >= 'a' && (c) <= 'f') || ((c) >= 'A' && (c) <= 'F'))


/**
 * PyOS_ascii_strtod:
 * @nptr:the string to convert to a numeric value.
 * @endptr:  if non-%NULL, it returns the character after
 *   the last character used in the conversion.
 * 
 * Converts a string to a #gdouble value.
 * This function behaves like the standard strtod() function
 * does in the C locale. It does this without actually
 * changing the current locale, since that would not be
 * thread-safe.
 *
 * This function is typically used when reading configuration
 * files or other non-user input that should be locale independent.
 * To handle input from the user you should normally use the
 * locale-sensitive system strtod() function.
 *
 * If the correct value would cause overflow, plus or minus %HUGE_VAL
 * is returned (according to the sign of the value), and %ERANGE is
 * stored in %errno. If the correct value would cause underflow,
 * zero is returned and %ERANGE is stored in %errno.
 * If memory allocation fails, %ENOMEM is stored in %errno.
 * 
 * This function resets %errno before calling strtod() so that
 * you can reliably detect overflow and underflow.
 *
 * Return value: the #gdouble value.
 **/
double
PyOS_ascii_strtod(const char *nptr, char **endptr)
{
	char *fail_pos;
	double val = -1.0;
	struct lconv *locale_data;
	const char *decimal_point;
	size_t decimal_point_len;
	const char *p, *decimal_point_pos;
	const char *end = NULL; /* Silence gcc */

	assert(nptr != NULL);

	fail_pos = NULL;

	locale_data = localeconv();
	decimal_point = locale_data->decimal_point;
	decimal_point_len = strlen(decimal_point);

	assert(decimal_point_len != 0);

	decimal_point_pos = NULL;
	if (decimal_point[0] != '.' || 
	decimal_point[1] != 0)
	{
		p = nptr;
		  /* Skip leading space */
		while (ISSPACE(*p))
			p++;

		  /* Skip leading optional sign */
		if (*p == '+' || *p == '-')
			p++;

		while (ISDIGIT(*p))
			p++;

		if (*p == '.')
		{
			decimal_point_pos = p++;

			while (ISDIGIT(*p))
p++;

			if (*p == 'e' || *p == 'E')
p++;
			if (*p == '+' || *p == '-')
p++;
			while (ISDIGIT(*p))
p++;
			end = p;
		}
		else if (strncmp(p, decimal_point, decimal_point_len) == 0)
		{
			/* Python bug #1417699 */
			*endptr = (char*)nptr;
			errno = EINVAL;
			return val;
		}
		/* For the other cases, we need not convert the decimal point */
	}

	/* Set errno to zero, so that we can distinguish zero results
	   and underflows */
	errno = 0;

	if (decimal_point_pos)
	{
		char *copy, *c;

		/* We need to convert the '.' to the locale specific decimal point */
		copy = (char *)PyMem_MALLOC(end - nptr + 1 + decimal_point_len);
		if (copy == NULL) {
			if (endptr)
*endptr = (char *)nptr;
			errno = ENOMEM;
			return val;
		}

		c = copy;
		memcpy(c, nptr, decimal_point_pos - nptr);
		c += decimal_point_pos - nptr;
		memcpy(c, decimal_point, decimal_point_len);
		c += decimal_point_len;
		memcpy(c, decimal_point_pos + 1, end - (decimal_point_pos + 1));
		c += end - (decimal_point_pos + 1);
		*c = 0;

		val = strtod(copy, &fail_pos);

		if (fail_pos)
		{
			if (fail_pos > decimal_point_pos)
fail_pos = (char *)nptr + (fail_pos - copy) - (decimal_point_len - 1);
			else
fail_pos = (char *)nptr + (fail_pos - copy);
		}

		PyMem_FREE(copy);

	}
	else {
		unsigned i = 0;
		if (nptr[i] == '-')
			i++;
		if (nptr[i] == '0' && (nptr[i+1] == 'x' || nptr[i+1] == 'X'))
			fail_pos = (char*)nptr;
		else
			val = strtod(nptr, &fail_pos);
	}

	if (endptr)
		*endptr = fail_pos;

	return val;
}


/**
 * PyOS_ascii_formatd:
 * @buffer: A buffer to place the resulting string in
 * @buf_len: The length of the buffer.
 * @format: The printf()-style format to use for the
 *  code to use for converting. 
 * @d: The #gdouble to convert
 *
 * Converts a #gdouble to a string, using the '.' as
 * decimal point. To format the number you pass in
 * a printf()-style format string. Allowed conversion
 * specifiers are 'e', 'E', 'f', 'F', 'g' and 'G'. 
 * 
 * Return value: The pointer to the buffer with the converted string.
 **/
char *
PyOS_ascii_formatd(char   *buffer, 
		   size_t  buf_len, 
		   const char *format, 
		   double  d)
{
	struct lconv *locale_data;
	const char *decimal_point;
	size_

[issue1632] email cannot be imported

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

But the email package does not import smtplib (the dependency is the
other way). Can you please try with the command:
  import email
and paste the whole traceback?

--
nosy: +amaury.forgeotdarc

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

Attached is new version of test_float.py with a few tests to check
str.format() with exponents formats, plus a diff. They test that the
exponent is always 3 digits and that the case of the e in the format is
respected.

Added file: http://bugs.python.org/file8969/test_float.diff
Added file: http://bugs.python.org/file8970/test_float.py

__
Tracker <[EMAIL PROTECTED]>

__*** test_float.py	2007-12-17 08:33:13.0 +
--- test_float.py.orig	2007-12-17 08:25:43.0 +
***
*** 139,157 
  self.assertEqual(format( 1.0, '+f'), '+1.00')
  self.assertEqual(format(-1.0, '+f'), '-1.00')
  
- self.assertEqual("1.234e+009", "{0:.3e}".format(1.23405e+9))
- self.assertEqual("1.234e-009", "{0:.3e}".format(1.23405e-9))
- self.assertEqual("1.234E+009", "{0:.3E}".format(1.23405e+9))
- self.assertEqual("1.234E-009", "{0:.3E}".format(1.23405e-9))
- self.assertEqual("1.234e+027", "{0:.3e}".format(1.23405e+27))
- self.assertEqual("1.234e-027", "{0:.3e}".format(1.23405e-27))
- self.assertEqual("1.234E+027", "{0:.3E}".format(1.23405e+27))
- self.assertEqual("1.234E-027", "{0:.3E}".format(1.23405e-27))
- self.assertEqual("1.234e+132", "{0:.3e}".format(1.23405e+132))
- self.assertEqual("1.234e-132", "{0:.3e}".format(1.23405e-132))
- self.assertEqual("1.234E+132", "{0:.3E}".format(1.23405e+132))
- self.assertEqual("1.234E-132", "{0:.3E}".format(1.23405e-132))
- 
  # % formatting
  self.assertEqual(format(-1.0, '%'), '-100.00%')
  
--- 139,144 



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