Yes the pollution is really a problem.
You see in CPython the .pyc files are at least contained to the package directory where the modules live, thus they follow the pigeon-hole principle (one-to-one).
The current release puts at the very least 6 files ( site.{exe, pdb}, snippets.{exe,pdb}, <modulefile.py>.{exe,pdb}) upon a command like "IronPythonConsole.exe modulefile.py" in every directory that you use it... And if you are like me and are using the Lib directory of stdlibs from Python-2.3.5 you get types.{exe, pdb}, os.{exe, pdb}, etc.. Stop the madness!!
Anthony
On 5/4/05, Timothy Fitz <[EMAIL PROTECTED]> wrote:
On 5/4/05, Anthony Tarlano <[EMAIL PROTECTED]> wrote:
> I filed a bug as usual, but maybe you should consider a 0.7.4.1 release
> fixing this and the *[exe,pdb] file pollution problem asap
Is the exe "file pollution problem" really a problem? Conceptually,
CPython and IronPython are doing the same thing here. Step 1 is
compile to bytecode, CPython generates .pyc files, IronPython
generates exe files (that are CLR code). Step 2 is run with a virtual
machine. On a windows machine, python associates with .pyc and .py
files, so both the pyc and exe files are "runnable", they both have
the problem that an unsuspecting person might unintentionally run
them, however exe files are more tempting to the average user. I think
functionally that narrows the difference between CPython and
Ironpython down to file extension names and their associated icons,
no?
Are there any plans to change this? If so to what? My initial thought
was generate dlls, but that loses the double-click to run
functionality.
_______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
