[Python-Dev] buildin vs. shared modules

[David LeBlanc]

> IOW, I have *never* seen anybody who wanted to rebuild a stock Python
> module without having to download the entire Python source code, and
> rebuild everything. After years of listening to python-help, I found
> that the most common application of rebuilding parts or all of Python
> is building debug binaries on Windows, to debug your own extension
> modules. This requires rebuilding all of Python, and people accept
> that (even though they don't like it).

Are we talking about the same thing? I'm by no means suggesting that the
python.x.x.tar.gz source be broken up! I'm not aware of any ability to
download component sources any other way, nor would I want that!

I have had the experience of building and rebuilding specific extensions of
Python to find a bug. I found it and reported it. I'm proud to say that I
found a very obscure bug in Python that affected how Zope was written at the
time. My 2 seconds of fame ;)

> > Perception does count for a lot, especially when reviewers are
> making gross
> > comparisons of executable (including dlls) sizes.
>
> I, personally, would not make technical decisions on grounds of
> perception which I know would be unfounded. I can see how other people
> would let their decisions guide by incorrect perception, and I find
> that unfortunate (but can accept it).
>
> I would, personally, strive to correct incorrect perception by means
> of education. I know this is a tedious process.

Yes, me too, but there are no end to the number of people who will look at
the surface and never dig deeper. If perception turns people away from
Python, that is not a good thing.

> > Yes. What big benefit does this offer compared to the status quo? Aren't
> > there more important things to devote resources to?
>
> The big benefit is that it simplifies packaging and deployment, and I
> believe this is the reason why Thomas Heller, who has just taken over
> Windows packaging, wants to see it implemented. It simplifies his life,
> and wasting volunteer time should not be taken lightly.

As from above, I'm not, nor do I think it was the original poster's intent,
suggesting that the Python distro be broken up. At this point, I download 2
files: the python binary and the python source. I thought this was about
merging all the .pyd files into a single python dll? As far as I can see,
that's not a distribution issue per se.

> It also simplifies my life, as I plan to maintain a Win64 port. I have
> to perform manual adjustments in each project file - the fewer project
> files, the better.
>
> There are certainly more important things to devote resources to, like
> fixing bugs. Unfortunately, there are no volunteers for these
> important things, and the volunteers tend to look into things that are
> not important but fun.
>
> > If there is enough feeling about it, would it be possible to create an
> > alternate VS project that could do the all in one dll instead of pulling
> > everyone along one path because a few like an idea?
>
> That would cause DLL hell - there must not be competing versions of
> python23.dll.

If I build it one way on my machine, how would that cause dll hell?

> There is also the issue of converting the VS6 projects to VS7.1; when
> that happens, a re-organization might be in place.
>
> > Why do you find it necessary to characterize some honest
> questions as FUD
> > instead of speaking to the merits or demerits of the discussion?
>
> Because it is: this was not meant as a critique, or bad-mouthing, or
> some such; if you have taken it in this sense, I apologize. The only
> rationale for leaving things as-is was that users might fear things
> that you also knew where unfounded fears because of uncertainty - FUD.
>
> Regards,
> Martin

David LeBlanc
Seattle, WA USA