After installing the x64 version of Python 2.5.1 via the MSI file on
python.org, I noticed most of the registry keys are "missing". Further
investigation shows they aren't actually missing, but have simply been
"virtualized", so they actually appear under the Wow6432Node key.
This Wow6432Node key is used by 32bit programs running on a 64bit OS.
Ironically, this means that a 32 bit Python can open HKLM\Software\Python -
the OS virtualizes that request to the Wow3264Node tree. However, a 64 bit
Python (ie, the very Python that was installed by the MSI) fails to open
that key - no vistualization occurs and as the key specified does not exist,
we fail. For example:
This is the Python 2.5 installed by the MSI installer:
Python 2.5.1 (r251:54863, Apr 18 2007, 09:02:36) [MSC v.1400 64 bit (AMD64)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import _winreg
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
WindowsError: [Error 2] The system cannot find the file specified
But if I use a 32bit version of Python:
Python 2.5.1 (release25-maint, Jun 4 2007, 23:00:11) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _winreg
<PyHKEY at 004790B0 (00000098)>
I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
start. One thing I did notice is that msilib\__init__.py has a variable
'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
Presumably it is relevant to *something*, otherwise it would not have been
created - but its unclear when and how this should be set to 1, and if this
should concern people trying to use bdist_msi to create x64 extension
packages - but for now, let's just stick with the topic at hand - the
registry keys set by the installer.
I completely intend to finish the backlog of summaries, but I've
reached the point that I know it is futile to continue thinking I'll
be able to fit in the time for the summaries in an on-going and
reliable manner. When I took on the responsibility, it was looking
like time would be fine. Since then, I had to move, my work load has
at least tripled, children prove more time consumer once they learn to
walk, and I'm even having to look at the possibility of expanding
beyond a one-man operation.
When I took the position, I had the time. My situation only lasted
that way for a couple weeks. Every time I think it will change,
something else happens. At this point, I can't keep fooling myself.
But, as I said, I absolutely will be finishing the summaries I have
not done, to make up for my mistakes with this. I haven't even had the
time to read python-dev during all these months, much less write about
Becoming involved with the upcoming Python Magazine is just the
evidence I needed that my life is not as care free as it was when I
thought I could make time for this.
Is anyone interested in taking the (much dwindled) flame from my unable hands?
Read my blog! I depend on your acceptance of my opinion! I am interesting!
Scott Dial wrote:
> In general, this is not true. FAT16 can address a 2GB device and I can
> think of at least one embedded system I am working with that does not
> support FAT32. If anything, at least .pyzip reduces to .pyz in 8dot3
> (whereas .py.z reduces to .z *yikes!*). However, I think it is still
> best practice to aim for 8dot3 naming.
The three-letter extension namespace is very small and heavily
overloaded. There's no such thing as a previously unused three-letter
extension; it's bound to conflict with something, even if we don't
know what it is. It's not best practice to restrict yourself to
short, cryptic, ambiguous names unless you have to.
For stuff hardwired into the interpreter, I agree it's safer to stick
with 8+3. But this is just the default association created by the
installer. If it's creating problems, you can always rename your
files to .pyz or whatever you like and create an association for that.
I'm a little surprised that people are suffering 8+3 names on their
usb drives in this day and age still. I suppose if I had to deal with
that, I would just zip/tar up my long-file-named files in an 8+3-named
archive. And since a .pyz-file is just such an archive, I concede the
point and withdraw my suggestion.
I'm tasked with performing a number of merge operations across
various Python branches. Can somebody please share a command
line that I should use to continue with the merge tracking that
has been used? Is that documented somewhere?
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 enhancements 07/13/07
http://bugs.python.org/issue1031 created FredFlinstone
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
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.
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.
[on using __main__ instead of __init__ or __zipmain__]
> __main__.py? : ) If someone tries does import __main__ from another
> module in the program, won't that result in an infinite loop?
It doesn't today; it does use circular imports, which can be a problem.
> while I think it would be a bad practice to
> import __main__,
I have seen it recommended as the right place to store global
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
>On 7/12/07, "Martin v. Löwis" <martin(a)v.loewis.de> wrote:
> > > The patch suggests using .pyz and adding a default association to the
> > > installer (much like .py and .pyw have).
> > Ok. It would be good if the patch actually added that extension, rather
> > than merely suggesting that it should be added.
>So does everyone agree that there should be a new extension called
>.pyz? And that the definition of this is a .zip file with a
>__zipmain__.py module at its root? If so, I can make the change... I
>haven't looked around the codebase yet but it sounds easy enough.
Let's use __main__, please. Fewer names to remember, and __main__ is
supposed to be the __name__ of the main program. It Just Makes Sense<TM>.
>* Does anyone else want to change the -z flag to make more sense for
>directories (and possibly change __zipmain__.py to __main__.py)? In
>thinking about this again, I am not sure I can come up with a real use
Testing your package before you zip it, would be one. :) My
personal main interest was in being able to add an item to sys.path
without having to set $PYTHONPATH on Windows. That's why I'd like it
to be possible to use -z more than once (or whatever the option ends up as).
> I think it's sufficient to treat it as a documented "trick"
>that you can substitute a whole directory for a zip file with the -z
>flag. If there is a concrete suggestion, I'd like to discuss it, but
>otherwise it seems like we'll get bogged down in expanding use cases.
Eh? First you say there aren't any use cases, now you say there'll be
too many? I'm confused. The only competing proposal besides what
I've suggested was the one to add an option to "runpy", and IMO
that's dead in the water due to shebang argument limits.
>* 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
I personally don't see any benefit to making up an extra name, when
we already have one that describes the functionality
perfectly. There is absolutely nothing about -z that needs or should
care about zipfile-ness, so why add an unnecessary limitation while
creating yet another __special__ name to remember?
After thinking about it some more, I suggest that instead of using a
special option to execute a zipfile, we simply always get an importer
for the script filename. If the importer is imp.NullImporter, then
we do normal script processing. Otherwise, we set set sys.path =
sys.argv = script, and import __main__.
This will support zipfiles and directories, Windows and Unix, even
using "env" (since no option to the interpreter is required).