Python 2.0b2 note for Windows developers

Since most Python users on Windows don't have any use for them, I trimmed the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe and .dll files. If you want them, they're available in a separate zip archive; read the Windows Users notes at http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html for info and a download link. If you don't already know *why* you might want them, trust me: you don't want them <wink>. they-don't-even-make-good-paperweights-ly y'rs - tim

Tim, Two requests: 1. Can you ship the .PDB files for the debug images so devo's do not need to build the python sources to debug extensions. And Yes I know the .ZIP will be huge. If you want a compromise only include the .PDB for python20_d.dll. 2. Place the files into libs, pyd etc dirs. I had to extract the groups into the right places which is a bit tedious and error prone. BArry

[Barry]
Sure! Most .pdb files are highly compressible, and the zip size hit isn't anything to worry about.
No. If you want a directory structure that doesn't match the actual build directory structure, I can't read your mind, and have no reason to believe that the specific artificial structure you have in mind is of use to anyone but you. Don't be so helpless <wink>: write a tiny Python script to move the files where you want them after unpacking. What I upload will be an exact image of the build directory structure. Most feedback I've gotten is that people want exactly that, because they *want* to compile Python themselves and just want to avoid jumping thru all the snaky hoops needed to compile the 3rd-party subprojects (from _tkinter to zlib). alphabetically y'rs - tim

Thanks
The structure I refer to is the one used by the Python Windows installer.
but you. Don't be so helpless <wink>: write a tiny Python script to move
I comment not because I'm lazy but because it seemed that every developer would need to reorganise the files.
I'd not thought of that. MY assumption was that I build the release windows code against the files installed by the python windows installer. And that the debug settings would logically point into the same structure.
Barry

[Tim]
[Barry]
I'd not thought of that.
My either. I must admit mild surprise at that. If people want the debug files in the same tree as the build tree, it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries? My experience with people wanting debug binaries is that they either don't want to, or can not build. When people need debug binaries, they go one of 2 routes - try and find pre-built debugs, or build them themselves. I can't see when people ever do both. For the last year or so, I have been making Debug builds of win32all available to registered users. This has always been made available in the "install" structure - quite a bit different than the source/build structure. I've never been asked for anything different. Just-FWIW ly, Mark.

[Tim]
[Barry Scott]
I'd not thought of that.
[Mark Hammond]
My either. I must admit mild surprise at that.
Not me, because this is the Python core: extension writers often have problems with their use of the Python C API, and the core is what supplies that. It's not surprising that they want to, e.g., drop some printfs into Python itself to see what's going on. Then they need to recompile Python. Plus that all the examples and instructions for building extensions assume you're working in a build-- not a release --tree.
If people want the debug files in the same tree as the build tree,
Some people, not all; by my informal count so far, "most", but it's like 2 or 3 to 1 -- and that's not only a ratio but a grand-total count.
it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries?
The "huge initial build" is no more than a few minutes, *provided* that they don't have to crawl over the web too to get source for, and figure out what to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb, pyexpat and zlib). Dealing with the latter for the first time can consume hours.
My experience with people wanting debug binaries is that they either don't want to, or can not build.
If they can't build, it's hard to take their claim to be developing extension modules seriously <wink>.
Were you *asked* for even that much? Barry's was the first request Guido recalls ever getting. It sounded reasonable to me to supply *something*, so I did. But the download stats for this zip file suggest it's not popular enough to be worth arguing over. Still, I've gotten a little feedback on it, and most people seem to be happy. Not all developers want the same thing, and a flat .zip file with no internal directory structure is maximally flexible. If a handful of other Windows developers pop up who swear they can't live with a flat file, and can't bear to write a little Python or .bat script to move the files to where they want them, and swear they want some directory structure that's a fuzzy generalization of the Windows install structure, and swear they all want the same fuzzy generalization (e.g., where do they want the .pdb files? there are none in the install tree now), then, sure, I'll make the *other* peoples' lives a bit more difficult by default. I'm not going to ship two (or more!) of these things, though. view-it-as-a-chance-for-activestate-to-take-over<wink>-ly y'rs - tim

Tim, Two requests: 1. Can you ship the .PDB files for the debug images so devo's do not need to build the python sources to debug extensions. And Yes I know the .ZIP will be huge. If you want a compromise only include the .PDB for python20_d.dll. 2. Place the files into libs, pyd etc dirs. I had to extract the groups into the right places which is a bit tedious and error prone. BArry

[Barry]
Sure! Most .pdb files are highly compressible, and the zip size hit isn't anything to worry about.
No. If you want a directory structure that doesn't match the actual build directory structure, I can't read your mind, and have no reason to believe that the specific artificial structure you have in mind is of use to anyone but you. Don't be so helpless <wink>: write a tiny Python script to move the files where you want them after unpacking. What I upload will be an exact image of the build directory structure. Most feedback I've gotten is that people want exactly that, because they *want* to compile Python themselves and just want to avoid jumping thru all the snaky hoops needed to compile the 3rd-party subprojects (from _tkinter to zlib). alphabetically y'rs - tim

Thanks
The structure I refer to is the one used by the Python Windows installer.
but you. Don't be so helpless <wink>: write a tiny Python script to move
I comment not because I'm lazy but because it seemed that every developer would need to reorganise the files.
I'd not thought of that. MY assumption was that I build the release windows code against the files installed by the python windows installer. And that the debug settings would logically point into the same structure.
Barry

[Tim]
[Barry]
I'd not thought of that.
My either. I must admit mild surprise at that. If people want the debug files in the same tree as the build tree, it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries? My experience with people wanting debug binaries is that they either don't want to, or can not build. When people need debug binaries, they go one of 2 routes - try and find pre-built debugs, or build them themselves. I can't see when people ever do both. For the last year or so, I have been making Debug builds of win32all available to registered users. This has always been made available in the "install" structure - quite a bit different than the source/build structure. I've never been asked for anything different. Just-FWIW ly, Mark.

[Tim]
[Barry Scott]
I'd not thought of that.
[Mark Hammond]
My either. I must admit mild surprise at that.
Not me, because this is the Python core: extension writers often have problems with their use of the Python C API, and the core is what supplies that. It's not surprising that they want to, e.g., drop some printfs into Python itself to see what's going on. Then they need to recompile Python. Plus that all the examples and instructions for building extensions assume you're working in a build-- not a release --tree.
If people want the debug files in the same tree as the build tree,
Some people, not all; by my informal count so far, "most", but it's like 2 or 3 to 1 -- and that's not only a ratio but a grand-total count.
it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries?
The "huge initial build" is no more than a few minutes, *provided* that they don't have to crawl over the web too to get source for, and figure out what to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb, pyexpat and zlib). Dealing with the latter for the first time can consume hours.
My experience with people wanting debug binaries is that they either don't want to, or can not build.
If they can't build, it's hard to take their claim to be developing extension modules seriously <wink>.
Were you *asked* for even that much? Barry's was the first request Guido recalls ever getting. It sounded reasonable to me to supply *something*, so I did. But the download stats for this zip file suggest it's not popular enough to be worth arguing over. Still, I've gotten a little feedback on it, and most people seem to be happy. Not all developers want the same thing, and a flat .zip file with no internal directory structure is maximally flexible. If a handful of other Windows developers pop up who swear they can't live with a flat file, and can't bear to write a little Python or .bat script to move the files to where they want them, and swear they want some directory structure that's a fuzzy generalization of the Windows install structure, and swear they all want the same fuzzy generalization (e.g., where do they want the .pdb files? there are none in the install tree now), then, sure, I'll make the *other* peoples' lives a bit more difficult by default. I'm not going to ship two (or more!) of these things, though. view-it-as-a-chance-for-activestate-to-take-over<wink>-ly y'rs - tim
participants (3)
-
Barry Scott
-
Mark Hammond
-
Tim Peters