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
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
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
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 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
>
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
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 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
> 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
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
> 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
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
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
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: 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)
On 27 Apr, 10:43, King 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
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: 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
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
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: 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
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 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: > @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 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
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
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
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?
"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?
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?
"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?
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?
"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?
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 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 GrahnR'lyeh wgah'nagl fhtagn! -- 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 GrahnR'lyeh wgah'nagl fhtagn! -- 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?
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
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 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 GrahnR'lyeh wgah'nagl fhtagn! -- 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) > > 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?
Clear. Thank you all. -- 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) -- 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
Re: Python compiled?
On 2005-09-05, billiejoex <[EMAIL PROTECTED]> wrote: > Py2exe is surely a good compromise but it is not comparable to > an executable file compiled, for example, in C for obvious > sizing reasons In theory something written in C could be smaller. In practice, it isn't. Most "real" apps end up shipping with a directory full of .dlls, help-files, uninstall scripts and miscellaneous other stuff. 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. Everything else ends up installing a directory full of libraries and help files and whatnot. In practice, a Python app packages with py2exe and Inno Setup behaves exactly the same as anything other recent Windows app. > (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. You're wrong. The size of a packaged Python app is simply not a concern. I've distributed several Python wxWidgets apps after packaging them with py2exe and Inno setup. I never got a single comment about the size of the packaged app -- all I got were surprised remarks about how they thought I was a Unix guy who didn't know anything about Windows. I reply that I am, and I don't. -- Grant Edwards grante Yow! Put FIVE DOZEN red at GIRDLES in each CIRCULAR visi.comOPENING!! -- 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?
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?
"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... -- 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?
> 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?
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". -- 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?
> 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?
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
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
