Re: [Python-Dev] Registry keys written by x64 installer
As you mention, 64 and 32bit programs use different instruction sets. Therefore, trying to use a 64bit install of Python with IIS configured to work with 32bits is not going to work. In this case, switching the configuration of IIS will require the Python user to uninstall the previous version and install a different version - but some sites may end up in a dilemma here - they may be *forced* to use IIS in 32bit mode due to no 64bit port for a tool they need, but simultaneously desire a 64bit build of Python for other tasks on that same box. IIUC, you want the AMD64 installer also deploy 32-bit pythonxy.dll etc. That's a challenge, of course: how would you install the 32-bit extension modules so that they don't interfere with the 64-bit ones? Right - I got the impression from Micheal that it was possible for 32bit components to be installed in a 64bit install, but I don't profess to know anything about this. That is true. However, there really isn't anything special about a 32bit component: the only difference is that Installer turns on file and registry redirection when installing that component. You are free to put 32-bit executables into 64-bit components just fine. (A component in MSI is a group of files and registry keys that is installed together). Regards, Martin ___ 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] Add a -z interpreter flag to execute a zip file
At 02:58 PM 7/14/2007 +1200, Greg Ewing wrote: Andy C wrote: What does if __name__ == '__main__ mean in __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? Is there a reason not to use __init__.py for this? Even some moderately-experienced Python developers confuse the concepts of package and directory containing Python code -- let's not make it worse by encouraging the inclusion of an __init__ module in the top-level package namespace! ___ 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] Add a -z interpreter flag to execute a zip file
Jim Jewett wrote: If anything, I would like to see the -m option enhanced so that if it gets a recognized collection file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. -m deals with the package namespace as it already stands - it knows nothing whatsoever about the underlying filesystem (and that's deliberate - the runpy module relies on PEP 302 to abstract away all those details). On Phillip's idea regarding being able to execute directories and zip files, I think the semantics would actually be manageable (as directories and zip files can be definitely identified), but I'd be concerned as to the startup cost for checking what is being executed. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Add a -z interpreter flag to execute a zip file
On 7/13/07, Jim Jewett [EMAIL PROTECTED] wrote: Andy C wrote: ... a .zip file with a __zipmain__.py module at its root? Why not just an __init__.py, which you would normally execute if you tried to import/run a directory? * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. Treating zip files (and only zip files) as a special case equivalent to uncompressed files seems like a wart; I would prefer not to special-case zips any more than they already are. Just to clarify, my patch already works with uncompressed directory trees just fine. It's just a matter of naming, I suppose. I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think. Andy ___ 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] Add a -z interpreter flag to execute a zip file
On Saturday 14 July 2007, Andy C wrote: I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different. We could use -r (run), or -X (execute); not sure those are really right either. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think. I've seen __main__ suggested as a place to store application-specific global settings, but not for a long time. I don't think it was ever mapped directly to a file on disk though. I find the idea really hackish. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Add a -z interpreter flag to execute a zip file
At 03:28 AM 7/15/2007 +1000, Nick Coghlan wrote: Jim Jewett wrote: If anything, I would like to see the -m option enhanced so that if it gets a recognized collection file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. -m deals with the package namespace as it already stands - it knows nothing whatsoever about the underlying filesystem (and that's deliberate - the runpy module relies on PEP 302 to abstract away all those details). On Phillip's idea regarding being able to execute directories and zip files, I think the semantics would actually be manageable (as directories and zip files can be definitely identified), but I'd be concerned as to the startup cost for checking what is being executed. Well, the start file is being opened and checked for directory-ness already, and it has to be read to be executed. The extra reading to see if it's a zipfile isn't likely to be much additional overhead. At this point I've got a partial patch. It figures out when it should import __main__, but it's not successful at actually doing so. It seems that simply importing or reloading '__main__' doesn't work, because it's considered a built-in module. Apparently, I'll have to explicitly load the module via the found importer. ___ 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] Subversion branch merging
That said, there are always strong arguments in favour of the distributed model encouraging and fostering community dev participation Just for the record: Python's development model *is* distributed, and has been for a long time. We don't all work in the same office, or even in the same time zone. We rarely meet face-to-face (although the recent hiring wave at Google has changed some of that - but then, there also was ZC, BeOpen, CNRI before that). I really don't think that the non-D aspect of the VCS is a burden to contribution. Many patches are contributed from the released source, i.e. without bothering to check out anything, or even from the binary installation, i.e. without bothering to download and build the source. People who don't use subversion to get themselves the latest sources to contribute against won't start doing so if some other system was used (they are less likely to if they have to learn it first). Instead, requiring contributors to use the Python VCS would place a burden, as does the requirement that we already have to contribute diff files, rather than an edited version of the original file. Also, having to register with the bugtracker is a burden for some contributors. Regards, Martin ___ 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] Add a -z interpreter flag to execute a zip file
On 7/14/07, Andy C [EMAIL PROTECTED] wrote: On 7/13/07, Jim Jewett [EMAIL PROTECTED] wrote: while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? No; they don't use a file. It is treated as a strictly dynamic scratchpad, and they do things like import __main__ __main__.DEBUGLEVEL=5 if __main__.myvar: ... -jJ ___ 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
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (07/08/07 - 07/15/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1646 open ( +1) / 8584 closed ( +0) / 10230 total ( +1) Average duration of open issues: 856 days. Median duration of open issues: 805 days. Open Issues Breakdown open 1646 ( +1) pending 0 ( +0) Issues Created Or Reopened (1) __ Datetime enhancements07/13/07 http://bugs.python.org/issue1031created FredFlinstone ___ 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
