[issue36853] inconsistencies in docs builds (Sphinx 2)
David Jones added the comment: I believe the issue is only triggered if you actually have some suspicious markup in your documentation (which is why your plain build on Sphinx 2 appears to work). Remove some lines from Doc/tools/susp-ignored.csv to trigger it. -- nosy: +drj ___ Python tracker <https://bugs.python.org/issue36853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21748] glob.glob does not sort its results
David Jones added the comment: The original bug report did not mention ls (note serhiy.storchaka). It is a red herring. I accept that the Python community doesn't care to have glob.glob sorted. But then I think you should distance yourself from the shell in the documentation. It currently says: "The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell" You could say something like: "The glob module finds all the pathnames matching a specified pattern, using a syntax inspired by the Unix shell; unlike Unix shell the ordering is not guaranteed" -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25511] multiprocessing pool blocks SIGTERM from being handled
New submission from David Jones: This is probably related to #21913, but more specifically concerns the documentation. I have a sub process of a larger program that handles a SIGTERM sent by the main process for a clean shutdown. However, if I launch a parallel task in the sub process, via multiprocessing.Pool.imap_unordered, all signals are blocked until pool finishes running the task. If this isn't going to be fixed, then it ought to at least be clearly documented. It took a very long time to diagnose this problem. It requires a programmer to understand the underlying implementation of a high-level construct, thus defeating the purpose of using a high level construct. Also, is there a way to work around this? -- assignee: docs@python components: Documentation messages: 253678 nosy: djones, docs@python priority: normal severity: normal status: open title: multiprocessing pool blocks SIGTERM from being handled type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21748] glob.glob does not sort its results
New submission from David Jones:
```
for f in glob.glob('input/*/*.dat'): print f
```
outputs:
```
input/ghcnm.v3.2.2.20140611/ghcnm.tavg.v3.2.2.20140611.qca.dat
input/ghcnm.v3.2.2.20140506/ghcnm.tavg.v3.2.2.20140506.qca.dat
```
Note that these are not in the right order. Compare with shell which always
sorts its globs:
```
drj$ printf '%s\n' input/*/*.dat
input/ghcnm.v3.2.2.20140506/ghcnm.tavg.v3.2.2.20140506.qca.dat
input/ghcnm.v3.2.2.20140611/ghcnm.tavg.v3.2.2.20140611.qca.dat
```
I think the shell behaviour is better and we should be allowed to rely on
glob.glob sorting its result.
Note from the documentation: The glob module finds all the pathnames matching
a specified pattern according to the rules used by the Unix shell. The Unix
shell has always sorted its globs.
--
components: Library (Lib)
messages: 220441
nosy: drj
priority: normal
severity: normal
status: open
title: glob.glob does not sort its results
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21748
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20742] 2to3 zip fixer doesn't fix for loops.
New submission from David Jones:
Consider the following code:
for z in zip([1]):pass
2to3 does not convert the zip in this code to list(zip(...)); it does not
change this code at all.
That can be an (obscure) bug because the zip in Python 2 has different
semantics from the zip in Python 3.
The output of this program
from __future__ import print_function
S = []
def l(c):
for i in [0,1]:
S.append(c)
yield i
S.append(c.upper())
la = l('a')
lb = l('b')
for a,b in zip(la, lb):
S.append(#)
print(''.join(S))
is different in Python 2 and Python 3 (when converted with 2to3, which doesn't
change the program).
In Python 2 the output is:
ababA##
In Python 3 the output is:
ab#ab#A
Obviously this example is somewhat contrived, but I have a non-contrived
example involving decoding PNG images (if anyone is interested).
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 211989
nosy: drj
priority: normal
severity: normal
status: open
title: 2to3 zip fixer doesn't fix for loops.
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20742
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
David Jones added the comment: Has there been any progress made on fixing this? I ran into this trying to install numpy via pip, 32-bit python installation on 64-bit Centos 6.4. It get's the compile flags right, but not the linker: C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/opt/python/ia32/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status Someone worked around this by changing ccompiler.py, line 693 to: runtime_library_dirs=None, debug=0, extra_preargs=['-m32'], See: http://stackoverflow.com/questions/11265057/how-do-i-install-a-32-bit-version-of-numpy I tried using the setarch command, which alters the output of uname, but it didn't change anything: setarch i686 pip install numpy This changes the output of uname from Linux centos63-vm 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux to Linux centos63-vm 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 i686 i686 i386 GNU/Linux So if get_platform really depends on uname, then why doesn't this work? -- nosy: +djones ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6387] floor division gives different result for int versus float.
New submission from David Jones d...@pobox.com: Consider: x//y != x//float(y) for some integer values of x and y. For example, x = 2**54-1, and y = 2: x=2**54-1 y=2 x//y 9007199254740991L x//float(y) 9007199254740992.0 _==x//y False I have no idea whether this should actually be a bug or not. The behaviour (above) _is_ the documented behaviour (because the operands are documented as being converted to a common type). But... I think there's a good case for computing the mathematically correct answer regardless of the types of the inputs. For one thing, one of the reasons behind introducing the // operator was to make division the same regardless of whether the inputs were floating point or int. Computing the mathematically correct answer (which since the answer is an integer is always exactly representable in Python) would be better, and simpler to document. -- components: Interpreter Core messages: 89915 nosy: drj severity: normal status: open title: floor division gives different result for int versus float. type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6387] floor division gives different result for int versus float.
David Jones d...@pobox.com added the comment: I do realise that. I still think the mathematically correct answer should be computed, since it can be. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment:
On 12 Feb 2009, at 09:00, David Jones wrote:
David Jones d...@pobox.com added the comment:
The following program does a very basic do-i-get-back-what-i-wrote
test.
sunau can't cope; I am investigating.
I see. sunau uses mu-law compression by default which makes it non-
invertable. How stupid. Inserting:
w.setcomptype('NONE', 'Pointless Argument')
just after setframerate fixes the tests so that all 3 modules pass.
Of course, this is still only the most very basic test that one might
want to do. And it doesn't cover the case mentioned in this bug
report anyway.
(drat, just found this, should've sent it yesterday)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5202
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment:
The following program does a very basic do-i-get-back-what-i-wrote test.
sunau can't cope; I am investigating.
#!/usr/bin/env python
# $Id$
# Audio File Tests
import aifc
import sunau
import wave
import struct
import sys
from StringIO import StringIO
frames = struct.pack('256B', *range(256))
log = sys.stderr
# Basic test of reproducability.
# We test that a set of frames (an entirely artifical set, see `frames`,
# above) can be written to an audio file and read back again to get the
# same set of frames.
# We test mono/stereo, 8-bit/16-bit, and a few framerates.
# As of 2009-02-12 sunau does not pass these tests, so I recommend that
# you remove it.
for af in (aifc, sunau, wave):
for nchannels in (1, 2):
for sampwidth in (1, 2):
for framerate in (11000, 44100, 96000):
print log, %s %d/%d/%d % (af.__name__,
nchannels, sampwidth, framerate)
f = StringIO()
w = af.open(f, 'w')
w.setnchannels(nchannels)
w.setsampwidth(sampwidth)
w.setframerate(framerate)
w.writeframesraw(frames)
w.close()
s = f.getvalue()
f = StringIO(s)
w = af.open(f)
assert w.getnchannels() == nchannels
assert w.getsampwidth() == sampwidth
assert w.getframerate() == framerate
assert w.readframes(len(frames)//nchannels//sampwidth) == frames
assert w.readframes(1) == ''
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5202
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment: On 10 Feb 2009, at 21:15, David Jones wrote: David Jones d...@pobox.com added the comment: On 10 Feb 2009, at 16:57, Guilherme Polo wrote: Guilherme Polo ggp...@gmail.com added the comment: Now, is there some problem if we remove the calls to the tell method in _write_header ? See patch attached (tests are very welcome too). Yes Ahem. Pardon me for answering you without reading your patch. I have now read your patch and it does more than just remove the calls to tell. In fact it looks very fine. It makes wave.py more like sunau.py in that it just knows what the offsets into the header are. I think I like that (especially the way you use the struct format string to compute the second offset). It also removes that nagging question at the back of my mind: why does wave.py use tell when it could simply just know the offsets, which are constant anyway?. And it works. How cool is that? I had changed my project to use sunau anyway, because that worked with pipes already. Tests, you say... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
New submission from David Jones d...@pobox.com: When using the wave module to output wave files, the output file cannot be a Unix pipeline. Example. The following program outputs a (trivial) wave file on stdout: #!/usr/bin/env python import sys import wave w = wave.open(sys.stdout, 'w') w.setnchannels(1) w.setsampwidth(1) w.setframerate(32000) w.setnframes(0) w.close() It can create a wave file like this: $ ./bugex foo.wav When used in a pipeline we get: $ ./bugex | wc Traceback (most recent call last): File ./bugex, line 9, in module w.close() File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py , line 437, in close self._ensure_header_written(0) File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py , line 458, in _ensure_header_written self._write_header(datasize) File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py , line 465, in _write_header self._form_length_pos = self._file.tell() IOError: [Errno 29] Illegal seek Exception exceptions.IOError: (29, 'Illegal seek') in bound method Wave_write.__del__ of wave.Wave_write instance at 0x71418 ignored 0 1 8 The wave module has almost all it needs to work around this problem. The wave module will only seek the output if it needs to patch the header. If you use setnframes to write the correct number of frames before writing them with writeframesraw then the header will not be patched upon calling close. However... The problem is that the tell method is invoked on the output stream (to record where the header is, in the event that we need to patch it); the tell method fails with an exception when the output is a pipeline (see example, above). Exceptions from tell when writing the header initially (in _write_header) should be ignored. If _patchheader is later invoked it will fail due to lack of pos. -- components: Library (Lib) messages: 81539 nosy: drj severity: normal status: open title: wave.py cannot write wave files into a shell pipeline type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment: Attached is a patch which is a diff from this version of wave.py : http://svn.python.org/view/*checkout*/python/trunk/Lib/wave.py?rev=54394 -- keywords: +patch Added file: http://bugs.python.org/file13011/wave-20090210.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment: On 10 Feb 2009, at 12:28, Guilherme Polo wrote: Guilherme Polo ggp...@gmail.com added the comment: Wouldn't it be better if you only ignored the 'illegal seek' error instead of ignoring any ioerror (should it even be always discarded) ? No. I get a 'bad file descriptor' under Windows 7, but, again, can it be always discarded ? Yes. To expand: Observe that the exception is raised when we are writing the header for the first time. The exception is not raised when we attempt to seek to patch the header, it is raised when we recording the file position so that we can seek to it later. We record the file position even though we might not use it later (the file position is only needed if we need to patch the header). So if we don't need to patch the header, we do not need the file position. So we can clearly ignore any error in attempting to get the file position. If we do need to patch the header, then we need the file position. If we do not have the file position (because the earlier attempt to get it failed), then patching the header will fail when it attempts a seek. This seems reasonable to me. You can also reproduce the problem without using wave: import sys sys.stdout.tell() That does not reproduce the problem. The problem is not that tell raises an exception, the problem is that tell raises an exception and it is only being used to get some information that may be not needed later. Therefore the exception should be ignored, and a problem should only be raised if it turns out that we did need for information that we couldn't get. I'm really unsure about the proposed patch. Noted. I also note that my patch can be improved by removing its last 11 lines. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment:
On 10 Feb 2009, at 12:28, Guilherme Polo wrote:
Guilherme Polo ggp...@gmail.com added the comment:
I'm really unsure about the proposed patch.
Perhaps my example was too trivial. The point is that if you call
setnframes then you can get wave.py to avoid patching the header; so
it does not need to seek on the output file. However, that _still_
doesn't let you pipe the output, because of the tell problem.
That's what the patch is for.
Here is a (slightly) less trivial example:
#!/usr/bin/env python
import sys
import wave
w = wave.open(sys.stdout, 'w')
w.setnchannels(1)
w.setsampwidth(1)
w.setframerate(2000)
w.setnframes(100)
for _ in range(50): w.writeframesraw('\x00\xff')
w.close()
(The wave file that it outputs is 100ms of 1000 Hz sine wave by the way)
Note the call to setnframes _before_ the data is written. That's
what means the header does not need to be patched. With my patch
applied the output of this program can be fed to a pipe.
If you remove the call to setnframes then the header will need to be
patched, and this still (correctly, usefully) raises an error with my
patch applied.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5202
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment: On 10 Feb 2009, at 13:02, David Jones wrote: I also note that my patch can be improved by removing its last 11 lines. Er, no it can't. What was I thinking? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones d...@pobox.com added the comment: On 10 Feb 2009, at 16:57, Guilherme Polo wrote: Guilherme Polo ggp...@gmail.com added the comment: Now, is there some problem if we remove the calls to the tell method in _write_header ? See patch attached (tests are very welcome too). Yes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4085] 2.5.2 whatsnew document corrupts names, by having broken HTML, at least on the Web.
New submission from David Jones [EMAIL PROTECTED]: Consider the web page: http://www.python.org/doc/2.5.2/whatsnew/acks.html (the problem appears throughout the whatsnew document, but that page happens to be short and have more than one instance). On my browser, Safari 3.1.2 on Intel OS X 10.4.11, Martin von Löwis has his name corrupted, as does Lars Gustäbel. The problem seems to be because whilst the page is encoded in utf-8 the web server does not transmit a Content-Type header that specifies utf-8: $ curl -I http://www.python.org/doc/2.5.2/whatsnew/acks.html HTTP/1.1 200 OK Date: Thu, 09 Oct 2008 08:51:22 GMT Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_wsgi/2.0 Python/2.4.4 Last-Modified: Fri, 22 Feb 2008 12:58:18 GMT ETag: 12c008-1336-c6b00e80 Accept-Ranges: bytes Content-Length: 4918 Content-Type: text/html Shouldn't that be Content-Type: text/html; charset=UTF-8? Yeah, probably. Shouldn't the browser be using the meta tag in the HTML file itself? Probably, but your broken HTML is preventing Safari from parsing the meta tag correctly. Specifically: $ curl http://www.python.org/doc/2.5.2/whatsnew/acks.html | grep rel=.first. link rel=first href=whatsnew25.html title='What's new in python 2.5' / The title attribute of that link element is incorrect. It features a single-quote inside a single-quoted string. Oopsie. I don't think Safari should be so mean, but bad HTML is bad HTML. Taking a local copy and fixing that title attribute (by using double quotes for example) causes the page to render just fine. -- assignee: georg.brandl components: Documentation messages: 74560 nosy: drj, georg.brandl severity: normal status: open title: 2.5.2 whatsnew document corrupts names, by having broken HTML, at least on the Web. type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4025] C99 comments in Python 2.6 break build on AIX 6.1
New submission from David Jones [EMAIL PROTECTED]: Doing a plan configure then make; the compilation breaks due to // style comments in a file called Objects/frameobject.c: cc_r -qlanglvl=extc89 -c -DNDEBUG -O -I. -IInclude -I./Include - DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c Objects/frameobject.c, line 520.9: 1506-046 (S) Syntax error. Full transcript attached. Furthermore, attempting to select a more permissive (better?) compiler, with CC=c99 ./configure --without-gcc for example, doesn't work because of the bug reported in http://bugs.python.org/issue1633863 (CC is ignored). I will comment separately in that issue. It is my understanding (per my blog article http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/ ) that the code is now c89 clean (or at least as clean as «gcc -std=c89 - Werror» can make it. That means you should be able to close this bug fairly quickly. :) After I've hacked the configure script the build still fails, but for different reasons. I'll file another bug for that. -- components: Interpreter Core files: py26aix61script1 messages: 74229 nosy: drj severity: normal status: open title: C99 comments in Python 2.6 break build on AIX 6.1 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file11687/py26aix61script1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1633863] AIX: configure ignores $CC
David Jones [EMAIL PROTECTED] added the comment:
This is still a problem for Python 2.6 on AIX 6.1.
The simplest fix is to change «CC=cc_r» to «CC=${CC:-xlc_r}» but I have no
idea how to go about changing the configure script.
--
nosy: +drj
versions: +Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1633863
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
New submission from David Jones [EMAIL PROTECTED]: After hacking the configure script to work around the issues http://bugs.python.org/issue4025 and http://bugs.python.org/issue1633863 the build still fails: building 'fcntl' extension xlc_r -DNDEBUG -O -I. -I/home/u0006584/Python-2.6/./Include -I. - IInclude -I./Include -I/home/u0006584/Python-2.6/Include - I/home/u0006584/Python-2.6 -c /home/u0006584/Python- 2.6/Modules/fcntlmodule.c -o build/temp.aix-6.1- 2.6/home/u0006584/Python-2.6/Modules/fcntlmodule.o ./Modules/ld_so_aix xlc_r -bI:Modules/python.exp build/temp.aix-6.1- 2.6/home/u0006584/Python-2.6/Modules/fcntlmodule.o -o build/lib.aix-6.1- 2.6/fcntl.so ld: 0711-317 ERROR: Undefined symbol: .flock ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. *** WARNING: renaming fcntl since importing it failed:0509-022 Cannot load module build/lib.aix-6.1-2.6. 0509-026 System error: A file or directory in the path name does not exist. error: No such file or directory make: 1254-004 The error code from the last command is 1. (Full transcript attached) I'm mystified and I can't log in to the AIX box right now. This does not appear to be the same as http://bugs.python.org/issue1756343 and http://bugs.python.org/issue1694442 which both appear to be the same, but documenting a differen AIX build problem. -- files: py26aix61script2 messages: 74231 nosy: drj severity: normal status: open title: fcntl extension fails to build on AIX 6.1 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file11688/py26aix61script2 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3166] Make conversions from long to float correctly rounded.
David Jones [EMAIL PROTECTED] added the comment: I agree, longs should be correctly rounded when coerced to floats. There is an ugly (but amusing) workaround while people wait for this patch: Go via a string: int(float(repr(295147905179352891391)[:-1])) Though I assume this relies on the platform's strtod working correctly. Which it does for me. -- nosy: +drj ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
