[issue1455] VS2008, quick hack for distutils.msvccompiler

[Martin v. Löwis]

Martin v. Löwis added the comment:

This issue is closed, and didn't really deal with VS 2005 at all, so we
should avoid tracking any further changes in it.

I personally don't care about the PCbuild8 folder at all. It can be
removed, updated, replaced with that script - whatever people like most.
You might want to ask Kristjan Jonsson (who created it originally) about
its fate.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1458] installer crashes on attempted cancellation

[Christian Heimes]

Changes by Christian Heimes:


--
assignee:  -> loewis
nosy: +loewis
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1690] Crash on cancellation of windows install

[Christian Heimes]

Changes by Christian Heimes:


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> installer crashes on attempted cancellation

__
Tracker <[EMAIL PROTECTED]>

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

[issue1713] posixpath.ismount() claims symlink to a mountpoint is a mountpoint.

[Christian Heimes]

Christian Heimes added the comment:

A fix for the problem is easy. One has to replace os.stat() with os.lstat():

def ismount(path):
"""Test whether a path is a mount point"""
try:
s1 = os.stat(path)
s2 = os.stat(join(path, '..'))
except os.error:
return False # It doesn't exist -- so not a mount point :-)
dev1 = s1.st_dev
dev2 = s2.st_dev
if dev1 != dev2:
return True # path/.. on a different device as path
ino1 = s1.st_ino
ino2 = s2.st_ino
if ino1 == ino2:
return True # path/.. is the same i-node as path
return False

--
nosy: +tiran
priority:  -> low
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

[issue1714] ConfigParser.py do not allow leading (and trailing) space in values.

[Miroslav Suchy]

New submission from Miroslav Suchy:

I have some configuration params with leading space. And program
(getmail4) which use ConfigParser.py. ConfigParser strip all leading
(and trailing) spaces from values. This is very often the most wanted
result. But if I want value with leading space I have no option to put
it there.
Therefore I suggest to optionaly write string value as
key = "value"

This patch will solve it (it is against my OS, sorry no chance to
checkout svn).

--- /usr/lib/python2.4/ConfigParser.py.orig 2007-12-31
16:04:32.0 +0100
+++ /usr/lib/python2.4/ConfigParser.py  2007-12-31 16:06:50.0 +0100
@@ -472,6 +472,7 @@
 if pos != -1 and optval[pos-1].isspace():
 optval = optval[:pos]
 optval = optval.strip()
+optval = optval.strip('"')
 # allow empty values
 if optval == '""':
 optval = ''

--
components: Extension Modules
messages: 59060
nosy: msuchy
severity: normal
status: open
title: ConfigParser.py do not allow leading (and trailing) space in values.
type: behavior
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue1694] floating point number round failures under Linux

[Mark Dickinson]

Mark Dickinson added the comment:

Is there anything in the Python documentation that implies that '%.1f' % 2.25 
should be the string '2.3'?  I know 
that the documentation for the builtin round function implies that round(2.25, 
1) should be (the closest 
representable float to) 2.3, but that's a separate issue.

As far as I can tell, the float formatting of Python derives its behaviour 
fairly directly from that of the C 
library.  And the C language specification seems to be pretty much silent on 
the exact rounding behaviour of the 
%e, %f and %g conversion specifiers, so it's not clear that either the Linux 
result or the Windows result is wrong.  
I'm actually more surprised by the Windows result:  I'd expect %f to do 
round-to-nearest, with halfway results like 
this one rounded to the string with even last digit.

Incidentally, on OS X 10.4.11/Intel, I get the same as on Linux:

Python 2.5.1 (r251:54863, Dec 18 2007, 11:48:56) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print '%.1f' % 2.25
2.2

--
nosy: +marketdickinson

__
Tracker <[EMAIL PROTECTED]>

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

[issue1694] floating point number round failures under Linux

[Tim Peters]

Tim Peters added the comment:

Right, Unix-derived C libraries generally do IEEE-754 "round to
nearest/even" rounding, while Microsoft's do "add a half and chop"
rounding.  The Python reference manual says nothing about this, and
neither does the C standard (well, C89 doesn't; unsure about C99).

Python's round() function is independent of the platform C
string<->float conversions, and intentionally does (as documented) "add
a half and chop" rounding.

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

[issue1692] Syntax Error exception dosen't print string; not informative

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser:


--
nosy: +kbk

__
Tracker <[EMAIL PROTECTED]>

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

[issue1694] floating point number round failures under Linux

[Mark Dickinson]

Mark Dickinson added the comment:

It's worth noting that Python's round function doesn't quite work as 
advertised, either:

Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> round(562949953421312.5, 1)
562949953421312.62

__
Tracker <[EMAIL PROTECTED]>

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

[issue1507224] sys.path issue if sys.prefix contains a colon

[Mattie]

Mattie added the comment:

This is also proving to be a problem in various places for applications
embedding Python 2.5 on Linux. For example, my EventScripts plugin
embeds Python into Counter-Strike: Source game servers. It's not
uncommon at all for these servers to use a colon in their path names, as
rental companies will often assign the directories as
myuser/IPADDRESS:PORT/cstrike. For embedding Python we have some tricks
that allow us to bypass this sometimes, but it is rather inconvenient.

In addition to sys.path, I haven't looked into it deeply, but I believe
the codecs search path also seems to get confused when the local
directory has a colon somewhere in it.

Please consider revitalizing this bug, if possible. Thanks for
considering it.

--
nosy: +Mattie

_
Tracker <[EMAIL PROTECTED]>

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

[issue1694] floating point number round failures under Linux

[Tim Peters]

Tim Peters added the comment:

Nice example!  Yes, the round() implementation is numerically naive, in
this particular case ignoring that x+0.5 isn't necessarily representable
(it multiplies the input by 10.0, adds 0.5, takes the floor, then
divides by 10.0, and in this specific case adding 0.5 loses information
to rounding:

>>> 5629499534213125 + 0.5
5629499534213126.0

).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1715] Make pydoc list submodules

[Gustavo J. A. M. Carneiro]

New submission from Gustavo J. A. M. Carneiro:

Often python extension modules define submodules like this:

static PyObject *
initfoo_xpto(void)
{
PyObject *m;
m = Py_InitModule3("foo.xpto", foo_xpto_functions, NULL);
[...]
return m;
}

PyMODINIT_FUNC
initfoo(void)
{
PyObject *m;
PyObject *submodule;
m = Py_InitModule3("foo", foo_functions, NULL);
[...]
submodule = initfoo_xpto();
Py_INCREF(submodule);
PyModule_AddObject(m, "xpto", submodule);
}

Unfortunately pydoc does not list these submodules.  Attached patch
fixes it.

--
components: Demos and Tools
files: pydoc-submodules.diff
messages: 59067
nosy: gustavo
severity: normal
status: open
title: Make pydoc list submodules
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9038/pydoc-submodules.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Lib/pydoc.py
===
--- Lib/pydoc.py	(revision 59634)
+++ Lib/pydoc.py	(working copy)
@@ -1064,6 +1064,14 @@
 result = result + self.section(
 'PACKAGE CONTENTS', join(modpkgs, '\n'))
 
+submodules = []
+for key, value in inspect.getmembers(object, inspect.ismodule):
+submodules.append(key)
+if submodules:
+submodules.sort()
+result = result + self.section(
+'SUBMODULES', join(submodules, '\n'))
+
 if classes:
 classlist = map(lambda (key, value): value, classes)
 contents = [self.formattree(
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1716] String format operator '%i' fails for large floats

[Christopher Tur Lesniewski-Laas]

New submission from Christopher Tur Lesniewski-Laas:

To reproduce:
>>> '%i' % 12345678901.0
TypeError: int argument required

Contrast with:
>>> '%i' % 1234567890.0
'1234567890'

Previous experience led me to expect that the '%i' format code would
work for all numerical types.  Admittedly, there's nothing in the docs
promising this, but it works *almost* all the time.

In fact, the operator fails to convert floats which are too big to fit
into a machine long.  The code for the '%i' operator handles objects of
type long specially, and then uses PyInt_AsLong to handle all other
objects (in formatint).

The ideal solution would be to ask the object to convert itself into an
int *before* the special test for type long; this would give the
expected behavior.

An acceptable solution would be to make the behavior consistent by
refusing all floats passed as the argument to '%i', but I expect this
would break a lot of code.  Of course, right now most of that code is
broken anyway, since it will throw a TypeError when the input float
happens to be large.

--
components: Interpreter Core
messages: 59068
nosy: ctl
severity: normal
status: open
title: String format operator '%i' fails for large floats
versions: Python 2.5, 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

[issue1716] String format operator '%i' fails for large floats

[Guido van Rossum]

Guido van Rossum added the comment:

On the one hand, if you want to format a float like that, you should use
"%.0f".  On the other hand, this should either consistently fail or
succeed, not depending on how large the float is.

I think in 2.6 we can't change this, but in 3.0, I propose that all
these accept only integers.  I find the behavior of %x and %o with
floats particularly anti-intuitive.

On the third hand, we're expecting % to be phased out in favor of
.format(), which allows floats of any value with the i, d, o, x format
specifiers.  So perhaps we should leave this alone?

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

[issue1693] Please check merge from trunk

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 59636.

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