[EVALUATION] - E02 - Support for MinGW Open Source Compiler

[Ilias Lazaridis]

I'm a newcomer to python:

[EVALUATION] - E01: The Java Failure - May Python Helps?
http://groups-beta.google.com/group/...f0c5c35374f553

-

I've download (as suggested) the python 2.4 installer for windows.

Now I have problems to compile python extension that some packages
depend on.

I use the MinGW open-source compiler.

-

My questions:

a) Why does the Python Foundation not provide additionally a binary
version, compiled with MinGW or another open-source compiler?

b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?

c) Why are the following efforts not _directly_ included in the python
source code base?

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

above link found in this thread:

http://groups-beta.google.com/group/...f0444c467de525

d) Is it really neccessary that I dive into such adventures, to be able
to do the most natural thing like: "developing python extensions with
MinGW"?

http://starship.python.net/crew/kern...w32/Notes.html

e) Is there any official statement available regarding the msvcr71.dll
and other MS licensing issues?

[see several threads "[Python-Dev] Is msvcr71.dll re-redistributable?"]

http://mail.python.org/pipermail/pyt...ry/thread.html

f) Are there any official (Python Foundation) statements / rationales
available, which explain why the MinGW compiler is unsupported, although
parts of the community obviously like to use it?

http://groups-beta.google.com/group/...3474e6c8053336

-

I just want to understand.

Thankfull for any pointer to official documents / statements.

[google is _not_ a fried here. I like to have a stable development
environment, which is supported by the official projects, thus it can
pass quality-assurance without beeing afraid about every next release.]

..

--
http://lazaridis.com

[Michael Hoffman]

Ilias Lazaridis wrote:

a) Why does the Python Foundation not provide additionally a binary
version, compiled with MinGW or another open-source compiler?
I use a binary version of Python compiled with an open-source compiler
on Windows that was provided by someone else.
b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?
Why should they? It already runs on Windows with a freely available
compiler.
f) Are there any official (Python Foundation) statements / rationales
available, which explain why the MinGW compiler is unsupported, although
parts of the community obviously like to use it?
Not to my knowledge. But I would guess because supporting it would
obviously be a lot of work and the core developers have other things to
do they consider more important. They are volunteers, you know.

Why don't you solve this problem and produce a patched version of
Python that does what you want.
[google is _not_ a fried here. I like to have a stable development
environment, which is supported by the official projects, thus it can
pass quality-assurance without beeing afraid about every next release.]

Then you have several options:

a) use a supported development environment
b) do the work yourself to support MinGW
c) pay someone else to do the work

But don't act like the volunteers who develop Python owe you a version
of Python that runs out of the box on MinGW. They don't, anymore than you
owe *me* a version of Python that runs out of the box on MinGW.

Now why haven't *you* produced a version of Python that is directly
compileable with MinGW? Time's a-wasting.
--
Michael Hoffman

[Miki Tebeka]

Hello Ilias,

d) Is it really neccessary that I dive into such adventures, to be able
to do the most natural thing like: "developing python extensions with
MinGW"?

Writing a setup.py and running
python setup.py build_ext --compiler=mingw32
works for me *without* any more work. Things can't get much simpler.

Bye.
--
------------------------------------------------------------------------
Miki Tebeka <mi*********@zoran.com>
http://tebeka.bizhat.com
The only difference between children and adults is the price of the toys

[Fuzzyman]

Ilias Lazaridis wrote:

I'm a newcomer to python:

[EVALUATION] - E01: The Java Failure - May Python Helps?
http://groups-beta.google.com/group/...f0c5c35374f553
-

I've download (as suggested) the python 2.4 installer for windows.

Now I have problems to compile python extension that some packages
depend on.

I use the MinGW open-source compiler.

-

My questions:

a) Why does the Python Foundation not provide additionally a binary
version, compiled with MinGW or another open-source compiler?

It's not necessary.
b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?

Are you sure it isn't ?
c) Why are the following efforts not _directly_ included in the python source code base?

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

above link found in this thread:

http://groups-beta.google.com/group/...f0444c467de525
d) Is it really neccessary that I dive into such adventures, to be able to do the most natural thing like: "developing python extensions with MinGW"?

http://starship.python.net/crew/kern...w32/Notes.html

Not very difficult. The mingw compiler *is* supported through
distutils. distutils can straightforwardly be configured to build
extensions with mingw. The relevent lib files need converting, which is
also simple.

I did it for Python 2.3. For Python 2.4 I use the free MS optimimizing
compiler. That does need a bit of hacking into distutils, but gain -
not very difficult.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml
e) Is there any official statement available regarding the msvcr71.dll and other MS licensing issues?

[see several threads "[Python-Dev] Is msvcr71.dll re-redistributable?"]
http://mail.python.org/pipermail/pyt...ry/thread.html

f) Are there any official (Python Foundation) statements / rationales available, which explain why the MinGW compiler is unsupported, although parts of the community obviously like to use it?

http://groups-beta.google.com/group/...3474e6c8053336
-

I just want to understand.

Thankfull for any pointer to official documents / statements.

[google is _not_ a fried here. I like to have a stable development
environment, which is supported by the official projects, thus it can pass quality-assurance without beeing afraid about every next release.]
.

--
http://lazaridis.com

[Ilias Lazaridis]

Michael Hoffman wrote:

Ilias Lazaridis wrote:

a) Why does the Python Foundation not provide additionally a binary
version, compiled with MinGW or another open-source compiler?
I use a binary version of Python compiled with an open-source
compiler on Windows that was provided by someone else.

Can you please point me (and the readers) to this resource?

b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?

Why should they? It already runs on Windows with a freely available
compiler.

Obvious: Courtesy [against the userbase needs]

Obvious: Consistency [same code-base across different compiler]

f) Are there any official (Python Foundation) statements /
rationales available, which explain why the MinGW compiler is
unsupported, although parts of the community obviously like to use
it?

Not to my knowledge.

[...] - (guess & comments)

thank you.
Why don't you solve this problem and produce a patched version of
Python that does what you want.
I'm not intrested in patching.

I'm intrested in a stable environment, supported by the original
implementors.

I need a solid fundament for my development.

[google is _not_ a fried here. I like to have a stable development
environment, which is supported by the official projects, thus it
can pass quality-assurance without beeing afraid about every next
release.]

Then you have several options:

a) use a supported development environment

Requirement: "full open-source tool-chain".
b) do the work yourself to support MinGW
this would be not neccessary, as others do this work already.

My question (that you've ommited) was: why does the python foundation
not include this efforts?

[REQUOTE]

c) Why are the following efforts not _directly_ included in the
python source code base?

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

above link found in this thread:

http://groups-beta.google.com/group/...f0444c467de525

[/REQUOTE]
c) pay someone else to do the work

But don't act like the volunteers who develop Python owe you a
version of Python that runs out of the box on MinGW. They don't,
anymore than you owe *me* a version of Python that runs out of the
box on MinGW.
I think Python is a serious Open Source System, driven by the Python
Foundation.

Serious Open Source Systems should serve the basic needs of their
community, especially if there are many depending systems.

If it is a programming language, the requirement "using an open-source
toolchain" is a rational and valid one.

The Python Foundation ingores this requirement, this way creating a
chain of neccessary manual uncontrolled actions.

This does not increase my trust in python [e.g. as an exchange for JAVA].
Now why haven't *you* produced a version of Python that is directly
compileable with MinGW? Time's a-wasting.

I have stated already that I am a newcomer to python.

[you should really avoid this tenor. Python is not an open-source
project of a few teenies. It's a serious programming-language, which
could be adopted by e.g. more phone-manufacturers (after Nokia)]

-

The Python Foundation could create an official sub-project to create an
automated build target based on the MinGW toolchain. I am sure that many
community members would be more than happy to contribute.

..

--
http://lazaridis.com

[Ilias Lazaridis]

[please check your news-client. For some reason, the tag "[EVALUATION]"
was removed]

-

You answer essentially something like "It's not necessary" cause "with a
little hacking it works".

I've found lots of documents, which describe how to "hack around" to
make it work.

I don't want to do "hacking".

I want to develope large scale applications, and for this I need an
stable official version of the python language, either binary or
produced directly out of official sources, completely with an
open-source tool-chain.

That's the reason for my very specific questions, which you have mostly
ignored.

-

copied from another answer:

"The Python Foundation could create an official sub-project to create an
automated build target based on the MinGW toolchain. I am sure that many
community members would be more than happy to contribute."

..

--
http://lazaridis.com

[Fuzzyman]

Ilias Lazaridis wrote:
[snip..]

b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?
Why should they? It already runs on Windows with a freely available compiler.

Obvious: Courtesy [against the userbase needs]

Obvious: Consistency [same code-base across different compiler]

Are you aware that the MSVC compiler they use produces tighter code
than gcc ? [1] *Most* users would rather have a faster python than a
python built with an open source compiler.

Particularly as distutils (read Python) can *easily* be configured to
use mingw to build extensions from source - which seems to be your real
requirement.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shmtl

[snip..] --
http://lazaridis.com

[1] Not knocking gcc - it's just optimsied for portability rather than
speed. If you want to see *a* benchmark, there is a link to one in my
'upgrading python' article. (In the article section at
http://www.voidspace.org.uk/python/index.shmtl )

[Michael Hoffman]

Ilias Lazaridis wrote:

Michael Hoffman wrote:

Can you please point me (and the readers) to this resource?
http://www.cygwin.com/

Why don't you solve this problem and produce a patched version of
Python that does what you want.

I'm not intrested in patching.

I'm intrested in a stable environment, supported by the original
implementors.

And the core developers are not interested in doing more than what they
have already done without further help (e.g. from you). Surely you can
"not interested" as you have justified your own inaction through it.
This does not increase my trust in python [e.g. as an exchange for JAVA].
You cannot run all Java programs on an open source compiler, so I guess
it's an imperfect world for you. And to get GCJ to run on MinGW you have to
add a lot of patches.

Now why haven't *you* produced a version of Python that is directly
compileable with MinGW? Time's a-wasting.

I have stated already that I am a newcomer to python.

[you should really avoid this tenor.

And you should avoid yours. Your sense of entitlement is palpable.
Python is not an open-source project of a few teenies. It's a serious
programming-language, which could be adopted by e.g. more
phone-manufacturers (after Nokia)]

The idea that MinGW support would affect that is laughable.
--
Michael Hoffman

[Ilias Lazaridis]

Miki Tebeka wrote:

Hello Ilias,

d) Is it really neccessary that I dive into such adventures, to be able
to do the most natural thing like: "developing python extensions with
MinGW"?

Writing a setup.py and running
python setup.py build_ext --compiler=mingw32
works for me *without* any more work. Things can't get much simpler.

looks really simple.

-

but:

the central problem still exists:

"** For a Python which was built with Cygwin, all should work without
any of these following steps. **"
source:
http://www.python.org/doc/2.2.3/inst...00000000000000

-

"the problem is that Python binary distributions for MS Windows do not
include import libraries for popular gcc based tools: cygwin and mingw32"
source: http://www.zope.org/Members/als/tips..._mingw_modules

-

the solutions is possibly (copied from another answer):

"The Python Foundation could create an official sub-project to create an
automated build target based on the MinGW toolchain. I am sure that many
community members would be more than happy to contribute."

..

--
http://lazaridis.com

[Michael Hoffman]

Ilias Lazaridis wrote:

"The Python Foundation could create an official sub-project to create an
automated build target based on the MinGW toolchain. I am sure that many
community members would be more than happy to contribute."

An "official sub-project" for something like this is not necessary. Identify
what needs to be done and create a patch, and it will be accepted if it is
a good patch.
--
Michael Hoffman

[David Fraser]

Ilias Lazaridis wrote:

I'm a newcomer to python:

[EVALUATION] - E01: The Java Failure - May Python Helps?
http://groups-beta.google.com/group/...f0c5c35374f553

-

I've download (as suggested) the python 2.4 installer for windows.

Now I have problems to compile python extension that some packages
depend on.

I use the MinGW open-source compiler.

-

My questions:

a) Why does the Python Foundation not provide additionally a binary
version, compiled with MinGW or another open-source compiler?

b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?

c) Why are the following efforts not _directly_ included in the python
source code base?

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

above link found in this thread:

http://groups-beta.google.com/group/...f0444c467de525

d) Is it really neccessary that I dive into such adventures, to be able
to do the most natural thing like: "developing python extensions with
MinGW"?

http://starship.python.net/crew/kern...w32/Notes.html

e) Is there any official statement available regarding the msvcr71.dll
and other MS licensing issues?

[see several threads "[Python-Dev] Is msvcr71.dll re-redistributable?"]

http://mail.python.org/pipermail/pyt...ry/thread.html

f) Are there any official (Python Foundation) statements / rationales
available, which explain why the MinGW compiler is unsupported, although
parts of the community obviously like to use it?

http://groups-beta.google.com/group/...3474e6c8053336

-

I just want to understand.

Thankfull for any pointer to official documents / statements.

[google is _not_ a fried here. I like to have a stable development
environment, which is supported by the official projects, thus it can
pass quality-assurance without beeing afraid about every next release.]

Just to add to all the other answers:

Don't just complain, submit patches and work at keeping them maintained.
If this is done for a while it may be more of an argument for having
them included

David

[Diez B. Roggisch]

Ilias Lazaridis wrote:

[please check your news-client. For some reason, the tag "[EVALUATION]"
was removed]

I want to develope large scale applications, and for this I need an
stable official version of the python language, either binary or
produced directly out of official sources, completely with an
open-source tool-chain.

Where does that requirement come from? If you want to create large scale
apps, the price for a msvc++ compiler shouldn't matter. And: Windows is a
non-free platform at first. If you have to or want to develop on top of it,
be prepared to pay. Its as simple as that. If you want something cheaper -
you'll have to put some effort into it. Or use linux.

Additionally, your point is moot because there is no need for python _core_
developers or the foundation to support every imaginable platform/compiler
combination. Instead this can be done by companies - see activestate. So if
you want it, step up and do it yourself so your work _becomes_ the official
mingw port. Community gratitude would be guaranteed.

--
Regards,

Diez B. Roggisch

[Ilias Lazaridis]

Fuzzyman wrote:

Ilias Lazaridis wrote:
[snip..]

b) Why does the Python Foundation not ensure, that the python
source-code is directly compilable with MinGW?

Why should they? It already runs on Windows with a freely available
compiler.
Obvious: Courtesy [against the userbase needs]

Obvious: Consistency [same code-base across different compiler]

Are you aware that the MSVC compiler they use produces tighter code
than gcc ? [1] *Most* users would rather have a faster python than a
python built with an open source compiler.
Particularly as distutils (read Python) can *easily* be configured to
use mingw to build extensions from source - which seems to be your real
requirement.

This is not relevant.

The Python Foundation should just ensure, that the source-code-base is
compilable with MinGW on windows, too.

This is a very natural requirement.

There is really no need to 'fight' against this.

There is just a need to cooperate to achieve this.

[...] [1] Not knocking gcc - it's just optimsied for portability rather than
speed. If you want to see *a* benchmark, there is a link to one in my
'upgrading python' article. (In the article section at
http://www.voidspace.org.uk/python/index.shmtl )

..

--
http://lazaridis.com

[Ilias Lazaridis]

Diez B. Roggisch wrote:

Ilias Lazaridis wrote:

I want to develope large scale applications, and for this I need an
stable official version of the python language, either binary or
produced directly out of official sources, completely with an
open-source tool-chain.
Where does that requirement come from? If you want to create large
scale apps, the price for a msvc++ compiler shouldn't matter. And:
Windows is a non-free platform at first. If you have to or want to
develop on top of it, be prepared to pay. Its as simple as that. If
you want something cheaper - you'll have to put some effort into it.
Or use linux.

I will not go into this 'twisting' games.

the requirement "Use of an open-source tool-chain" is nothing special.
Additionally, your point is moot because there is no need for python
_core_ developers or the foundation to support every imaginable
platform/compiler combination.
MinGW is not "every imaginable platform/compliler".
Instead this can be done by companies - see activestate. So if you
want it, step up and do it yourself so your work _becomes_ the
official mingw port. Community gratitude would be guaranteed.

I'm not intrested in creating an distribution.

I provide an analysis of the situation, context: newcomer, disapointed
from JAVA.

One of my questions is:

[REQUOTE]

c) Why are the following efforts not _directly_ included in the
python source code base?

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

[/REQUOTE]

..

--
http://lazaridis.com

[Ilias Lazaridis]

David Fraser wrote:

Ilias Lazaridis wrote: [...] Just to add to all the other answers:

Don't just complain, submit patches and work at keeping them maintained.
If this is done for a while it may be more of an argument for having
them included

I do not "just complain".

I've spend already hours with writing down the questionaire [which you
have successfully ignored].

..

--
http://lazaridis.com

[Ilias Lazaridis]

Michael Hoffman wrote:

Ilias Lazaridis wrote:

"The Python Foundation could create an official sub-project to create
an automated build target based on the MinGW toolchain. I am sure that
many community members would be more than happy to contribute."
An "official sub-project" for something like this is not necessary.

It is.

I hope the officials from the Python Foundation detect that:

* source code should be _directly_ compilable under major compilers.
* community efforts for such a important functionality should be
channelized and organized
Identify
what needs to be done and create a patch, and it will be accepted if it is
a good patch.

[REQUOTE]

c) Why are the following efforts not _directly_ included in the
python source code base?

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

[/REQUOTE]

..

--
http://lazaridis.com

[Robert Kern]

Ilias Lazaridis wrote:

David Fraser wrote:

Ilias Lazaridis wrote:

[...]

Just to add to all the other answers:

Don't just complain, submit patches and work at keeping them
maintained. If this is done for a while it may be more of an argument
for having them included

I do not "just complain".

I've spend already hours with writing down the questionaire [which you
have successfully ignored].

Why don't you spend hours writing code and submitting working patches,
instead? That's what I did years ago in the original effort to get mingw
to compile Python extensions (one of the, woefully out-dated, web-pages
you cite is mine. I have now edited it to clarify the situation so
others do not come away from it as you did).

Just writing "questionnaires" *is* actually "just complaining."

The answer to most of your questions is, "Because no one has yet
volunteered their time and effort to get the job done."

If this is important to you, you need to step up yourself and get it
done and not expect other people to volunteer their unpaid time to
satisfy your whims.

The open source Python community is driven by volunteerism, not a sense
of entitlement. If this does not appeal to you, then perhaps the Python
community is not the right one for you.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Grant Edwards]

On 2005-02-14, Ilias Lazaridis <il***@lazaridis.com> wrote:

Fredrik Lundh wrote:

Ilias Lazaridis wrote

The idea that the Python Foundation cares about user needs would affect that.
please let the users speak for themselves.

I have.

I've review several threads,publications, actions etc., that show that
the users have this need.

This is open source. You don't just order somebody else to do
what you want. You _do_ it and donate it to the community.
please review the initial thread with care, i've pointed to
some documents/thread.

So what? You want it, you do it.

--
Grant Edwards grante Yow! I'm in ATLANTIC CITY
at riding in a comfortable
visi.com ROLLING CHAIR...

[Stephen Kellett]

In message <RX**************@objmedia.demon.co.uk>, Stephen Kellett
<sn***@objmedia.demon.co.uk> writes

Hi Robert,

Weird, you hit "reply" and the newsreader does a "post". C'est la vie.
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[jfj]

bruno modulix wrote:

Ilias Lazaridis wrote:

I'm a newcomer to python:

[EVALUATION] - E01: The Java Failure - May Python Helps?
http://groups-beta.google.com/group/...f0c5c35374f553

My trollometer's beeping...

When person 'A' calls person 'B' a troll, these are the possibilities:

1. 'A' is indeed a troll

2. 'B' is the troll

3. both 'A' and 'B' are trolls

4. nobody is a troll. they're computer scientists passionate about their
ideas and they are trying to convince each other.

5. nobody is a troll and there is no trolling going on.

Now, it's rather common to accuse people of trolling these days.
The fact that Markus Wankus said that Ilias is a troll does not mean
that everybody should reply to him in that tone.
This is a one .vs many battle and it sucks.
gerald

[Diez B. Roggisch]

> Now, it's rather common to accuse people of trolling these days.

The fact that Markus Wankus said that Ilias is a troll does not mean
that everybody should reply to him in that tone.
This is a one .vs many battle and it sucks.

Just because someone says somebody else is a troll surely is not valid
reason to take that for granted.

But googling [1-*] for Mr. Lazaridis makes it apparent that he _is_ a troll.
And even if you only take the two threads on c.l.py into account IMHO you
can see that.

He's been _banned_ from several OS project mailing lists like eclipse,
netbeans and hibernate. Of course he claims that is because of censorship
and has nothing to do with his actions in those respective communities. But
somehow to me at least a pattern is visible.
[1]:
http://groups-beta.google.com/group/...8a70ee4e39fc41

[2]: http://www.netbeans.org/servlets/Rea...stName=nbusers

[3]:
http://groups-beta.google.com/group/...ae8ee0bccdeb14

[4]:
http://groups-beta.google.com/group/...b5dcfd54a6a902

--
Regards,

Diez B. Roggisch

[Pat]

Wow! I must say, I'm less than impressed with the responses so far. I
know Ilias can give the impression that he is just trolling, but I can
assure you he is not. At least, not in this case. ;-)

So in an effort to make some headway, I'm going to try to summarize the
current state of affairs. The bottom line is that compiling C
extension modules on the Windows platform for Python 2.4 is, today, a
royal pain in the ass. Period. Here's why.

The main challenge is that extensions must be compiled using the same
runtime dll as that used by the Python interpreter itself. The
official Windows binary installation of Python 2.3.5 and its
predecessors was compiled with one MS product, which was fairly easy to
support with minGW, but Python 2.4 was compiled with the newer .NET
compiler. Unfortunately, compiling extensions for Python 2.4 with the
free MS tools is not trivial, as evidenced by Mike Fletcher's very
thorough document on the subject:

Python 2.4 Extensions w/ the MS Toolkit Compiler

http://www.vrplumber.com/programming/mstoolkit/

In addition, there are some unresolved licensing questions concerning
the .NET runtime file for extensions (msvcr71.dll):

http://mail.python.org/pipermail/pyt...ry/051393.html

There have been extensive discussions about these issues on the
Python-Dev mailing list over the past couple of months (mostly in
December, but continuing to the present - see
http://mail.python.org/pipermail/pyt...er/thread.html
as a starting point), which seem to have fizzled out or at least
haven't resolved much. The discussions made reference to work that has
already been done to allow Python to be compiled with minGW:

pyMinGW is a patch to Python source that aims to get Python to compile
under MinGW

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

I've not seen any commentary on the quality of this patch, so that
doesn't appear to be the reason it hasn't been officially adopted.
Reading all the threads from Python-Dev has not enlightened me at all
as to what the underlying reason is for not adopting these changes.
Maybe there are good reasons, I just couldn't find them, and I'm
usually pretty good with Google.

A few of you have mentioned that minGW is not an optimizing compiler on
the Windows platform, whereas the MS .NET one is. If anyone has
information on the performance differences, I'd really appreciate being
able to see it, particularly as it applies to Python 2.4.

Now, we get to the essence of my particular situation. I've got a
project that includes some Python extensions written in C. My users
(who are Python developers, but not necessarily hard-core types) need
to be able to work out of their local Subversion checkouts. This
includes locally compiling these extensions as necessary. I'd like
this to work with Python 2.4, and be as painless as possible on my
users. I can't expect them to purchase a .NET compiler or go through a
bunch of configuration changes. So far, I haven't figured out a good
way to support this. I'm open to suggestions. I suspect that my needs
are very similar to those of the original poster.

Perhaps the issue is in part a matter of minGW catching up with the new
MS compilers. My understanding of and experience with Python 2.3.5 and
its predecessors has been that Python itself didn't need to be
recompiled with minGW, since extensions compiled with minGW linked to
the same C runtime dll. So if minGW had support for msvcr71.dll then
maybe this problem goes away with Python 2.4 as well.

If anyone can shed any light on this situation, it would really help me
out. Thanks.

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Fredrik Lundh]

"Pat" wrote:

The bottom line is that compiling C extension modules on the
Windows platform for Python 2.4 is, today, a royal pain in the
ass.
really?
python setup.py install

works for me.

</F>

[Cameron Laird]

In article <37*************@individual.net>,
Diez B. Roggisch <de*********@web.de> wrote:

One of the most funny things within open-source is that switching:

first:
"we have powerfull solutions which beat this and that"

then:
"hey, this is just volunteer work"

I don't see the contradiction here. It beats a great deal of commercial
solutions in a lot of ways. But not on every single one of these. And the
_reason_ for beating commercial software in certain aspects is exactly that
somebody stood up and volunteered. Obviously you aren't interested in the
more labour-intensive parts of the os-development.

But if those answers above were of official nature, I must seriously
rethink if I can rely on _any_ system which is based on python, as the
foundation and the community do not care about essential needs and
requirements.

They might not care about _your_ perceived essential needs. But as lots of
people use python and python based solutions with great commercial success,
you might think of reviewing your needs more critical. After all, there is
no _perfect_ system for all needs.

[Pat]

So what if someone appears to be a troll? Suck it up and rise above
it. This thread started with legitimate questions. Unfortunately,
almost every response has been dismissive, petty, and a complete waste
of time and effort. Please respond to the issue or simply ignore it.
The issue is real and I'd like to find a solution to it as well. Right
now it feels like I'm in the company of a bunch of hell-bent school
bullies. I'm ashamed of the behavior I'm witnessing on this list.

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Pat]

I thought I was being as clear and specific as I needed to be.
Apparently not. I'm talking about compiling the original source code,
per the recommendations made by Mike Fletcher and documented here:

Python 2.4 Extensions w/ the MS Toolkit Compiler

http://www.vrplumber.com/programming/mstoolkit/

Now, if you know something I don't, I'm all ears. But I don't see how
your suggestion solves my problem. But I'll be thrilled if that is the
case. Care to enlighten me?

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[David Fraser]

Pat wrote:

Wow! I must say, I'm less than impressed with the responses so far. I
know Ilias can give the impression that he is just trolling, but I can
assure you he is not. At least, not in this case. ;-)

So in an effort to make some headway, I'm going to try to summarize the
current state of affairs. The bottom line is that compiling C
extension modules on the Windows platform for Python 2.4 is, today, a
royal pain in the ass. Period. Here's why.

The main challenge is that extensions must be compiled using the same
runtime dll as that used by the Python interpreter itself.

Actually compiling extensions with mingw seems to work fine. Have you
tried it?

David

[Stephen Kellett]

In message <11**********************@o13g2000cwo.googlegroups .com>, Pat
<po*****@orbtech.com> writes

Wow! I must say, I'm less than impressed with the responses so far. I
know Ilias can give the impression that he is just trolling, but I can
assure you he is not. At least, not in this case. ;-)
He deserves what he gets. He appears to put no effort in, other than to
o Write his own document for his own needs that no one else is
interested in
o Answer people's comments to him in a way that does not demonstrate he
has put any effort in.
o Based on his answers it seems pretty clear to me (and it seems many
others) that he has not put any effort in and has no intention of doing
so.
In addition, there are some unresolved licensing questions concerning
the .NET runtime file for extensions (msvcr71.dll):
To quote that URL;
<QUOTE>
The 2.4 python.org installer installs msvcr71.dll on the target system.

If someone uses py2exe or a similar tool to create a frozen application,
is he allowed to redistribute this msvcr71.dll to other users together
with his application or not, even if he doesn't own MSVC?
</END QUOTE>

msvcr71.dll is a redistributable for applications written using their
compiler. You can redistribute that. If that answer is not good enough
for you there is now a free version of Microsofts Visual Studio called
Visual Studio Express (downloadable from the Microsoft's website). This
DLL is (to my understanding) part of Visual Studio 7.1 and Visual Studio
Express.

No licensing problem exists. Microsoft will not get upset about
msvcr71.dll being distributed. They will if you distribute msvcr71d.dll
though - don't do that!

I'm not a lawyer, so take this as you would any other free advice and
download Visual Studio Express and read the redistribution sections in
the license/help file to verify. Alternatively search msdn.microsoft.com
for "redistributable".

Look at this from Microsoft's perspective - Python is a language that
can be used on Windows operating systems. msvcr71.dll is required to
make some versions of Python work. Microsoft are not stupid - they know
that to encourage uptake of their OS they shouldn't put needless
restrictions on certain technology - the C runtime being on of those
technologies. It is in Microsoft's own best interests to allow
msvcr71.dll to be used for Python.
users. I can't expect them to purchase a .NET compiler or go through a

See above.

Regards

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Stephen Kellett]

In message <gu**************@objmedia.demon.co.uk>, Stephen Kellett
<sn***@objmedia.demon.co.uk> writes

Studio Express (downloadable from the Microsoft's website). This DLL is
(to my understanding) part of Visual Studio 7.1 and Visual Studio
Express.

My mistake. Visual Studio Express is going to be part of Version 8
(2005) and thus the DLLs there will be msvcr80.dll

That said, I still stand by my licensing comments.

Distributable files overview.
http://msdn.microsoft.com/library/de...en-us/vccore/h
tml/vcconalistofredistributablefiles.asp

V7.0/V7.1 specific redistribution instructions.
http://support.microsoft.com/default...b;en-us;326922
Title: INFO: Redistribution of the Shared C Runtime Component in Visual
C++ .NET
Article ID : 326922
Last Review : March 25, 2004
Revision : 1.0
Keywords: kbinfo KB326922

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Stephen Kellett]

In message <11**********************@o13g2000cwo.googlegroups .com>, Pat
<po*****@orbtech.com> writes

now it feels like I'm in the company of a bunch of hell-bent school
bullies.

From my experience of bully behaviour that isn't what is happening here.
Bullying usually involves abusive behaviour and language and isn't much
to do with the topic as the person. The responses he has got are to do
with how he is behaving, not who he is. I haven't seen any abusive
language. As for behaviour, people are being as blunt with him as he is
with them. Many have also told him what he should do in order to get a
better response. He has ignored them.

Many societies around the world shun people that won't fit the norm. The
norm in the newsgroups he is causing trouble in is that "You look for
yourself first, do some research, then ask". He isn't even willing to
use a search engine, let alone read the documentation or heaven forbid,
read the source code himself. Sooner or later he'll give up, or realise
that if he does a bit of the work himself he'll get much more back. Its
up to him.

You'll notice that I've answered your question in another reply as its
obvious you have put some effort in before making your comments. In
other words I am not behaving in a contradictory way to what I specified
above.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Pat]

Actually, no. We ran into some issues with Python 2.4 that caused us
to return to Python 2.3.5. But I would really like to upgrade to
Python 2.4. So I started researching the subject before I did
anything.

If you are telling me that minGW can compile extensions that are
compatible with the Python 2.4 that uses msvcr71.dll, then that is good
news indeed. Is there anything that needs to be configured or patched
to make this happen? And how does minGW know which dll to link? What
if I have both versions of Python installed - 2.3.5 and 2.4? Is there
an easy way to detect this and switch between the two dlls?

If I'm asking questions already answered elsewhere, I'd love a link to
that resource, if you have it.

Thanks,

Pat

Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Ilias Lazaridis]

Grant Edwards wrote:

On 2005-02-14, Ilias Lazaridis <il***@lazaridis.com> wrote:

Fredrik Lundh wrote:

Ilias Lazaridis wrote

The idea that the Python Foundation cares about user needs would affect that.

please let the users speak for themselves.

I have.

I've review several threads,publications, actions etc., that show that
the users have this need.

This is open source. You don't just order somebody else to do
what you want. You _do_ it and donate it to the community.

I analyze the current situation.

The is the fundamentall step before doing anything.

But the reaction of this community raises some questions and my curiosity.

please review the initial thread with care, i've pointed to
some documents/thread.

So what? You want it, you do it.

I like to synchronize any efforts with the existing ones.

That's why I ask some questions.

nothing special.

..

--
http://lazaridis.com

[Pat]

Stephen,

I appreciate your responses. Maybe "school bullies" was an
exaggeration on my part. At the same time, I'm not sure it is good for
the Python community to expect everyone to roll up their sleeves and
hack at something to make it work. (And I don't mean to imply that you
hold that opinion. But far too many others *have* expressed that.)
It's a marketing issue as much as anything. Why is Apple doing so
well? They make everything simple. Now the techies will argue that
they make some things too simple (like the iPod), but it's hard to deny
that simple things that work consistently without any fuss have a
broader appeal with the public at large.

I think the same applies to developers. Not every programmer is
willing to go through a lot of pain and effort just to get something
simple to work. I, for one, am willing to go through that pain to save
users of my product (who happen to be developers) from having to do the
same. But I don't think any less of my users. I'm as lazy as they
are. I like simple things that work consistently without any fuss too.
:-)

Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Bruno Desthuilliers]

jfj a écrit :

bruno modulix wrote:

Ilias Lazaridis wrote:

I'm a newcomer to python:

[EVALUATION] - E01: The Java Failure - May Python Helps?
http://groups-beta.google.com/group/...f0c5c35374f553

My trollometer's beeping...

When person 'A' calls person 'B' a troll, these are the possibilities:

1. 'A' is indeed a troll

2. 'B' is the troll

3. both 'A' and 'B' are trolls

4. nobody is a troll. they're computer scientists passionate about their
ideas and they are trying to convince each other.

5. nobody is a troll and there is no trolling going on.

Now, it's rather common to accuse people of trolling these days.
The fact that Markus Wankus said that Ilias is a troll does not mean
that everybody should reply to him in that tone.
This is a one .vs many battle and it sucks.

You're totaly right. Now just take some minutes to (re)read this thread,
then google for 'Ilias Lazaridis'.

Bruno

[Stephen Kellett]

In message <11**********************@c13g2000cwb.googlegroups .com>, Pat
<po*****@orbtech.com> writes

Actually, no. We ran into some issues with Python 2.4 that caused us
to return to Python 2.3.5. But I would really like to upgrade to
Python 2.4. So I started researching the subject before I did
anything.

Pat, could you include some context in your replies? I have no idea if
you are replying to my comments about Visual Studio Express or someone
else? The only text I see in your replies is what you write, no text
from the posting you are replying to. As it is I've ignored all your
replies so far as I'm not sure I'm the person you are addressing (until
I saw the above, now I'm confused).

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Bruno Desthuilliers]

Stephen Kellett a écrit :

In message <ma***************************************@python. org>, Simon
Brunning <si************@gmail.com> writes

On Mon, 14 Feb 2005 14:12:57 +0100, bruno modulix <on***@xiludom.gro> wrote:

Why do you hate Perl and Ruby community that much ?
Oh, I don't. But fair's fair - we've carried our share of the burden, surely?

He is already badgering the Ruby guys. Without about as much success as
this newsgroup. When he doesn't get what he wants a post along the lines
of

"XXXX lang is only suited to small projects and not real world
industrial projects"
or
"the community doesn't care"
will appear.

Its quite incredible - in the time he has spent complaining he could
have done his own research and written some useful tools. I know how
long it took me to write my first major C++ app that interfaced with
Python and Ruby. It was less time than he has spent complaining - and
that included rebuilding Python/Ruby, inspecting the source for what I
needed and performing many experiments before I succeeded.

Just google for Ilias Lazaridis... You may observe that our new troll
has already played the same game on many newsgroups, forums and whatever...

Stephen

[Pat]

>>users. I can't expect them to purchase a .NET compiler or go through
a

See above.

That answers the cost question (assuming that your interpretation of
the licensing is correct, since I'm not a lawyer nor qualified to
render much of an opinion on that). But there is still the issue of
going through a bunch of configuration hassle that scares me away from
expecting my users to make use of the MS tools. Unless things have
gotten easier since Mike Fletcher wrote about the situation.

But thanks for the licensing info. Much appreciated. :-)

Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Fredrik Lundh]

"Pat"wrote:

I thought I was being as clear and specific as I needed to be.
Apparently not. I'm talking about compiling the original source code
the python source or the extension source?
The bottom line is that compiling C extension modules
would indicate the latter. setup.py handles that just fine, if you have the
right tools. no pain at all.
Now, if you know something I don't, I'm all ears. But I don't see how
your suggestion solves my problem.

if your problem is compiling C extension modules, I suggest getting a
good compiler. I've done that, and compiling C extension modules is
no problem at all.

if your problem is that you don't want to use a good compiler, or that
your company cannot afford to buy you a compiler, or you have other
reasons to chose the "pain in the ass" way over the "it just works" way,
I'm afraid I cannot help you. my time's too precious to waste on inferior
tools.

</F>

[Pat]

Stephen Kellet said:

<quote>
Pat, could you include some context in your replies? I have no idea if
you are replying to my comments about Visual Studio Express or someone
else? The only text I see in your replies is what you write, no text
from the posting you are replying to. As it is I've ignored all your
replies so far as I'm not sure I'm the person you are addressing (until
I saw the above, now I'm confused).
</quote>

Sorry about that. I'm replying using Google Groups and making a total
mess of things. :-(

David Fraser asked if I had tried to compile a Python extension for
Python 2.4 using minGW. I said that I had not (but I have for Python
2.3.5). Here is the rest of my reply, for future reference:

We ran into some issues with Python 2.4 that caused us
to return to Python 2.3.5. But I would really like to upgrade to
Python 2.4. So I started researching the subject before I did
anything.

If you are telling me that minGW can compile extensions that are
compatible with the Python 2.4 that uses msvcr71.dll, then that is good
news indeed. Is there anything that needs to be configured or patched
to make this happen? And how does minGW know which dll to link? What
if I have both versions of Python installed - 2.3.5 and 2.4? Is there
an easy way to detect this and switch between the two dlls?

If I'm asking questions already answered elsewhere, I'd love a link to
that resource, if you have it.

Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Stephen Kellett]

In message <11**********************@o13g2000cwo.googlegroups .com>, Pat
<po*****@orbtech.com> writes

That answers the cost question (assuming that your interpretation of
the licensing is correct, since I'm not a lawyer nor qualified to
render much of an opinion on that). But there is still the issue of
going through a bunch of configuration hassle that scares me away from

What configuration hassle? Can't be any harder than specifying a
different CRT surely?

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Pat]

Fredrik Lundh wrote:

"Pat"wrote:

I thought I was being as clear and specific as I needed to be.
Apparently not. I'm talking about compiling the original source code

the python source or the extension source?

> The bottom line is that compiling C extension modules
would indicate the latter. setup.py handles that just fine, if you

have the right tools. no pain at all.

Now, if you know something I don't, I'm all ears. But I don't see

how your suggestion solves my problem.

if your problem is compiling C extension modules, I suggest getting a
good compiler. I've done that, and compiling C extension modules is
no problem at all.

if your problem is that you don't want to use a good compiler, or

that your company cannot afford to buy you a compiler, or you have other
reasons to chose the "pain in the ass" way over the "it just works" way, I'm afraid I cannot help you. my time's too precious to waste on inferior tools.

Okay, I think we are pretty much talking about the same thing. My
problem is not that I'm unable or unwilling to purchase a good
compiler. My problem is that I don't want to make it a requirement of
my users. The twist is that my users will be working out of a
Subversion repository that includes source code for extensions written
in C. Those extensions need to be compiled, and the code changes too
frequently for me to want to deal with supplying compiled binaries.

So I'm looking for options for Windows users who do not have, and are
unwilling to get, a Microsoft compiler. For some users, minGW is an
attractive option. For those who want to use minGW, I'm trying to
establish whether or not minGW is a viable option, particularly for
Python 2.4. I was under the impression that there were possible
advantages to compiling Python itself using minGW, but that that
required some patches that hadn't been applied to Python (for reasons
unknown to me). Said patches are available here:

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

I'm also under the impression that there are possible disadvantages to
compiling Python itself with anything other than the Microsoft's
optimizing compiler, such as performance. But I haven't seen any
numbers on that, so I don't have information one way or the other.

It may also be the case that minGW can now correctly compile extension
that link to the newer runtime used by Python 2.4, but that wasn't
always the case. If that's true, that would eliminate the primary
reason for wanting to compile Python itself with minGW, though
philosophical differences with MS might motivate some to want to avoid
the MS compilers altogether.

Perhaps the only thing that's a mess is my understanding of the
situation. But even if that's the case, I don't think I'm alone, based
on all the threads I've read over the past couple of days. ;-)

Thanks in advance for any help anyone can offer to reduce my confusion.

Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[Stephen Kellett]

In message <11*********************@l41g2000cwc.googlegroups. com>, Pat
<po*****@orbtech.com> writes

if I have both versions of Python installed - 2.3.5 and 2.4? Is there
an easy way to detect this and switch between the two dlls?
Easy? Depends what you call easy.

a) You just need to detect if pythonNN.dll is implicitly linked to
msvcrt.dll or msvcrXX.dll (where XX indicates a VS studio number,
currently XX can only be 71, but if Python is done for Visual Studio
2005 (8.0) then XX may also have a value of 80).

b) GetModuleHandle(name of DLL from a) to get the DLL handle.

c) GetProcAddress on the respective to get the C runtime function you
want to call (for example, fopen).

d) call the function.

You either need (a) or all of (a)...(d) depending on what you are doing.
Those embedding Python but no idea of the Python version in advance will
do the latter.
If I'm asking questions already answered elsewhere, I'd love a link to
that resource, if you have it.

I'm probably not the best person to answer such a question. I'm mainly a
C/C++ (with Java under protest) person dabbling in Python/Ruby.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Pat]

Stephen Kellett wrote:

In message <11**********************@o13g2000cwo.googlegroups .com>, Pat <po*****@orbtech.com> writes

That answers the cost question (assuming that your interpretation of
the licensing is correct, since I'm not a lawyer nor qualified to
render much of an opinion on that). But there is still the issue of
going through a bunch of configuration hassle that scares me away

from
What configuration hassle? Can't be any harder than specifying a
different CRT surely?

I don't want to have to ask users of my code to have to go through
this:

http://www.vrplumber.com/programming/mstoolkit/

What I want is to provide everything a user would need within my own
Subversion repository. Any C code would be compiled behind the scenes
using free tools that I'm able to include in my repository (without
having to hire a lawyer first).

Having to tell users that they need to download, install, and configure
all this additional compiler stuff is asking too much from my potential
user base, since I'm also targeting novices and developers from other
languages for whom C compiler stuff is going to be a barrier to entry.

I hope that makes sense. :-)

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst http://www.pypersyst.org

[A.B., Khalid]

Pat wrote:

There have been extensive discussions about these issues on the
Python-Dev mailing list over the past couple of months (mostly in
December, but continuing to the present - see
http://mail.python.org/pipermail/pyt...er/thread.html
as a starting point), which seem to have fizzled out or at least
haven't resolved much. The discussions made reference to work that has already been done to allow Python to be compiled with minGW:

pyMinGW is a patch to Python source that aims to get Python to compile under MinGW

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

I've not seen any commentary on the quality of this patch, so that
doesn't appear to be the reason it hasn't been officially adopted.
Reading all the threads from Python-Dev has not enlightened me at all
as to what the underlying reason is for not adopting these changes.
Maybe there are good reasons, I just couldn't find them, and I'm
usually pretty good with Google.

If passing all the regression tests of the official Windows Python
distribution is an indication of the quality of patch-- and pyMinGW
patched and MinGW built Python does pass all of them-- then one is
inclined to say that pyMinGW is a good patch.

The reason why it is, on the other hand, not included in the official
distribution is threefold.

1. Contrary to what many might imagine, I don't think enough people use
MinGW to frankly justify any extra effort beyond pyMinGW.
2. Given number 1 above, this patch, I believe, and I could be
mistaken, must not rush to be included in Python's core; people like
your esteemed person should test it (note that it is designed not to
interfere with your trusted and working official Python, if any); it is
only when enough people do such testing that there will be a case for
it to be included in Python's core.
3. Finally. there is nothing wrong with third-party patches if they get
the job done, which I believe is the case with pyMinGW.
Regards,
Khalid

[Fredrik Lundh]

"Pat" wrote:

Okay, I think we are pretty much talking about the same thing. My
problem is not that I'm unable or unwilling to purchase a good
compiler. My problem is that I don't want to make it a requirement of
my users. The twist is that my users will be working out of a
Subversion repository that includes source code for extensions written
in C. Those extensions need to be compiled, and the code changes too
frequently for me to want to deal with supplying compiled binaries.
here's what I do to supply compiled binaries for 2.1 through 2.4:
mkall
upload dist So I'm looking for options for Windows users who do not have, and are
unwilling to get, a Microsoft compiler. For some users, minGW is an
attractive option. For those who want to use minGW, I'm trying to
establish whether or not minGW is a viable option, particularly for
Python 2.4.

here's what I just did (time in minutes):

+00: googled for the mingw home page
+00: found the mingw download page
+02: finally figured out what to download
+03: noticed that my usual SF site only offered 1K/s; aborted download
+07: finished downloading the mingw kit from another SF site
+17: finished installing
+18: added \mingw\bin to the path
+18: typed "python setup.py install --compiler=mingw32"
+18: got a linker error; googled for help
+19: copied python24.dll to \mingw\lib
+20: finished building the sample library (cElementTree); all tests pass

so what's your excuse for not doing this? ;-)

</F>

[Fredrik Lundh]

"Pat" wrote:

If you are telling me that minGW can compile extensions that are
compatible with the Python 2.4 that uses msvcr71.dll, then that is good
news indeed. Is there anything that needs to be configured or patched
to make this happen? And how does minGW know which dll to link? What
if I have both versions of Python installed - 2.3.5 and 2.4? Is there
an easy way to detect this and switch between the two dlls?

just use the right Python to run the setup.py script, and distutils will take
care of the rest.

</F>

[Fredrik Lundh]

"Pat" wrote:

Having to tell users that they need to download, install, and configure
all this additional compiler stuff is asking too much from my potential
user base, since I'm also targeting novices and developers from other
languages for whom C compiler stuff is going to be a barrier to entry.

I hope that makes sense. :-)

telling them to download and configure subversion just to be able to use
your stuff doesn't make much sense, no.

(not that subversion is hard to install, though, but it's a lot harder than just
running a bdist installer).

</F>

[Fredrik Lundh]

Stephen Kellett wrote:

if I have both versions of Python installed - 2.3.5 and 2.4? Is there
an easy way to detect this and switch between the two dlls?
Easy? Depends what you call easy.

in the context of "building a C extension when you have multiple versions
installed", the answer is "easy". setup.py automatically finds the right DLL,
mingw seems take care of the rest.
a) You just need to detect if pythonNN.dll is implicitly linked to msvcrt.dll or msvcrXX.dll
(where XX indicates a VS studio number, currently XX can only be 71, but if Python is done for
Visual Studio 2005 (8.0) then XX may also have a value of 80).

b) GetModuleHandle(name of DLL from a) to get the DLL handle.

c) GetProcAddress on the respective to get the C runtime function you want to call (for example,
fopen).

d) call the function.

You either need (a) or all of (a)...(d) depending on what you are doing. Those embedding Python
but no idea of the Python version in advance will do the latter.

if someone needs code that does it all, check the exemaker sources:

http://effbot.org/zone/exemaker.htm

</F>

[Stephen Kellett]

In message <gj**************@objmedia.demon.co.uk>, Stephen Kellett
<sn***@objmedia.demon.co.uk> writes

In message <11*********************@l41g2000cwc.googlegroups. com>, Pat
<po*****@orbtech.com> writes

if I have both versions of Python installed - 2.3.5 and 2.4? Is there
an easy way to detect this and switch between the two dlls?

Easy? Depends what you call easy.

a) You just need to detect if pythonNN.dll is implicitly linked to
msvcrt.dll or msvcrXX.dll (where XX indicates a VS studio number,
currently XX can only be 71, but if Python is done for Visual Studio
2005 (8.0) then XX may also have a value of 80).

I should have also mentioned that if you don't know how to do get the
list of imported DLLs you can grab the source code for the PE Explorer
DLL from:

http://www.objmedia.demon.co.uk/free...peFileDLL.html

If you want to see how to use this DLL you can also grab:

http://www.objmedia.demon.co.uk/free...eExplorer.html

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html

[Stephen Kellett]

In message <11*********************@z14g2000cwz.googlegroups. com>, Pat
<po*****@orbtech.com> writes

What configuration hassle? Can't be any harder than specifying a
different CRT surely?

I don't want to have to ask users of my code to have to go through
this:

http://www.vrplumber.com/programming/mstoolkit/

OK. I misunderstood your original intent. I thought the original
question was can we redistribute this DLL? I answered this bit. I wasn't
attempting to answer the larger question about building extensions etc.
My development environment has all the things in that article by default
- I wouldn't even start work without them, so I had them "taken for
granted" in my thoughts. I can see your problem :-) but I have no easy
answer. Sorry.
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html