Certain numbers reading incorrectly (contain a colon)

[Jody]

On my current installation of PyScripter, certain numbers (see below)
are being read/displayed/interpreted incorrectly.
This problem only occurs when I run a program within PyScripter.
WinPython, IDLE, and the command line all work correctly.
"287100" is being read in as "22870:0.0"
"281210" is being read in as "28120:.0"
"260100" is being read in as "2600:0.0"
"236210" is being read in as "23620:.0"

===Start Test Code===
for x in [287010.0, 287100.0, 281210.0, 260100.0, 236210.0]:
print x
===End Test Code===

===Start Output===
287010.0
2870:0.0
28120:.0
2600:0.0
23620:.0
===End Output===

I discovered this problem while using xlrd and incorrectly attributed
the error to that library. Those discussions can be viewed here.
http://groups.google.com/group/python-excel/browse_thread/thread/53c205e72448e441/ad6e2ceb3ca6f126#ad6e2ceb3ca6f126

The problem occurs on my work computer (winXP 32bit), but does not
occur on my home computer (win 7 64 bit)
I'm using Python 2.7 and PyScripter 2.1.1.0 on both machines.
The issue occurs whether the # is printed or written to a file. So it
is not just a display issue.

Does anyone have any ideas how/why this would occur only within this
interpreter? Thanks for your help.

[Andy Milne]

I reproduced this. It's a python 2.7 issue with INTERNAL versus EXTERNAL engine issue:

32bit XP box with PyScripter 2.1.1.0 and Python 2.7 running the INTERNAL Engine:

*** Internal Python engine  is active ***

>>> 

[Dbg]>>> 

287010.0

2870:0.0

28120:.0

2600:0.0

23620:.0

>>> 

32bit XP box with PyScripter 2.1.1.0 and Python 2.7 running the EXTERNAL Engine:

*** Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32. ***

*** Remote Python engine  is active ***

>>> 

*** Remote Interpreter Reinitialized  ***

>>> 

[Dbg]>>> 

287010.0

287100.0

281210.0

260100.0

236210.0

>>> 

Using 2.6 it works great. So, as a workaround use 2.6 or the external engine.

--
You received this message because you are subscribed to the Google Groups "PyScripter" group.
To post to this group, send email to pyscr...@googlegroups.com.
To unsubscribe from this group, send email to pyscripter+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyscripter?hl=en.

[PyScripter]

Just to make sure.

With the following script

===Start Test Code===
f = open("test.txt", "w")

for x in [287010.0, 287100.0, 281210.0, 260100.0, 236210.0]:

print >> f, x
f.close()
===End Test Code===

text.txt contains wrong output? And it happens with the remote engine
as well?

Very strange! I cannot reproduce this on Win7 and I do not have an XP
machine handy. Could anybody else test this?

On Sep 28, 5:22 pm, Jody <jody1...@gmail.com> wrote:
> On my current installation of PyScripter, certain numbers (see below)
> are being read/displayed/interpreted incorrectly.
> This problem only occurs when I run a program within PyScripter.
> WinPython, IDLE, and the command line all work correctly.
> "287100" is being read in as "22870:0.0"
> "281210" is being read in as "28120:.0"
> "260100" is being read in as "2600:0.0"
> "236210" is being read in as  "23620:.0"
>
> ===Start Test Code===
> for x in [287010.0, 287100.0, 281210.0, 260100.0, 236210.0]:
>     print x
> ===End Test Code===
>
> ===Start Output===
> 287010.0
> 2870:0.0
> 28120:.0
> 2600:0.0
> 23620:.0
> ===End Output===
>
> I discovered this problem while using xlrd and incorrectly attributed

> the error to that library.  Those discussions can be viewed here.http://groups.google.com/group/python-excel/browse_thread/thread/53c2...

[PyScripter]

Thanks Andy.

I was able to reproduce this on Win7 as well
It appears that it happens only with the internal engine, when using
Python 2.7 or Python 3.x. I will investigate.

> On Tue, Sep 28, 2010 at 7:22 AM, Jody <jody1...@gmail.com> wrote:
> > On my current installation of PyScripter, certain numbers (see below)
> > are being read/displayed/interpreted incorrectly.
> > This problem only occurs when I run a program within PyScripter.
> > WinPython, IDLE, and the command line all work correctly.
> > "287100" is being read in as "22870:0.0"
> > "281210" is being read in as "28120:.0"
> > "260100" is being read in as "2600:0.0"
> > "236210" is being read in as  "23620:.0"
>
> > ===Start Test Code===
> > for x in [287010.0, 287100.0, 281210.0, 260100.0, 236210.0]:
> >    print x
> > ===End Test Code===
>
> > ===Start Output===
> > 287010.0
> > 2870:0.0
> > 28120:.0
> > 2600:0.0
> > 23620:.0
> > ===End Output===
>
> > I discovered this problem while using xlrd and incorrectly attributed
> > the error to that library.  Those discussions can be viewed here.
>

> >http://groups.google.com/group/python-excel/browse_thread/thread/53c2...

>
> > The problem occurs on my work computer (winXP 32bit), but does not
> > occur on my home computer (win 7 64 bit)
> > I'm using Python 2.7 and PyScripter 2.1.1.0 on both machines.
> > The issue occurs whether the # is printed or written to a file.  So it
> > is not just a display issue.
>
> > Does anyone have any ideas how/why this would occur only within this
> > interpreter?  Thanks for your help.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PyScripter" group.
> > To post to this group, send email to pyscr...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > pyscripter+...@googlegroups.com<pyscripter%2Bunsu...@googlegroups.com>
> > .

[Jody]

I'm not sure what "remote engine" means, but if i'm in pyscripter and
i ctrl-F9 (run), the file has the wrong output. But if I alt-f9
(external run), it has the correct output.

[PyScripter]

This can be reproduce with the simplest of scripts:

x = 236210.0
print type(x), str(x), x, repr(x)

Output: <type 'float'> 23620:.0 23620:.0 236210.0

For some strange reason str produces the wrong result. And it only
happens with some numbers and not others: x = 287010.0 works OK. Most
weird.

[Andy Milne]

To make the CTRL+F9 work, you need to configure PyScripter to use the Remote engine. Do the following:

From the Menu select "Run", then select "Python Engine", then select "Remote".

You should see

*** Remote Python engine  is active ***

>>> 

in the Python Interpreter window.

--
You received this message because you are subscribed to the Google Groups "PyScripter" group.
To post to this group, send email to pyscr...@googlegroups.com.

To unsubscribe from this group, send email to pyscripter+...@googlegroups.com.

[PyScripter]

Menu option Run, Python Engine, Remote

This is now the default. See http://code.google.com/p/pyscripter/wiki/RemoteEngines
for details.

[Eric S. Johansson]

On 9/28/2010 12:27 PM, PyScripter wrote:
> Just to make sure.
>
> With the following script
>
> ===Start Test Code===
> f = open("test.txt", "w")
> for x in [287010.0, 287100.0, 281210.0, 260100.0, 236210.0]:
> print>> f, x
> f.close()
> ===End Test Code===
>
> text.txt contains wrong output? And it happens with the remote engine
> as well?
>
> Very strange! I cannot reproduce this on Win7 and I do not have an XP
> machine handy. Could anybody else test this?

287010.0
287100.0
281210.0
260100.0
236210.0

w7
*** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
on win32. ***

*** Remote Python engine is active ***

>

[PyScripter]

It works correctly in the internal interpreter with the latest Python
3.2a2. This was probably a Python bug in the new code that handles
float to str conversions (short float representation). See for
example:

http://bugs.python.org/issue9215 (it mentions the ":" !)

I expect that updates to the 3.1 and 2.7 branches to include the fix.
It still escapes me why it works with the standalone python and it
doesn't with the embedded. In any case the morale is that the remote
engine should always be used.

[John Machin]

On Sep 29, 5:06 am, PyScripter <pyscrip...@gmail.com> wrote:
> It works correctly in the internal interpreter with the latest Python
> 3.2a2.  This was probably a Python bug in the new code that handles
> float to str conversions (short float representation).  See for
> example:
>
> http://bugs.python.org/issue9215 (it mentions the ":" !)
>
> I expect that updates to the 3.1 and 2.7 branches to include the fix.
> It still escapes me why it works with the standalone python and it
> doesn't with the embedded.  In any case the morale is that the remote
> engine should always be used.

"Pyscripter" is calling this

"""
This was probably a Python bug in the new code that handles
float to str conversions (short float representation). See for
example:

http://bugs.python.org/issue9215 (it mentions the ":" !)
"""

The referenced Python bug tracker item relates ONLY to one test
failure on one buildbot running Ubuntu and using a dodgy experimental
version of gcc (with an optimisation bug) (if I read the chain of
messages correctly). It's NOT a Python bug in the sense that it was
caused by wrong Python source code. The problem was fixed by
installing a non-buggy compiler on that 1 buildbot.

The problem is showing up on a Windows box -- is Activestate using a
dodgy compiler? And it's showing up only on one of Pyscripter's two
"engines", whatever they are. Is Pyscripter providing C extension
modules using a dodgy C compiler?

I think "Pyscripter" is being a bit too blase about this ...

[PyScripter]

Well here are the facts:
Python 3.1 changed the float to string conversion to address the issue
described in http://drj11.wordpress.com/2007/07/03/python-poor-printing-of-floating-point/.
The changes were back-ported to Python 2.7.

The print statement uses the str() function to convert float to
string. When using the internal interpreter occurs rarely and in
unpredictable ways.

str(38210.0) returns the wrong value
str(37210.0) is ok
str(36210.0) is wrong
str(35210.0) is ok

PyScripter uses the python dll of the official distribution from
python.org and does not mess up with built-in functions. It is the
built-in function (class) that returns the wrong value and not
PyScripter.

Python 3.2a1 presents the same issue, but the recently released 3.2a2
works fine. The code used by str() has been changed again according
to the SVN comment to make str work like repr for float. My
expectation is that this change will be applied to future releases of
Python 2.7 and 3.1, so there is no point in filing a bug report, which
otherwise I would have done.

Also, since this does not affect the default engine of PyScripter I
think the impact on users is minimal.

[PyScripter]

I decided to file a bug report http://bugs.python.org/issue9980.
Let's see what the python gurus might say.

On Sep 29, 5:55 am, PyScripter <pyscrip...@gmail.com> wrote:
> Well here are the facts:
> Python 3.1 changed the float to string conversion to address the issue

> described inhttp://drj11.wordpress.com/2007/07/03/python-poor-printing-of-floatin....

[John Machin]

On 29/09/2010 1:13 PM, PyScripter wrote:
> I decided to file a bug report http://bugs.python.org/issue9980.
> Let's see what the python gurus might say.

You bug report (ans your previous message) say: """This only happens
with the embedded python engine which uses the pythonxx.dll of the
official distribution."""

However the user is using the ActiveState distribution, not the official
(python.org) distribution.

[PyScripter]

I have reproduced the bug with the official distribution.

On Sep 29, 7:23 am, John Machin <sjmac...@lexicon.net> wrote:
> On 29/09/2010 1:13 PM, PyScripter wrote:
>

> > I decided to file a bug reporthttp://bugs.python.org/issue9980.

[PyScripter]

The bug report http://bugs.python.org/issue9980 has caused a flurry of
responses which you might find interesting. In the meantime I have
found a workaround and include that in the next release.