Re: [Python-Dev] PEP 3147: PYC Repository Directories
Hanno Schlichting wrote: >+1 for a single strategy that is used in all cases. The current >solution could be phased out across multiple releases, but in the end >there should be a single approach and no flag. Otherwise some code and >tools will only support one of the approaches, especially if this is >seen as something "only a minority of Linux distributions uses". -1. As far as I can tell, this PEP proposes to solve a specific problem that Linux distributions have. As they have decent package managers, this PEP makes their maintainers' lives a lot easier. If implemented, I believe it would eventually be used by all of them, not just "a minority". For just about anyone else, I believe the current situation works perfectly fine, and should not be changed. Personally, I work mainly on Windows, and things I install are placed in the site-packages directory of the Python version I use. There is no need to place .pyc files in subdirectories there, as there will only ever be one. Programs I write myself are also rarely, if ever, run by multiple Python versions. They get run by the default Python on my system; if I change the default, the .pyc files get overwritten, which is exactly what I want, I no longer need the old ones. As to the single cache directory per directory versus per .py file issue: a subdirectory per .py file is easier to manipulate manually; listing the .py file and the subdirectory containing the compiled versions belonging to it makes it somewhat easier to prevent errors due to deleting the source but not the compiled version. However, as the use-case for this PEP seems to be to make life easier for Linux packagers, it seems that a single __pycache__ subdirectory (or whatever the name would be) is preferable: less filesystem clutter, and no risks of forgetting to delete .pyc files, as this is about system-managed Python source. Gertjan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
Michael Foord wrote: >The launcher program could thrive without *having* to be part of a >standard Python install. Offering it separately makes sense even if it >*is* included. If we do both then users can vote with their feet. A launcher might be difficult to integrate into the Python installer, as there can, by definition, only be one. What if I install a new version of Python and then uninstall it? Will the launcher be uninstalled as well? Will it be reverted to a previous version, and if so, which? I am actually working on such a launcher for myself right now. The main problem I am trying to solve is doubleclicking a .py or .pyw file and having it run in the Python version it is intended for. From the command line, I want "something.py arg1 ... argn" to do the right thing as well. I don't care much for fixing "python something.py arg1 ... argn", as I personally rarely need to pass options to Python. I may look into that later, though. My launcher parses the first line of the script for something that starts with "#!" and contains "python". It tries to match that with a list of installed Python versions obtained from the registry, falling back to a configurable default if no such line is found. As to performance of such a solution: I'm writing this in Python (2.5, as its MSVCRT is easier to include in an exe) and converting it to an executable with py2exe. The extra startup time is manageble on my system. Using Python to write this in makes it much easier to experiment with adding features. Once the dust has settled I may attempt to rewrite it in C. Anyway, I believe that such a launcher should not be part of Python itself at first; an external program makes it easier to figure out what works well. As to adding Python to the Windows path: I'd be mildly annoyed if the installer offered that option, and seriously annoyed if it defaulted that option to "yes". Gertjan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Launcher for Windows (PEP 397) needs testing!
Vinay Sajip wrote: >The C implementation of the PEP 397-compatible Python Launcher for Windows has >come along nicely in the last few days, and now reached a point where it would >benefit from some testing by interested python-dev members. I've gotten the sources from: >https://bitbucket.org/vinay.sajip/pylauncher GUILauncher and CLILauncher refuse to build with Visual C++ 2008 Express Edition (using Launchers.sln): .\CLILauncher.rc(97) : error RC2135 : file not found: C:\Users\Vinay\Projects\Launchers\launcher.ico This is on Windows XP Pro, 32 bit. There are a few compilation warnings as well: .\launcher.c(59) : warning C4996: '_wgetenv': This function or variable may be unsafe. Consider using _wdupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. Associator builds (with the same warning displayed above). When checking it's dependencies, I see it depends on MSVCR90.DLL. You've mentioned that you use only "plain C and Win32 APIs"; would it be possible to remove this dependency? That would make it possible to copy the executable to a directory on the PATH, without having to worry about installing the C(++) runtime. Regards, Gertjan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
