My only complaint about Python

[Graham Fawcett]

As a step towards this, it would be useful if it were
distributed with the libpythonXX.a that mingw requires
already built. Then it would just be a matter of giving
the appropriate flag to setup.py when compiling a module.

+1! Building libpythonXX.a isn't tremendously hard, but it's a pain.
Given the simplicity of mingw's installation (and distutils'
familiarity with it) this would definitely simplify extension building
on win32.

-- Graham

 

[Tim Peters]

[Darren Dale]
....
[Tim Peters]

We should be clear here that this isn't Guido's decision. What you
get on Windows is what you get on all other platforms in this respect:
you get what volunteers show up to produce, year after year after
year. So you get a fine Cygwin port from Jason Tishler, seemingly
toiling all alone, and you get contributions from at least four
developers who do use Visual Studio.

[Darren]
I meant no disrespect to the developers.

Didn't think you did. I'm just saying (a) the BDFL is irrelevant to
this particular issue; and, (b) you get what other people give. If
nobody with a long-term commitment to a specific Visual Studio
alternative appears, then #b rules.

...
This comes back to the heart of the matter. How do you get volunteers
who dont have access to VS to get involved with Python development?

Very few Python contributors have access to VS, but it doesn't matter
since most aren't running on Windows either. Even on Windows, VS is
usually irrelevant to whether somene can pitch in on reviewing bugs
and patches, improving the standard libraries, improving the docs,
helping on the newsgroup and mailing lists, keeping python.org
healthy, etc. I think it's more of a cultural thing, that Windows
users typically have a lower contribution rate than users on other
platforms (whether it's C code or anything else).

I mentioned Cygwin before, and you can certainly develop C extension
modules, for Python, on Windows, using that. Other responders have
their own favored VS alternatives. "A problem" is that there's more
than one VS alternative! That fragments the relatively-small-anyway
community of people who need a VS alternative on Windows.

I think the suggestions here were right on, give Python the ability to
support MinGW out of the box.

That's a wish. If it's to be granted, someone has to volunteer to do
the work initially, and keep it working as the years go by. Don't
expect that one of the current contributors will do so (they're
swamped already). IOW, it's not a matter of convincing someone it's a
good idea, it's a matter of someone volunteering to do actual, real
work.

I thought that a compiler could even be included in a version of the Windows
distribution, but maybe that is taking it too far.

That one won't happen -- most Windows Python users don't even know C,
and download size is still an issue for many. Even people who want to
work on core Python development on Windows using VS need to work from
a source tarball instead, or from a CVS checkout.

 

[Istvan Albert]

Ralf Schmitt wrote:

You can build modules using msys/mingw. Instructions can be found at
http://sebsauvage.net/python/mingw.html

works out great! I didn't even need to do step 3 (tweaking distutils).

thanks for the pointer.

Istvan.

 

[Jeff Shannon]

all humbug. Visual C++ is nowhere near free, it's all proprietary.

That's free-as-in-beer, not Free-as-in-speech.

It's a shame that, at least in English, the most natural word to use for
each of these two different concepts just happens to be the same word.
But such is the case. (I don't think it's practical to try to convince
everyone, worldwide, to refer to it as 'gratis' and 'liberte'...) And
given that it *is* the case, it would be much more pleasant if people
could use the word for both of its meanings without being criticized by
people who are philosophically devoted to only one of those meanings.

Jeff Shannon
Technician/Programmer
Credit International

 

[Tim Daneliuk]

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

They do. MSC/C++ is now available at NO cost:

http://msdn.microsoft.com/visualc/vctoolkit2003/

 

[510046470588-0001]

They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Klaus Schilling

 

[Miklós]

That's free-as-in-beer, not Free-as-in-speech.

It's a shame that, at least in English, the most natural word to use for
each of these two different concepts just happens to be the same word.
But such is the case. (I don't think it's practical to try to convince
everyone, worldwide, to refer to it as 'gratis' and 'liberte'...) And
given that it *is* the case, it would be much more pleasant if people
could use the word for both of its meanings without being criticized by
people who are philosophically devoted to only one of those meanings.

It makes me smile that you keep getting into such semantic troubles unless
you express yourself in such a roundabout way.
I think it would be a really wise thing to always use the word 'gratis' for
'free-as-in-beer'.

Btw, my native language (Hungarian) avoids another serious semantic
booby-trap in English, with the ambigous word "love"... But at least in
c.l.p.
this rarely makes confusion.

Miklós

 

[Andrea Griffini]

no cost is not the same as free

Do you mean that there are limitations about legal use of
VC toolkit 2003 for building a python interpreter or that
you actually need to see the source code of the C compiler
to build python ?

Andrea

 

[Tim Daneliuk]

no cost is not the same as free

Klaus Schilling

<Goes Off The Reservation For A Moment>

"No Cost" is _exactly_ the same thing as "Free". It is not the same
thing as "Open Source".

The debate is foolish in any case. If I use an GPLed compiler, even with
the Lesser License, I have constraints placed upon what I may or may
not do with the derivative work. If I use a commercial compiler, I do
not have access to the source code _for the compiler_, but (usually)
there are no constraints placed upon what I may do with the derivative
work.

This whole mentality of "it must be 'free' or it's bad" is very silly
and at odds with how the world actually operates (aka Reality). I use
both freely available open source tools and commercial tools (that I've
paid for and licensed legitimately). Each has a place. One is not
inherently better than another.

The "freeness" of a particular product is only one of a number of
dimensions I examine when making tool choices for myself or my clients.
"Open Source" is often irrelevant to people - how many people actually
want to examine and modify the guts of compiler? Far more important than
the cost of acquistion is the _cost of ownership_. This is influenced
by a lot of things:

1) Training
2) Maintenance
3) Stability/Quality
4) Documentation
5) 3rd-Party support

IOW, I couldn't care less if something is "free", "freely available",
"open source", "closed source", or "commercial" software. I care about
whether it solves the problem at hand in a time- and cost-effective manner.

Unfortunately, Stallman and his ilk - for all their many contributions to
our field - have polluted the discussion with their hare-brained political
notions, naive ideas about intellectual property, and incessant whining
that everyone _else_ should "share" they way they define the term. I tire
of it as you may be able to tell from this short rant ...

Pax ...

</Back On The Reservation>

 

[Christophe Cavalaria]

<Goes Off The Reservation For A Moment>

"No Cost" is _exactly_ the same thing as "Free". It is not the same
thing as "Open Source".

The debate is foolish in any case. If I use an GPLed compiler, even with
the Lesser License, I have constraints placed upon what I may or may
not do with the derivative work. If I use a commercial compiler, I do
not have access to the source code _for the compiler_, but (usually)
there are no constraints placed upon what I may do with the derivative
work.

This is wrong on so many levels :
- gcc is GPL software and you don't have to GPL the source code of the
programs you compile with it. Doing so would place a restriction on the
user of the software which is exactly what the GPL is trying to prevent.
Using gcc to compile source code isn't creating a derivative work of gcc !
- if you modify the gcc source code and thus create a derivative work, you
don't have to distribute the changes, unless you distribute the new gcc
version.
- with a commercial closed source compiler, you can't do any derivative of
the compiler at all and thus you have less freedom than with a GPL
compiler.

If you can't see the difference between using a software and creating a
derivative work of that software ...

 

[Tim Daneliuk]

Tim Daneliuk wrote:




This is wrong on so many levels :
- gcc is GPL software and you don't have to GPL the source code of the
programs you compile with it. Doing so would place a restriction on the
user of the software which is exactly what the GPL is trying to prevent.
Using gcc to compile source code isn't creating a derivative work of gcc !
- if you modify the gcc source code and thus create a derivative work, you
don't have to distribute the changes, unless you distribute the new gcc
version.
- with a commercial closed source compiler, you can't do any derivative of
the compiler at all and thus you have less freedom than with a GPL
compiler.

If you can't see the difference between using a software and creating a
derivative work of that software ...

It is "derivative" in the sense that the final binary may either contain
and/or depend upon library support shipped with the gcc compiler chain.
IIRC (and this may have changed - I have not looked at it in some time),
even the Lesser GPL places some constraints about what you _must_ distribute
(or be willing to provide) when you use their libs to produce a shipped product.
Moreover, for a long time (and this too may have changed), the corporate
lawyers I had checking the GPL did not like it because it was (legally)
muddy.

The only sense in which you have "less freedom" with a commercial product
is that you cannot build works that derive directly from the compiler/library
source code. So what? In most real world commercial applications, this is
a non-issue. Note that I was clear that I use _both_ OSS and Commercial products.
My rant is directed at people who thing Proprietary=Evil and OSS=Good which is
a nonsensical position.

 

[Robert Kern]

Tim Daneliuk wrote:

[snip]

It is "derivative" in the sense that the final binary may either contain
and/or depend upon library support shipped with the gcc compiler chain.

Yes, the final binary *may* depend on any number of libraries either
distributed with gcc or completely independent from gcc. The license of
those libraries have an effect on your program. The license of gcc does
not. gcc does not have to use glibc as the standard C library. For
example, the cygwin distribution of gcc uses their own newlib
(GPL+exception, I believe) and mingw uses Microsoft's MSVCRT. gcc can
also target the native libc on other systems. Or, if you provide your
own C runtime or do not need one, then there are no license problems.

I repeat, it is the license of the libraries that affects your program,
not the license of gcc.

IIRC (and this may have changed - I have not looked at it in some time),
even the Lesser GPL places some constraints about what you _must_
distribute
(or be willing to provide) when you use their libs to produce a shipped
product.

So can the licenses, proprietary or otherwise, of any other library any
compiler might link to.

--
Robert Kern
(e-mail address removed)

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

 

[Bengt Richter]

[Darren Dale]
...
[Tim Peters]

We should be clear here that this isn't Guido's decision. What you
get on Windows is what you get on all other platforms in this respect:
you get what volunteers show up to produce, year after year after
year. So you get a fine Cygwin port from Jason Tishler, seemingly
toiling all alone, and you get contributions from at least four
developers who do use Visual Studio.

[Darren]
I meant no disrespect to the developers.

Didn't think you did. I'm just saying (a) the BDFL is irrelevant to
this particular issue; and, (b) you get what other people give. If
nobody with a long-term commitment to a specific Visual Studio
alternative appears, then #b rules.

...
This comes back to the heart of the matter. How do you get volunteers
who dont have access to VS to get involved with Python development?

Very few Python contributors have access to VS, but it doesn't matter
since most aren't running on Windows either. Even on Windows, VS is
usually irrelevant to whether somene can pitch in on reviewing bugs
and patches, improving the standard libraries, improving the docs,
helping on the newsgroup and mailing lists, keeping python.org
healthy, etc. I think it's more of a cultural thing, that Windows
users typically have a lower contribution rate than users on other
platforms (whether it's C code or anything else).

I mentioned Cygwin before, and you can certainly develop C extension
modules, for Python, on Windows, using that. Other responders have
their own favored VS alternatives. "A problem" is that there's more
than one VS alternative! That fragments the relatively-small-anyway
community of people who need a VS alternative on Windows.

I think the suggestions here were right on, give Python the ability to
support MinGW out of the box.

That's a wish. If it's to be granted, someone has to volunteer to do
the work initially, and keep it working as the years go by. Don't
expect that one of the current contributors will do so (they're
swamped already). IOW, it's not a matter of convincing someone it's a
good idea, it's a matter of someone volunteering to do actual, real
work.

I thought that a compiler could even be included in a version of the Windows
distribution, but maybe that is taking it too far.

That one won't happen -- most Windows Python users don't even know C,
and download size is still an issue for many. Even people who want to
work on core Python development on Windows using VS need to work from
a source tarball instead, or from a CVS checkout.

Has anyone considered treating a current binary windows cpython distro like 2.3 as
a bootstrap, using a python script to control (e.g. via os and urllib etc) all the downloading
and md5/pgp-sig checking and building necessary to create an msys/MinGW installation
(as needed if not present) and then a python built from sources purely using msys/MinGW,
with end result being a python installation ready to be used in parallel, or to be switched
to as default?

It might take hours to download and crunch, and it might need to be re-startable
and be based on an evolving checkpointable config file of preferences etc, but why not?

If someone then wanted to make a script repackaging the result as a binary installation,
that would be handy too, and IWT some official versions of everything would wind up on python.org
after a while.

IMO a python script that created the whole thing from sources (well, ok, not including bootstrapping
msys/MingGW totally from sources ;-) would be a useful DOCUMENT as well as a tool. IOW, spreading
bot-knowledge can distribute the knowledge necessary to distributing the volunteer workload of
maintaining and improving the thing. I'm thinking simple text UI control as necessary.

Such a migration bootstrap script seems to me like it would have more robust survival prospects than
an equivalent-end-result prebuilt binary distro made ad hoc by hand and contributed.

Seems like someone must have thought of this before. I guess pieces exist as .bat or .cmd files,
but I'd like to see the whole thing wrapped in a single flexible python script.

Regards,
Bengt Richter

 

[David Fraser]

Do you mean that there are limitations about legal use of
VC toolkit 2003 for building a python interpreter or that
you actually need to see the source code of the C compiler
to build python ?

There are other benefits to open source compilers - in gcc's case, a
specific advantage is that it can cross-compile from other operating
systems. In certain circumstances that can be a big advantage

David