> This may be relevant to the problems you're seeing:
>
> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470
>
> The short story, as the tracker item paints it, is that setting
> LC_NUMERIC to anything other than 'C' can give results like the ones you
> describe
> There is no guarantee at all that a .pyc file is good for any purpose
> outside the machine that produced it. In practice, however, you
> *should* be able to rely on no surprises if you have the same platform
> and the same version of Python; do you?
Python 2.3.5 and 2.3.3 on the test machine -
On Mon, 23 May 2005 12:39:00 +0200, Tomasz Lisowski
<[EMAIL PROTECTED]> wrote:
>Hi,
>
>We are distributing our Python application as the short main script (.py
>file) and a set of modules compiled to the .pyc files. So far, we have
>always treated .pyc files as portable between platforms,
Ther
This may be relevant to the problems you're seeing:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470
The short story, as the tracker item paints it, is that setting
LC_NUMERIC to anything other than 'C' can give results like the ones you
describe---Python itse
Hi,
We are distributing our Python application as the short main script (.py
file) and a set of modules compiled to the .pyc files. So far, we have
always treated .pyc files as portable between platforms, but recently we
have discovered an annoying problem. In a module, there is the following
