Re: Python compiled by tcc
Am 21.05.17 um 12:38 schrieb bartc: On 21/05/2017 10:32, Christian Gollwitzer wrote: Am 18.05.17 um 10:10 schrieb Christian Gollwitzer: The whole discussion reminds me of the "bumblebees can't fly" thing. tcc is a very small compiler (some 100kb) which supports most of C99. For what it's worth, I compiled Python 3.6.1 on Linux/x86 using tcc. It was a simple matter of cloning tcc, compiling/installing it and the doing CC=tcc ./configure make BTW, how long did an incremental change take to build? I've measured 5 seconds before with gcc. Tcc might be slower in its generated code, but if you just want to quickly see the result of a modification, that the result might run at half the speed is irrelevant. If I do touch Python/Python-ast.c time make python it says real0m0.564s user0m0.394s sys 0m0.149s BTW the Xlinker option is a good example to see why autoconf is needed. They were lazy and had a simple switch on `uname` to find the option, instead of testing it with the compile-macros of autoconf. (Not such good news for me, as now I feel obliged to make my own C compiler manage it. And it sort of competes with tcc for compilation speed (and size too but that wasn't intentional). However it lacks some C99 features at the minute.) haha :) Good luck with that. Remember, tcc supports x86, x86_64, MIPS, ARM, ARM64, and C67, so it is a serious beast. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Python compiled by tcc
On 21/05/2017 10:32, Christian Gollwitzer wrote: Am 18.05.17 um 10:10 schrieb Christian Gollwitzer: The whole discussion reminds me of the "bumblebees can't fly" thing. tcc is a very small compiler (some 100kb) which supports most of C99. For what it's worth, I compiled Python 3.6.1 on Linux/x86 using tcc. It was a simple matter of cloning tcc, compiling/installing it and the doing CC=tcc ./configure make in the Python source folder. It only failed at the final linker step, because the tcc linker does not understand the flags -Xlinker -export-dynamic. The compilation was extremely fast, it took 5s of wall clock time and 3s of user time to go from the sources to the python executable. That's good news, the fact that such a small compiler can go a good way towards compiling quite an elaborate project, with only some technicalities getting in the way. (And it makes you wonder what on earth those other tools are up to.) BTW, how long did an incremental change take to build? I've measured 5 seconds before with gcc. Tcc might be slower in its generated code, but if you just want to quickly see the result of a modification, that the result might run at half the speed is irrelevant. (Not such good news for me, as now I feel obliged to make my own C compiler manage it. And it sort of competes with tcc for compilation speed (and size too but that wasn't intentional). However it lacks some C99 features at the minute.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Python compiled by tcc
Am 18.05.17 um 10:10 schrieb Christian Gollwitzer: The whole discussion reminds me of the "bumblebees can't fly" thing. tcc is a very small compiler (some 100kb) which supports most of C99. For what it's worth, I compiled Python 3.6.1 on Linux/x86 using tcc. It was a simple matter of cloning tcc, compiling/installing it and the doing CC=tcc ./configure make in the Python source folder. It only failed at the final linker step, because the tcc linker does not understand the flags -Xlinker -export-dynamic. The compilation was extremely fast, it took 5s of wall clock time and 3s of user time to go from the sources to the python executable. The ./python executable generated this way does work as far as I can tell, however "make test" fails with an import error - module "socket" is not available. Additionally, after linking "python", the compilation went on and required a C++ compiler, which was no problem in itself, but of course fell back to g++ - tcc only supports pure C. So IMHO it should be a breeze to compile a pure C Python extension into something which successfully runs with the gcc compiled python. On OSX, it was not successfull, because tcc cannot yet create executable binaries on disk in Mach-O format, however, ibraries are possible and runtime-linking (JIT) works without problems. I guess that compiling the full thing on Windows could work with CC=tcc, if the GNU utils arae available (Cygwin/MSYS/Linux subsystem) Christian -- https://mail.python.org/mailman/listinfo/python-list
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by R. David Murray rdmur...@bitdance.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Larry Hastings added the comment: Pull request accepted and merged. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Here's the pull request: https://bitbucket.org/larry/cpython350/pull-requests/4/21167-fix-definition-of-nan-when-icc-used/diff -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Roundup Robot added the comment: New changeset d9c85b6bab3a by R David Murray in branch '2.7': #21167: Fix definition of NAN when ICC used without -fp-model strict. https://hg.python.org/cpython/rev/d9c85b6bab3a New changeset 5e71a489f01d by R David Murray in branch '3.4': #21167: Fix definition of NAN when ICC used without -fp-model strict. https://hg.python.org/cpython/rev/5e71a489f01d New changeset e3008318f76b by R David Murray in branch '3.5': Merge: #21167: Fix definition of NAN when ICC used without -fp-model strict. https://hg.python.org/cpython/rev/e3008318f76b New changeset 1dd4f473c627 by R David Murray in branch 'default': Merge: #21167: Fix definition of NAN when ICC used without -fp-model strict. https://hg.python.org/cpython/rev/1dd4f473c627 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Thanks Chris, and Mark. I ran the tests on 3.6 both on Linux (non ICC) and on Mac (with ICC without -fp-model strict) and all the tests passed. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Larry, do you want this for 3.5.0a2? It's an innocuous patch for anyone not using ICC, and makes ICC just work (with the default ICC build arguments) for people using ICC. (Well, on (lin/u)nux and mac, anyway, I'm not sure we've resolved all the ICC issues on Windows yet.) -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Larry Hastings added the comment: Assuming that ICC_NAN_STRICT is only on for Intel icc: yes, please. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: I've applied this patch to 2.7 on OSX and compiled without -fp-model strict, and all of the tests now pass. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Now, what's the equivalent patch for python3? Should I open a new issue for that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Nevermind, I forgot to try and see if it applied...and it does :) -- versions: +Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Chris Hogan added the comment: From Clark Nelson: In my opinion, exactly how and where the macro is defined that indicates our conformance to the FP standard doesn't really matter. The point is that it is our intention to conform, at least to some degree and under some circumstances. Under those circumstances, it would be wrong to map (0 * x) to 0 without regard to what x might be. Clark -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Note that Chris' patch is coming from Intel. (The ICC buildbots are currently building with -fp-model strict, by the way.) Mark, Stefan, what do you think? Is this a good idea? IIUC we would then not have to worry about differentiating between the python build and the distutils flags, and users would get whatever they specified at python build time. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Chris Hogan added the comment: Producing NaN by Py_HUGE_VAL / Py_HUGE_VAL as in the suggested patch is unsafe as it can generate a FP exception during runtime. Also aggresive compiler FP optimizations can eliminate this calculation on compile-time. For this reason, we've used constant referencing in our fix, which will work regardless of how -fp-model is set. The problem is that the compiler is free to pre-compute the result as both values in 0*Inf are constants. An aggressively optimizing compiler could treat 0 * x = 0 no matter what x is. So under aggressive floating point optimizations setting we could get a wrong value, and that is indeed what happens. Another problem is that 0 * Inf along with resulting in a QNaN value should raise an invalid floating point exception flag. If the result is pre-computed at compile time, then the user won’t see the flag (it is another question whether the user wanted the flag or not originally). Our patch preserves both the value and the side effect, and leaves people free to build with the flags they want. -- nosy: +christopher.hogan Added file: http://bugs.python.org/file40162/intel-nan-safe.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment: Looks fine to me. IIRC, we moved the PyFloat_FromString implementation away from using Py_NAN in Python 3 for exactly this reason. On this point, though: An aggressively optimizing compiler could treat 0 * x = 0 no matter what x is. Wouldn't such a compiler be in violation of the C standard, at least if it defines __STDC_IEC_559__? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Scholes C added the comment: please disregard , the issue is resolved with your patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Scholes C added the comment:
HI,
can you please look into this ?
thanks.
icc builds of python 2.7 seem to have issues handling nan, inf, etc
$ /usr/local/python-2.7.6/bin/python
Python 2.7.6 (default, Jan 10 2014, 12:14:02)
[GCC Intel(R) C++ gcc 4.1 mode] on linux2
Type help, copyright, credits or license for more information.
print float('nan')
0.0
$ /usr/local/python-2.6.6-64bit/bin/python
Python 2.6.6 (r266:84292, Oct 14 2010, 15:47:19)
[GCC Intel(R) C++ gcc 4.1 mode] on linux2
Type help, copyright, credits or license for more information.
print float('nan')
nan
I tried both –fp-model strict and –fp-model precise compiler options as
suggested by http://bugs.python.org/issue21167, but neither seems to resolve
other situations like the one with atan2 below:
$ LD_LIBRARY_PATH=/dat/sharefolder_scratch/python-build ./python
Python 2.7.9 (default, Feb 18 2015, 19:58:37)
[GCC Intel(R) C++ gcc 4.1 mode] on linux2
Type help, copyright, credits or license for more information.
print float('nan')
nan
import math
print math.atan2(0, float('nan'))
0.0
$ /usr/local/python-2.6.6-64bit/bin/python
Python 2.6.6 (r266:84292, Oct 14 2010, 15:47:19)
[GCC Intel(R) C++ gcc 4.1 mode] on linux2
Type help, copyright, credits or license for more information.
import math
print math.atan2(0, float('nan'))
nan
--
nosy: +Scholes.C
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: Note that defaulting to unsafe math in extensions will make *their* use of the Py_NAN macro break under icc. If we go that route (-fp-model strict for Python build, but not for extensions), we should also apply the attached patch that defines Py_NAN as Py_HUGE_VAL / Py_HUGE_VAL. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment:
Using -fp-model strict (or other appropriate icc flag) seems like a reasonable
resolution.
It should likely also be applied to Python 3.x, despite the version field of
this issue. (Even if float('nan') happens to work in current 3.x, internal code
that returns Py_NAN can and will break.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Stefan Krah added the comment: Mark, if you agree that fp-model strict should not show up in the distutils CFLAGS once Python is installed, the issue now depends on #21121. -- dependencies: +-Werror=declaration-after-statement is added even for extension modules through setup.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment: Sure, if that's really the expectation. I'm not sure I'd want any of *my* extension modules being built with non-strict FP, but there's a bit of a personal bias there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Stefan Krah added the comment: I quite agree, and it's hard to tell what users want. Basically I'm afraid of a bug report C extension using unsafe math got slower in Python-3.5. I would find either decision reasonable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
New submission from Hrvoje Nikšić:
On a Python compiled with Intel C compiler, float('nan') returns 0.0. This
behavior can be reproduced with icc versions 11 and 12.
The definition of Py_NAN in include/pymath.h expects `HUGE_VAL * 0.0` to
compile to a NaN value on IEEE754 platforms:
/* Py_NAN
* A value that evaluates to a NaN. On IEEE 754 platforms INF*0 or
* INF/INF works. Define Py_NO_NAN in pyconfig.h if your platform
* doesn't support NaNs.
*/
#if !defined(Py_NAN) !defined(Py_NO_NAN)
#define Py_NAN (Py_HUGE_VAL * 0.)
#endif
I don't have a copy of the standard, but a simple test shows that the above
does not hold for icc. When compiled with icc without any flags, the following
program outputs inf 0.00 instead of the expected inf nan:
#include stdio.h
#include math.h
int main()
{
double inf = HUGE_VAL;
double nan = HUGE_VAL * 0;
printf(%f %f\n, inf, nan);
return 0;
}
Compiling the same program with gcc yields the expected output of inf nan.
This issue can be fixed (or worked around, if it's an icc bug) by using a
different definition of Py_NAN. On icc, defining Py_NAN as `Py_HUGE_VAL /
Py_HUGE_VAL` produces the intended effect. If this is considered suboptimal on
other compilers, the definition can be conditionally compiled for icc only.
The attached patch fixes the issue, taking the conservative approach of only
modifying the icc definition of Py_NAN.
--
components: Interpreter Core
files: intel-nan.diff
keywords: patch
messages: 215687
nosy: hniksic
priority: normal
severity: normal
status: open
title: float('nan') returns 0.0 on Python compiled with icc
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file34746/intel-nan.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Stefan Krah added the comment: Did you compile with -fp-model strict? IIRC icc is not IEEE-754 compliant by default. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by Jurica Bradarić jbrada...@gmail.com: -- nosy: +jbradaric ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment:
What's `sys.float_repr_style` for this build? For Python 3.5 and short float
repr, `float('nan')` shouldn't even be using Py_NAN. It should land in
_Py_parse_inf_or_nan in pystrtod.c, which uses `_Py_dg_stdnan` to get the NaN
value directly from a suitable bitpattern.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: sys.float_repr_style is 'short'. I haven't actually tried this in Python 3.5, but I did note the same definition of Py_NAN (which is used elsewhere in the code), so I tagged the issue as likely also present in 3.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: The compilation was performed with the default flags, i.e. without -fp-model strict or similar. If Python requires strict IEEE 754 floating-point, it should probably be mentioned at a prominent place in the documentation. Administrators building Python with alternative compilers or on non-gcc Unix systems might not be aware of the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment:
I tagged the issue as likely also present in 3.x.
So I believe that this particular issue (float('nan') giving zero) should not
be present on Python 3.4 or above. The bogus definition of Py_NAN will still
cause problems in some math and cmath return values, though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment: If Python requires strict IEEE 754 floating-point, It doesn't (at the moment). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by Mark Dickinson dicki...@gmail.com: -- versions: -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: Mark: If Python requires strict IEEE 754 floating-point, It doesn't (at the moment). Does this imply that my patch is a better fix than requiring the builder to specify -fp-model strict to icc? For our use case either solution is valid. For administrators and users testing or using Python with icc, it might be more convenient for Py_NAN to do the right thing with the default icc flags. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment: It doesn't (at the moment). Sorry; that was an unhelpful kneejerk reply. There are two aspects to this. (1) Currently, at least in theory, CPython doesn't require IEEE 754 *at all*: in theory, it should work with whatever floating-point format the platform's double type happens to provide. In practice I suspect there's a lot more IEEE 754 dependence in the codebase than we realize, and I'd expect to see a fair amount of test breaking if Python were ever to meet a non-IEEE 754 platform. (Reports of any *recent* occurrences of Python in the wild meeting non-IEEE 754 platforms would be welcomed.) (2) If CPython *does* figure out that it's running on an IEEE 754 platform then yes, care should be taken with compiler flags to ensure that we're not using compiler optimisations that have the potential to break IEEE semantics. Without this there's a significant danger of float to string conversions getting messed up; there are also a few odds and ends in the math and cmath libraries that depend on careful IEEE semantics. (The implementations of fsum and log1p, for example.) I think the right fix here is to add the relevant compiler flag to the build. That said, I'd *also* love to see remaining uses of Py_NAN fixed to use _Py_dg_stdnan where available. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Stefan Krah added the comment: I agree we should add -fp-model strict to the icc build flags, provided that there is a way that it does not show up in the distutils flags. Apparently icc users want unsafe fast math by default, so this flag should probably not be enforced in extension module builds. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Query on Python Compiled source--Urgent
On 14/10/2013 06:41, chandan kumar wrote:
I'm working on a python project for protocol testing.I need to provide
only python compiled source to our customer.
Here are the steps followed to take python compiled from actual source.
1.There are 5 different test suites under the project
2..Run all 5 test suite with python sources.
3.After completion of test suite ,just take .pyc files and copied in to
seperate folder.
4.Re run test suite for any issues with the .pyc code.I started seeing
one issue when it logs the test results in to excel file.
This issue occurs sometimes.50% of chances are there to see this issue
Below is the error
Traceback (most recent call last):
File D:\users\ScriptTestCode\scriptsCompiledCode\ExecuteScripts.py,
line 32, in module
TestManager.execute_scripts(TEST_BUILD)
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 764, in execute_scripts
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 772, in _execute_all
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 924, in _testsuite_950_band
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 377, in exec_test_suite
File D:\users\ScriptTestCode\scripts\ResultReporter.py, line 321, in
save_test_results
_my_doc.save(StackTestData.TEST_REPORT_PATH)
File C:\Python27\lib\site-packages\pyExcelerator\Workbook.py, line
610, in save
doc.save(filename, self.get_biff_data())
File C:\Python27\lib\site-packages\pyExcelerator\CompoundDoc.py,
line 554, in save
f = file(filename, 'wb')
IOError: [Errno 22] invalid mode ('wb') or filename:
'.\\TestResults\\TestReport.xls'
Now my question is of there any issue with logging to excel it should
happen for the first test suite itself,but it occurs in either 2,3,4 or
5 test suite. Some it runs without any issues.
Well, the fact that it works/fails 50% of the time points to a race
condition. You don't say how the test suites / tests are running, but if
anything's running in parallel, one test's cleanup could be pulling the
file out from under another test's writing results. Without knowing more
about your test runner, this is really guess-work.
Logging to Excel isn't part of the builtin logging module so you've
presumably added that functionality yourself. But PyExcelerator is
ultimately just opening a file and writing to it so for this purpose it
appears to be equivalent to, say, logging a bunch of stuff into a list
and then writing that into a file.
TJG
--
https://mail.python.org/mailman/listinfo/python-list
Re: Query on Python Compiled source--Urgent
Hi,
Yes ,its not actual logging module.Using pyexcelerator we are storing just test
results to excel file.
Each test suite has some 25-100 test cases.We are using unit test from python
,after completion of each test case the test result will be stored in excel
file.Below is the sample result that is stored in excel file.
S.No TestCaseID TestDescription TestResult
1 Test_case_1 SetTransmitPower Pass
2 Test_case_2 Set Frequency fail
Nothing is running parallel.
Best Regards,
Chandan
On Monday, 14 October 2013 1:10 PM, Tim Golden m...@timgolden.me.uk wrote:
On 14/10/2013 06:41, chandan kumar wrote:
I'm working on a python project for protocol testing.I need to provide
only python compiled source to our customer.
Here are the steps followed to take python compiled from actual source.
1.There are 5 different test suites under the project
2..Run all 5 test suite with python sources.
3.After completion of test suite ,just take .pyc files and copied in to
seperate folder.
4.Re run test suite for any issues with the .pyc code.I started seeing
one issue when it logs the test results in to excel file.
This issue occurs sometimes.50% of chances are there to see this issue
Below is the error
Traceback (most recent call last):
File D:\users\ScriptTestCode\scriptsCompiledCode\ExecuteScripts.py,
line 32, in module
TestManager.execute_scripts(TEST_BUILD)
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 764, in execute_scripts
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 772, in _execute_all
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 924, in _testsuite_950_band
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 377, in exec_test_suite
File D:\users\ScriptTestCode\scripts\ResultReporter.py, line 321, in
save_test_results
_my_doc.save(StackTestData.TEST_REPORT_PATH)
File C:\Python27\lib\site-packages\pyExcelerator\Workbook.py, line
610, in save
doc.save(filename, self.get_biff_data())
File C:\Python27\lib\site-packages\pyExcelerator\CompoundDoc.py,
line 554, in save
f = file(filename, 'wb')
IOError: [Errno 22] invalid mode ('wb') or filename:
'.\\TestResults\\TestReport.xls'
Now my question is of there any issue with logging to excel it should
happen for the first test suite itself,but it occurs in either 2,3,4 or
5 test suite. Some it runs without any issues.
Well, the fact that it works/fails 50% of the time points to a race
condition. You don't say how the test suites / tests are running, but if
anything's running in parallel, one test's cleanup could be pulling the
file out from under another test's writing results. Without knowing more
about your test runner, this is really guess-work.
Logging to Excel isn't part of the builtin logging module so you've
presumably added that functionality yourself. But PyExcelerator is
ultimately just opening a file and writing to it so for this purpose it
appears to be equivalent to, say, logging a bunch of stuff into a list
and then writing that into a file.
TJG
--
https://mail.python.org/mailman/listinfo/python-list--
https://mail.python.org/mailman/listinfo/python-list
Re: Query on Python Compiled source--Urgent
Hi,
Yes ,its not actual logging module.Using pyexcelerator we are storing just
test results to excel file.Each test suite has some 25-100 test cases.We are
using unit test from python ,after completion of each test case the test result
will be stored in excel file.Below is the sample result that is stored in excel
file.
S.No TestCaseID TestDescription TestResult
1 Test_case_1 SetTransmitPower Pass
2 Test_case_2 Set Frequency Fail
Nothing is running parallel.
Best Regards,
Chandan
On Monday, 14 October 2013 1:10 PM, Tim
Golden m...@timgolden.me.uk wrote:
On 14/10/2013 06:41,
chandan kumar wrote:
I'm
working on a python project for protocol testing.I need to
provide
only python compiled source to
our customer.
Here are the steps followed to take python compiled from
actual source.
1.There are 5 different
test suites under the project
2..Run
all 5 test suite with python sources.
3.After completion of test suite ,just
take .pyc files and copied in to
seperate folder.
4.Re run test suite
for any issues with the .pyc code.I started seeing
one issue when it logs the test results in
to excel file.
This issue occurs sometimes.50% of
chances are there to see this issue
Below is the error
Traceback (most recent call last):
File
D:\users\ScriptTestCode\scriptsCompiledCode\ExecuteScripts.py,
line 32, in module
TestManager.execute_scripts(TEST_BUILD)
File
D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 764, in execute_scripts
File
D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 772, in _execute_all
File
D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 924, in _testsuite_950_band
File
D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py,
line 377, in exec_test_suite
File
D:\users\ScriptTestCode\scripts\ResultReporter.py,
line 321, in
save_test_results
_my_doc.save(StackTestData.TEST_REPORT_PATH)
File
C:\Python27\lib\site-packages\pyExcelerator\Workbook.py,
line
610, in save
doc.save(filename,
self.get_biff_data())
File
C:\Python27\lib\site-packages\pyExcelerator\CompoundDoc.py,
line 554, in save
f = file(filename,
'wb')
IOError: [Errno 22]
invalid mode ('wb') or filename:
'.\\TestResults\\TestReport.xls'
Now my question is
of there any issue with logging to excel it should
happen for the first test suite
itself,but it occurs in either 2,3,4 or
5 test suite. Some it runs without any
issues.
Well, the
fact that it works/fails 50% of the time points to a race
condition. You don't say how the test
suites / tests are running, but if
anything's running in parallel, one
test's cleanup could be pulling the
file
out from under another test's writing results. Without
knowing more
about your test runner, this is
really guess-work.
Logging
to Excel isn't part of the builtin logging module so
you've
presumably added that
functionality yourself. But PyExcelerator is
ultimately just opening a file and writing to
it so for this purpose it
appears to be
equivalent to, say, logging a bunch of stuff into a list
and then writing that into a file.
TJG
--
https://mail.python.org/mailman/listinfo/python-list
-Inline Attachment Follows-
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Query on Python Compiled source--Urgent
[Please post your answer below the previous reply, not above]
[... snip most of original traceback ...]
File C:\Python27\lib\site-packages\pyExcelerator\CompoundDoc.py,
line 554, in save
f = file(filename, 'wb')
IOError: [Errno 22] invalid mode ('wb') or filename:
'.\\TestResults\\TestReport.xls'
Now my question is of there any issue with logging to excel it should
happen for the first test suite itself,but it occurs in either 2,3,4 or
5 test suite. Some it runs without any issues.
On 14/10/2013 10:34, chandan kumar wrote:
Yes ,its not actual logging module.Using pyexcelerator we are storing just
test results to excel file.Each test suite has some 25-100 test cases.We are
using unit test from python ,after completion of each test case the test
result will be stored in excel file.Below is the sample result that is stored
in excel file.
S.NoTestCaseID TestDescription TestResult
1 Test_case_1 SetTransmitPower Pass
2 Test_case_2 Set Frequency Fail
Nothing is running parallel.
Sorry -- I didn't look closely enough at the error message. invalid
mode or filename wouldn't be the result of a file getting deleted out
from under a write.
Error 22 is returned from the MS runtime as EINVAL. It's not clear from
the traceback why it would consider that path invalid, but you're going
to have to do some legwork to narrow it down, I'm afraid.
The most likely prospects is that you're not running in the directory
you think you're in. Try putting a print os.getcwd() somewhere in the
mix to see where you actually are.
However, that still wouldn't quite explain why it occurs only sometimes
but, as I said, we'd have to know more about your test-runner to be able
to help.
TJG
--
https://mail.python.org/mailman/listinfo/python-list
Re: Query on Python Compiled source--Urgent
On Mon, 14 Oct 2013 13:41:35 +0800, chandan kumar wrote: Now my question is of there any issue with logging to excel it should happen for the first test suite itself,but it occurs in either 2,3,4 or 5 test suite. Some it runs without any issues. Logging to excel is probably a wrong thing to do (it is not a good idea to tie yourself into a 3rd party format that can be changed any time) you would be better to log to a csv file which can then be opened by excell OR ANY OTHER spreadsheet application. it is also far easier to use the CSV module than attempting to write a native XLS file -- Mal: I've seen you without your clothes on before. Never thought I'd see you naked. --Episode #11, Trash -- https://mail.python.org/mailman/listinfo/python-list
Query on Python Compiled source--Urgent
Hi,
I'm working on a python project for protocol testing.I need to provide only
python compiled source to our customer.
Here are the steps followed to take python compiled from actual source.
1.There are 5 different test suites under the project
2..Run all 5 test suite with python sources.
3.After completion of test suite ,just take .pyc files and copied in to
seperate folder.
4.Re run test suite for any issues with the .pyc code.I started seeing one
issue when it logs the test results in to excel file.
This issue occurs sometimes.50% of chances are there to see this issue
Below is the error
Traceback (most recent call last):
File D:\users\ScriptTestCode\scriptsCompiledCode\ExecuteScripts.py, line
32, in module
TestManager.execute_scripts(TEST_BUILD)
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py, line 764,
in execute_scripts
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py, line 772,
in _execute_all
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py, line 924,
in _testsuite_950_band
File D:\users\ScriptTestCode\scriptsCompiledCode\TestManager.py, line 377,
in exec_test_suite
File D:\users\ScriptTestCode\scripts\ResultReporter.py, line 321, in
save_test_results
_my_doc.save(StackTestData.TEST_REPORT_PATH)
File C:\Python27\lib\site-packages\pyExcelerator\Workbook.py, line 610, in
save
doc.save(filename, self.get_biff_data())
File C:\Python27\lib\site-packages\pyExcelerator\CompoundDoc.py, line 554,
in save
f = file(filename, 'wb')
IOError: [Errno 22] invalid mode ('wb') or filename:
'.\\TestResults\\TestReport.xls'
Now my question is of there any issue with logging to excel it should happen
for the first test suite itself,but it occurs in either 2,3,4 or 5 test suite.
Some it runs without any issues.
Please let me know do i need to follow any sequence when copying compiled
source code and whats exactly going wrong here.
Best Regards,
Chandan.--
https://mail.python.org/mailman/listinfo/python-list
[issue13061] Decimal module yields incorrect results when Python compiled with clang
Changes by Ned Deily n...@acm.org: -- assignee: ronaldoussoren - ned.deily stage: - committed/rejected status: pending - closed title: Decimal module yields incorrect results when Python compiled with llvm - Decimal module yields incorrect results when Python compiled with clang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
New submission from Joshua Bleecher Snyder joshar...@gmail.com: When Python is compiled on OS X with llvm, the decimal module behaves erratically (simple calculations are wrong, most doctests fail). This was originally reported here: http://stackoverflow.com/questions/7590137/dividing-decimals-yields-invalid-results-in-python-2-5-to-2-7 and the compiler dependency was tracked down here: https://trac.macports.org/ticket/31444 Although it looks like MacPorts is going to force use of gcc, it'd still be better for Python to behave correctly when compiled with llvm. Possibly related to http://bugs.python.org/issue11149? -- assignee: ronaldoussoren components: Build, Installation, Library (Lib), Macintosh messages: 144604 nosy: josharian, ronaldoussoren priority: normal severity: normal status: open title: Decimal module yields incorrect results when Python compiled with llvm type: behavior versions: 3rd party, Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
Stefan Krah stefan-use...@bytereef.org added the comment: Possibly related to http://bugs.python.org/issue11149? Maybe I missed it in the links you gave, but that is easily settled by compiling with and without -fwrapv. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
Joshua Bleecher Snyder joshar...@gmail.com added the comment: Possibly related to http://bugs.python.org/issue11149? Maybe I missed it in the links you gave, but that is easily settled by compiling with and without -fwrapv. Apologies -- I didn't do enough homework on this one. Yes, I can confirm that compiling with -fwrapv solves this issue. Not sure whether that makes this bug a straight duplicate of http://bugs.python.org/issue11149... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
Changes by Ned Deily n...@acm.org: -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
Stefan Krah stefan-use...@bytereef.org added the comment: It's more a straight duplicate of #12973, but the underlying cause (signed integer overflow) is the same. For people who are finding this via a search engine: A lot of bugs have been fixed in #12973, but even if the test suite passes without -fwrapv it is *still* recommended to use -fwrapv. Could anyone test if the attached patch works for llvm-gcc? -- keywords: +patch Added file: http://bugs.python.org/file23265/llvm-gcc-fwrapv.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13061] Decimal module yields incorrect results when Python compiled with llvm
Ned Deily n...@acm.org added the comment: There is some confusion here, I think. As best as I can tell, the original problem reported in the Stackoverflow question and to MacPorts involved using the clang compiler, not llvm-gcc and the Decimal problem reported here was only ever a problem when using clang. It's not an issue when using Apple's llvm-gcc compiler because the pre-#11149 configure test works properly with llvm-gcc. That test looks for -fwrapv in the compiler help string: $ llvm-gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ llvm-gcc -v --help 2/dev/null | grep -- -fwrapv -fwrapv Assume signed arithmetic overflow wraps around $ gcc-4.2 --version i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc-4.2 -v --help 2/dev/null | grep -- -fwrapv -fwrapv Assume signed arithmetic overflow wraps around $ clang --version Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.1.0 Thread model: posix $ clang -v --help 2/dev/null | grep -- -fwrapv The above was using the 3 Apple-supplied compilers with the OS X 10.7 (Lion) version of Xcode 4.1 (Build version 4B110). The 10.6 compiler versions should work the same way. So this issue should be closed as a duplicate of Issue11149. I'm setting it to pending and will close it if there are no objections. -- resolution: - duplicate status: open - pending superseder: - [PATCH] Configure should enable -fwrapv for clang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Python compiled modules are too big in size (even after strip)
Hi, I have just compiled python 2.6.5 from sources on ubuntu hardy 8.04. I have used a simple script to do everything in one go: ./configure --enable-shared make make install Python is compiled and installed successfully. However the modules(_socket.so, _random.so etc) are two big in terms of file size. They are around 4.5-5.0 mb each. I have used strip strip-all *.so, but still size is around 1.5 mb each. This is still too big compare to size of modules on ubuntu karmic's pre installed python 2.6.5. Am I missing something here? Do I have to re-configure or re-compile the python again from sources? Regards Prashant -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled modules are too big in size (even after strip)
On 27 Apr, 10:43, King animator...@gmail.com wrote: Hi, I have just compiled python 2.6.5 from sources on ubuntu hardy 8.04. I have used a simple script to do everything in one go: ./configure --enable-shared make make install Python is compiled and installed successfully. However the modules(_socket.so, _random.so etc) are two big in terms of file size. They are around 4.5-5.0 mb each. I have used strip strip-all *.so, but still size is around 1.5 mb each. This is still too big compare to size of modules on ubuntu karmic's pre installed python 2.6.5. Am I missing something here? Do I have to re-configure or re-compile the python again from sources? Regards Prashant Err, the common install on karmic is 2.6.4... IIRC (and probably not) the default was 2.6.2 on hardy Obviously doesn't help where you're finding large sized shared libs, but anyway... Jon. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled modules are too big in size (even after strip)
Hi Jon, I do have a limited skill sets in c/c++ and also new on linux. I think I am missing some flags or anything when I am compiling python from sources. Still hoping that some one point me out the missing link. Cheers Prashant -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled modules are too big in size (even after strip)
Le Tue, 27 Apr 2010 02:43:19 -0700, King a écrit : Python is compiled and installed successfully. However the modules(_socket.so, _random.so etc) are two big in terms of file size. They are around 4.5-5.0 mb each. I have used strip strip-all *.so, but still size is around 1.5 mb each. This is way more than it should be. Even if debug mode, most extension modules should be around 100kB or smaller. Am I missing something here? Do I have to re-configure or re-compile the python again from sources? I would suggest to check the compile options gcc gets (look at make output), and try changing them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Serializing Python compiled code.
[EMAIL PROTECTED] wrote: In a C++ application having a Python interpreter embedded, is it possible to compile a small Python snippet into object code and serialize the compiled object code to, for example, a database? I am exploring the possibility of writing a data driven application, where small-sized object code can be read from a database and executed. Keeping aside all other considerations such as security, etc for a moment, is this feasible? The biggest problem, in my view, is that the compiled object code won't work with any other version of Python, or with versions where the compiler was built with other options, or possibly even on other processors with the same version. The nice thing about a database server is that you can use it from different computers without worrying about versions or processors. Compilation is not that expensive. Why not just store the raw code snippets? -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Serializing Python compiled code.
Hi everyone, In a C++ application having a Python interpreter embedded, is it possible to compile a small Python snippet into object code and serialize the compiled object code to, for example, a database? I am exploring the possibility of writing a data driven application, where small-sized object code can be read from a database and executed. Keeping aside all other considerations such as security, etc for a moment, is this feasible? Please do reply. Thanks, -/renji -- http://mail.python.org/mailman/listinfo/python-list
Re: Serializing Python compiled code.
--- [EMAIL PROTECTED] wrote: In a C++ application having a Python interpreter embedded, is it possible to compile a small Python snippet into object code and serialize the compiled object code to, for example, a database? I am exploring the possibility of writing a data driven application, where small-sized object code can be read from a database and executed. Keeping aside all other considerations such as security, etc for a moment, is this feasible? This might be too coarse for you, but you could serialize the .pyc files that get created from your modules. If you drop a .pyc file into a directory, and you make sure that you don't have a corresponding .py file of the same basename, and new date, in the directory, then Python will still execute it. This is a bit of a gotcha of Python for naive users, but this feature helps in use cases like yours, where you don't want to pay the lexing step, and for whatever reason, you don't want to simply use the file system as your store for code. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
Franz Steinhaeusler [EMAIL PROTECTED] wrote: Yes, people have compiled Python with gcc on windows. I believe it is slightly slower than the standard release, but I would guess that may depend on the exact versions of gcc/msc you choose to compare, and the exact compiler options you choose (or I may even be imagining it entirely). I cannot imagine, that there is a decisive difference, especially as in gcc, you have also a couple of options. I did a quick comparison running pystone and taking the best of several runs: On one system which had the Windows Python 2.4 distribution and also Python 2.4 installed under cygwin: Windows Python 2.4: 46k Cygwin Python 2.4: 41k On another system which has a dual boot setup: Windows Python 2.5: 43.7k Ubuntu Python 2.5: 42.0k So in the first case there was about a 12% improvement and in the second case about 5% improvement using the Windows distribution. I don't know whether the gap is closing from improvements in gcc or whether there is an OS related difference as well. Unfortunately cygwin doesn't appear to offer Python 2.5 yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
On 7 Feb 2007 09:44:32 GMT, Duncan Booth [EMAIL PROTECTED] wrote: Franz Steinhaeusler [EMAIL PROTECTED] wrote: Yes, people have compiled Python with gcc on windows. I believe it is slightly slower than the standard release, but I would guess that may depend on the exact versions of gcc/msc you choose to compare, and the exact compiler options you choose (or I may even be imagining it entirely). I cannot imagine, that there is a decisive difference, especially as in gcc, you have also a couple of options. I did a quick comparison running pystone and taking the best of several runs: On one system which had the Windows Python 2.4 distribution and also Python 2.4 installed under cygwin: Windows Python 2.4: 46k Cygwin Python 2.4: 41k On another system which has a dual boot setup: Windows Python 2.5: 43.7k Ubuntu Python 2.5: 42.0k So in the first case there was about a 12% improvement and in the second case about 5% improvement using the Windows distribution. I don't know whether the gap is closing from improvements in gcc or whether there is an OS related difference as well. Unfortunately cygwin doesn't appear to offer Python 2.5 yet. Hello Duncan, interesting test, so this little gap don't care at all (for me). If the difference would be say 30% or more, than that would make a perceptible difference, I think. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
On Mon, 05 Feb 2007 12:17:48 +0100, hg [EMAIL PROTECTED] wrote: Duncan Booth wrote: Franz Steinhaeusler [EMAIL PROTECTED] wrote: Hello, I'm only curious. Why is Python and most extension (also wxPython) not built using an open source compiler like gcc or g++ on Windows? I'm always wondering, why Microsoft is still supported in that way, using VC++ 7.1, if I'm not wrong. Ok, maybe the compiled assembler code could be better, but this cannot be the reason, or? It would be wonderful (from the principle) if this could be possible. From the standpoint of open source. What are your opinions? Practicality beats purity. To maximise the interoperability of Python with other software on the platform it makes sense to use the best supported compiler environment for the platform. @Duncan: Yes, you are not wrong! :) But this is not really open source in my opinion. Ok there is the VC++ toolkit for download. I'm just curious, if there ever had compiled on windows using that toolkit or even with gcc, and with gcc, whether there are problems or/and differences in speed and run time behaviour. Still, if one considers the many threads of people trying to get it to work with the free version + other people that had to invest in VS mostly for that (I did) / it might eventually be fair to reconsider. + a dll is a dll hg @hg: that would be cool. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
Franz Steinhaeusler [EMAIL PROTECTED] wrote: @Duncan: Yes, you are not wrong! :) But this is not really open source in my opinion. Ok there is the VC++ toolkit for download. Which I agree totally is a real pain finding the right versions to download. I'm just curious, if there ever had compiled on windows using that toolkit or even with gcc, and with gcc, whether there are problems or/and differences in speed and run time behaviour. Yes, people have compiled Python with gcc on windows. I believe it is slightly slower than the standard release, but I would guess that may depend on the exact versions of gcc/msc you choose to compare, and the exact compiler options you choose (or I may even be imagining it entirely). As I understand it, you can use Mingw to compile extension modules which are compatible with the standard release of Python, and of course there is always cygwin. But I still don't understand what difference it makes to anyone between: an application (could be open or closed source) running on an open source language (Python) compiled with a closed source compiler on a closed source OS. versus an application (could be open or closed source) running on an open source language (Python) compiled with an open source compiler on a closed source OS. at the end of the day you still have a mix of open and closed source components. If it makes you feel better to be using an open source compiler that's fine, but it doesn't really do anything for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
On 6 Feb 2007 08:35:08 GMT, Duncan Booth [EMAIL PROTECTED] wrote: Franz Steinhaeusler [EMAIL PROTECTED] wrote: @Duncan: Yes, you are not wrong! :) But this is not really open source in my opinion. Ok there is the VC++ toolkit for download. Which I agree totally is a real pain finding the right versions to download. I'm just curious, if there ever had compiled on windows using that toolkit or even with gcc, and with gcc, whether there are problems or/and differences in speed and run time behaviour. Yes, people have compiled Python with gcc on windows. I believe it is slightly slower than the standard release, but I would guess that may depend on the exact versions of gcc/msc you choose to compare, and the exact compiler options you choose (or I may even be imagining it entirely). I cannot imagine, that there is a decisive difference, especially as in gcc, you have also a couple of options. As I understand it, you can use Mingw to compile extension modules which are compatible with the standard release of Python, and of course there is always cygwin. But I still don't understand what difference it makes to anyone between: an application (could be open or closed source) running on an open source language (Python) compiled with a closed source compiler on a closed source OS. versus an application (could be open or closed source) running on an open source language (Python) compiled with an open source compiler on a closed source OS. For me it's more a issue of principle. :) Ok, the OS is as it is, but the layer is more open. If there would be no toolkit, you have to buy (and many have bought Visual Studio) for open source projects, and that is the point, where I cannot make friend with me. at the end of the day you still have a mix of open and closed source components. If it makes you feel better to be using an open source compiler that's fine, but it doesn't really do anything for me. Ok, I let your opinion, it is also fine with me! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
Franz Steinhaeusler [EMAIL PROTECTED] wrote: Hello, I'm only curious. Why is Python and most extension (also wxPython) not built using an open source compiler like gcc or g++ on Windows? I'm always wondering, why Microsoft is still supported in that way, using VC++ 7.1, if I'm not wrong. Ok, maybe the compiled assembler code could be better, but this cannot be the reason, or? It would be wonderful (from the principle) if this could be possible. From the standpoint of open source. What are your opinions? Practicality beats purity. To maximise the interoperability of Python with other software on the platform it makes sense to use the best supported compiler environment for the platform. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled on Windows
Duncan Booth wrote: Franz Steinhaeusler [EMAIL PROTECTED] wrote: Hello, I'm only curious. Why is Python and most extension (also wxPython) not built using an open source compiler like gcc or g++ on Windows? I'm always wondering, why Microsoft is still supported in that way, using VC++ 7.1, if I'm not wrong. Ok, maybe the compiled assembler code could be better, but this cannot be the reason, or? It would be wonderful (from the principle) if this could be possible. From the standpoint of open source. What are your opinions? Practicality beats purity. To maximise the interoperability of Python with other software on the platform it makes sense to use the best supported compiler environment for the platform. Still, if one considers the many threads of people trying to get it to work with the free version + other people that had to invest in VS mostly for that (I did) / it might eventually be fair to reconsider. + a dll is a dll hg -- http://mail.python.org/mailman/listinfo/python-list
Python compiled on Windows
Hello, I'm only curious. Why is Python and most extension (also wxPython) not built using an open source compiler like gcc or g++ on Windows? I'm always wondering, why Microsoft is still supported in that way, using VC++ 7.1, if I'm not wrong. Ok, maybe the compiled assembler code could be better, but this cannot be the reason, or? It would be wonderful (from the principle) if this could be possible. From the standpoint of open source. What are your opinions? -- http://mail.python.org/mailman/listinfo/python-list
relocate python compiled file
Hi, When i run the python file, the python compiled file is created. Is it possible to relocate the python compiled file to some other directory?. Is it possible to frequent update the relocated pyc file while running the py file?thanks and regards, abbi Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
billiejoex [EMAIL PROTECTED] wrote: Hi all. I'm sorry for a noob question like this but I'll try to ask it anyway. One of the greatest problem that may discourage a new user to choose Python language is it's interpreted nature. I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered from being interpreted. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Tim Roberts [EMAIL PROTECTED] writes: I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered from being interpreted. Are you kidding? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Tim Roberts [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] billiejoex [EMAIL PROTECTED] wrote: Hi all. I'm sorry for a noob question like this but I'll try to ask it anyway. One of the greatest problem that may discourage a new user to choose Python language is it's interpreted nature. I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered from being interpreted. Nor has 386 'machine language' suffered from being interpreted, at a deeper level, by microcode. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Terry Reedy wrote: Tim Roberts [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] billiejoex [EMAIL PROTECTED] wrote: Hi all. I'm sorry for a noob question like this but I'll try to ask it anyway. One of the greatest problem that may discourage a new user to choose Python language is it's interpreted nature. I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered from being interpreted. Nor has 386 'machine language' suffered from being interpreted, at a deeper level, by microcode. I think both you and Paul may be missing Tim's point. I don't think he's talking about suffering in technical respects, like speed. He's talking about popularity. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Robert Kern [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Terry Reedy wrote: Nor has 386 'machine language' suffered from being interpreted, at a deeper level, by microcode. I think both you and Paul may be missing Tim's point. I don't think he's talking about suffering in technical respects, like speed. He's talking about popularity. I knew that ;-) and meant that ;;--)). Of course, many people don't know that 'machine code' is often now interpreted -- nor that Python code is compiled to something by all current implementations. Perhaps we should call the CPython 'interpreter' the CPython interpreter-compiler that it is. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On Tue, 06 Sep 2005 17:29:46 -, Grant Edwards [EMAIL PROTECTED] wrote: On 2005-09-06, Jorgen Grahn [EMAIL PROTECTED] wrote: I also believe it's better to convince the end user to install Python before installing the application[1], rather than to try to sneak in an interpreter with py2exe or something -- an interpreter which the end user cannot update, manage or use for other things. There's a typo in that last phrase. It should read [...] -- an interpreter the user isn't going to uninstall or break because he doesn't know what it is or why it's there. I meant what I wrote, of course (and you should really have added a smiley.) Might be because I'm more at home in Linux (Debian). The bundling-an-interpreter approach to distribution software is simply not applicable on those platforms, for many different reasons. Maybe that's why I have a hard time even understanding the idea. I see lots of problems and few benefits. For example, the issue of security fixes. If there's a bug in Python which makes anyone running an interpreter vulnerable, how are those users even going to /find out/ about it? /Jorgen -- // Jorgen Grahn jgrahn@ Ph'nglui mglw'nafh Cthulhu \X/algonet.se R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On Wed, 7 Sep 2005 08:40:28 -0500, Terry Hancock [EMAIL PROTECTED] wrote: On Tuesday 06 September 2005 11:32 am, Jorgen Grahn wrote: I hope people are less hesitant to install interpreted applications today than they were ten years ago. I also believe it's better to convince the end user to install Python before installing the application[1], rather than to try to sneak in an interpreter with py2exe or something -- an interpreter which the end user cannot update, manage or use for other things. I have to confess to be very ignorant about the Windows installation options for Python packages, but surely in principle at least, it should be possible to make self-installing .EXE files that do what I get from apt-get install python-mypackage or at least dpkg --install mypackage That is to say, which install an interpreter if one isn't already there, and then install the package. Or, upon finding an interpreter install into it along the lines of distutils. It has been a while since I used bdist_wininst, but I hope it at least a) detects if there is a suitable Python installed b) otherwise, suggests that the user should install one, explains why, gives the URL of a suitable package, and the size of the download Things get trickier, of course, if the software depends on external packages and modules. /Jorgen -- // Jorgen Grahn jgrahn@ Ph'nglui mglw'nafh Cthulhu \X/algonet.se R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On 2005-09-08, Jorgen Grahn [EMAIL PROTECTED] wrote: On Tue, 06 Sep 2005 17:29:46 -, Grant Edwards [EMAIL PROTECTED] wrote: On 2005-09-06, Jorgen Grahn [EMAIL PROTECTED] wrote: I also believe it's better to convince the end user to install Python before installing the application[1], rather than to try to sneak in an interpreter with py2exe or something -- an interpreter which the end user cannot update, manage or use for other things. There's a typo in that last phrase. It should read [...] -- an interpreter the user isn't going to uninstall or break because he doesn't know what it is or why it's there. I meant what I wrote, of course (and you should really have added a smiley.) Nah, I knew everybody would get it without one. c.l.p readers are smarter than the average bear. Might be because I'm more at home in Linux (Debian). The bundling-an-interpreter approach to distribution software is simply not applicable on those platforms, for many different reasons. Of course. I never ship an interpreter for Linux apps. Just the python source. I thought we were talking about Windows apps what with the reference to py2exe and Inno Setup and whatnot. Linux comes with Python already installed, though sometimes wxPyton and friends aren't installed by default. Mostly my Linux Python apps are strictly command-line anyway. Maybe that's why I have a hard time even understanding the idea. I see lots of problems and few benefits. I've had limited success telling Windows users to install Python. Even if you point them to the ActiveState MSI file with all the Win32 stuff already bundled, they seem to muck it up most of the time. I can't imagine how -- it's dead simple to install, but they manage to screw it up. For example, the issue of security fixes. If there's a bug in Python which makes anyone running an interpreter vulnerable, how are those users even going to /find out/ about it? I guess you ship them an update -- same as you would for a security fix for the other parts of the application. -- Grant Edwards grante Yow! My TOYOTA is built at like a... BAGEL with CREAM visi.comCHEESE!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On Tuesday 06 September 2005 11:32 am, Jorgen Grahn wrote: I hope people are less hesitant to install interpreted applications today than they were ten years ago. I also believe it's better to convince the end user to install Python before installing the application[1], rather than to try to sneak in an interpreter with py2exe or something -- an interpreter which the end user cannot update, manage or use for other things. I have to confess to be very ignorant about the Windows installation options for Python packages, but surely in principle at least, it should be possible to make self-installing .EXE files that do what I get from apt-get install python-mypackage or at least dpkg --install mypackage That is to say, which install an interpreter if one isn't already there, and then install the package. Or, upon finding an interpreter install into it along the lines of distutils. I mean, with the whole AUTOEXEC.BAT start up a CD and run whatever evil code we find there as soon as we stick it into our unwisely promiscuous machine, it ought to make it possible for the installation to be completely transparent to the user. You know, after writing that, I'm starting to rethink what people mean when they say Windows is easy. ;-) Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Grant Edwards wrote: distributing DLLs have been a solved problem for at least 15-20 years... There are days when some poeple might disagree with that. ;) distributing them has never been a problem. installing them in a shared location has always been a problem. (the solution to the latter is simple, of course: don't do that) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Clear. Thank you all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On 2005-09-06, Fredrik Lundh [EMAIL PROTECTED] wrote: Grant Edwards wrote: distributing DLLs have been a solved problem for at least 15-20 years... There are days when some poeple might disagree with that. ;) distributing them has never been a problem. installing them in a shared location has always been a problem. (the solution to the latter is simple, of course: don't do that) /F I should add that py2exe doesn't do that, so py2exe'd apps tend to be better behaved than many other sorts of Window's apps. -- Grant Edwards grante Yow! ALFRED JARRY! Say at something about th' DEATH visi.comof DISCO!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On Mon, 5 Sep 2005 22:48:19 +0200, billiejoex [EMAIL PROTECTED] wrote: there are noob questions and there are uneducated questions, yours are of the latter ( actually yours are STATEMENTS not questions ), and just trolling for what it is worth, if you would take the time to read what Python is and why it is you would not be asking these questions. I'm really sorry man. I didn't wanted to be uneducated, believe me. I wrote fastly, I'm new in Python and probably for my language problems I didn't expressed concepts properly. I didn't think they were uneducated, they were good questions. At least if one understands that the problem is that the /end user/ percieves a problem. I hope people are less hesitant to install interpreted applications today than they were ten years ago. I also believe it's better to convince the end user to install Python before installing the application[1], rather than to try to sneak in an interpreter with py2exe or something -- an interpreter which the end user cannot update, manage or use for other things. /Jorgen [1] Might be hard to convince people who have ever installed a Java interpreter -- when I do that on Windows, I usually break at least one existing Java application, and I usually get a whole lot of useless desktop icons, a funny thing in the system tray, etc. -- // Jorgen Grahn jgrahn@ Ph'nglui mglw'nafh Cthulhu \X/algonet.se R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On 2005-09-06, Jorgen Grahn [EMAIL PROTECTED] wrote: I also believe it's better to convince the end user to install Python before installing the application[1], rather than to try to sneak in an interpreter with py2exe or something -- an interpreter which the end user cannot update, manage or use for other things. There's a typo in that last phrase. It should read [...] -- an interpreter the user isn't going to uninstall or break because he doesn't know what it is or why it's there. -- Grant Edwards grante Yow! ... I don't like at FRANK SINATRA or his visi.comCHILDREN. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On Tue, 06 Sep 2005 03:06:52 -, rumours say that Grant Edwards [EMAIL PROTECTED] might have written: There are very, very few pure exe single-file executable windows apps. Putty is the only one I've run across in a _long_ while. Then you should also run across Media Player Classic (download it from http://sourceforge.net/projects/guliverkli ). Just a plain exe, no installation needed, and is an excellent media player. For a funny side, check the program's version history. -- TZOTZIOY, I speak England very best. Dear Paul, please stop spamming us. The Corinthians -- http://mail.python.org/mailman/listinfo/python-list
Python compiled?
Hi all. I'm sorry for a noob question like this but I'll try to ask it anyway. One of the greatest problem that may discourage a new user to choose Python language is it's interpreted nature. Another important problem is that no interpreter is installed on Windows machine by default and this makes harder to distribute the software. Does it is planned that, in a far future, Python will implement a form of compilation? This would be awesome. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
billiejoex wrote: Hi all. I'm sorry for a noob question like this but I'll try to ask it anyway. One of the greatest problem that may discourage a new user to choose Python language is it's interpreted nature. What? The instant gratification of immediate results is not discouraging. Another important problem is that no interpreter is installed on Windows machine by default and this makes harder to distribute the software. Python isn't that big to install, and people don't have problems with small downloads Does it is planned that, in a far future, Python will implement a form of compilation? This would be awesome. Again, I don't see how compiling would make Python better. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
One of the greatest problem that may discourage a new user to choose Python language is it's interpreted nature. Strange.. this is one reason I love Python :-) Another important problem is that no interpreter is installed on Windows machine by default and this makes harder to distribute the software. Does it is planned that, in a far future, Python will implement a form of compilation? This would be awesome. py2exe (http://starship.python.net/crew/theller/py2exe/) and pyinstaller (http://pyinstaller.hpcf.upr.edu/pyinstaller/) compile python programs into .exe files that can be executed on any Win32 machine. So you can develop the code using the python interpreter and deploy it using either of these. I have used py2exe and nsis installer to create setup versions of my applications and it deployment is really smooth, just like any compiled software. -Kartic -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Hi ! One of the greatest reason which encouraged me to choose Python is its interpreted nature (more exactly its nature of dynamic language). The utilities of distribution, or packaging, are enough numerous to solve this kind of problem. The existence of Py2exe (inter alia), could concillier the needs... @-salutations Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
there are noob questions and there are uneducated questions, yours are of the latter ( actually yours are STATEMENTS not questions ), and just trolling for what it is worth, if you would take the time to read what Python is and why it is you would not be asking these questions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
I'm sorry. Maybe you misunderstanded. I know the great advanteges deriving by using interpretation too, I appreciate it very much (I'm newbie in Python and the interpeter really helps me out in many situations), but a 'pure' interpretated language needs obligatorily an interpreter and (sorry for repeating) this could be a problem for distribution (imho). Py2exe is surely a good compromise but it is not comparable to an executable file compiled, for example, in C for obvious sizing reasons (I never used PyInstaller. I surely try it out as soon as possible, but I didn't think that the output package size is too much different than py2exe one). For these reasons I think that an hibrid language that permits interpretation and compilation at the same time, should be a great advantage. best regards -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
there are noob questions and there are uneducated questions, yours are of the latter ( actually yours are STATEMENTS not questions ), and just trolling for what it is worth, if you would take the time to read what Python is and why it is you would not be asking these questions. I'm really sorry man. I didn't wanted to be uneducated, believe me. I wrote fastly, I'm new in Python and probably for my language problems I didn't expressed concepts properly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
billiejoex wrote: I'm sorry. Maybe you misunderstanded. I know the great advanteges deriving by using interpretation too, I appreciate it very much (I'm newbie in Python and the interpeter really helps me out in many situations), but a 'pure' interpretated language needs obligatorily an interpreter and (sorry for repeating) this could be a problem for distribution (imho). Do youself a favour - google this group for that question. You'll get plenty of answers to your questions and allegations. This dead Horse has been beaten to hell and back. Really. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
billiejoex wrote: I know the great advanteges deriving by using interpretation too, I appreciate it very much (I'm newbie in Python and the interpeter really helps me out in many situations), but a 'pure' interpretated language needs obligatorily an interpreter and (sorry for repeating) this could be a problem for distribution (imho). Python is a compiled language; the Python source code you write is compiled to byte codes, which are executed by a virtual machine. on windows, that virtual machine consists of a DLL. distributing DLLs have been a solved problem for at least 15-20 years... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
billiejoex [EMAIL PROTECTED] wrote: interpretation and compilation at the same time, should be a great advantage. Python is compiled and needs a runtime environment. just like java does and like C needs the C standard library installed. I can see no differences except one is compiled to native code, the other is compiled to bytecode and JITted or interpreted and python is compiled to bytecode and interpreted or (with psyco) JITted. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
Hmm, this may be offtopic, but does anyone know how pyinstaller actually works? Does it just unpack everything into a temporary directory at runtime? How can it work in Windows and Linux? Their website was sparse... Well I'm trying it now. Let me know if anyone has these answers in the meantime. Thanks, Greg On 9/5/05, Valentino Volonghi aka Dialtone [EMAIL PROTECTED] wrote: billiejoex [EMAIL PROTECTED] wrote: interpretation and compilation at the same time, should be a great advantage.Python is compiled and needs a runtime environment.just like java does and like C needs the C standard library installed. I can see no differences except one is compiled to native code, theother is compiled to bytecode and JITted or interpreted and python iscompiled to bytecode and interpreted or (with psyco) JITted.-- Valentino Volonghi aka DialtoneNow Running MacOSX 10.4Blog: http://vvolonghi.blogspot.comhttp://weever.berlios.de-- http://mail.python.org/mailman/listinfo/python-list-- Gregory PiñeroChief Innovation OfficerBlended Technologies (www.blendedtechnologies.com) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiled?
On 2005-09-05, Fredrik Lundh [EMAIL PROTECTED] wrote: distributing DLLs have been a solved problem for at least 15-20 years... There are days when some poeple might disagree with that. ;) -- Grant Edwards grante Yow! LOOK!!! I'm WALKING at in my SLEEP again!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
