pygame and python 2.5

[siggi]

@Ben Sizer

Hi Ben,

in January I received your message re Pygame and Python 2.5:

>pygame and python 2.5
Ben Sizer kylotan at gmail.com
Fri Jan 12 11:01:00 CET 2007
--------------------------------------------------------------------------------

siggi wrote:

>when I rtry to install pygame (pygame-1.7.1release.win32-py2.4.exe, the
most
ciurrent version I found) it requires Python 2.4! Will I really have to
uninstall my Python 2.5 and install the old Python 2.4 in order to use
pygame?

For now, yes. This is a long-standing problem with Python really,
requiring extensions to always be recompiled for newer versions. I
usually have to wait about 6 months to a year after any new release
before I can actually install it, due to the extension lag.

--
Ben Sizer

As a Python (and programming ) newbie allow me a - certainly naive -
question:

What is this time consuming part of recompiling an extension, such as
Pygame, from source code to Windows? Is it a matter of spare time to do the
job? Or do you have to wait for some Windows modules that are necessary for
compiling?

I am just asking for sake of "scientific" interest; building, compiling
from source code is a mystery to me poor Windows user ;-)

Thank you,

siggi

[Ben Sizer]

On Feb 9, 1:48 pm, "siggi" <[e-mail]:

@Ben Sizer

Lucky I spotted this...

As a Python (and programming ) newbie allow me a - certainly naive -
question:

What is this time consuming part of recompiling an extension, such as
Pygame, from source code to Windows? Is it a matter of spare time to do the
job? Or do you have to wait for some Windows modules that are necessary for
compiling?

The problem is something like this:
- Python extensions written in C require recompilation for each new
version of Python, due to Python limitations.
- Recompiling such an extension requires you to have a C compiler set
up on your local machine.
- Windows doesn't come with a C compiler, so you have to download
one.
- The compiler that Python expects you to use (Visual Studio 2003) is
no longer legally available.
- The other compiler that you can use (MinGW) is requires a slightly
convoluted set of steps in order to build an extension.

Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.

--
Ben Sizer

[skip]

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

Skip

[John Nagle]

Ben Sizer wrote:

The problem is something like this:
- Python extensions written in C require recompilation for each new
version of Python, due to Python limitations.
- Recompiling such an extension requires you to have a C compiler set
up on your local machine.
- Windows doesn't come with a C compiler, so you have to download
one.
- The compiler that Python expects you to use (Visual Studio 2003) is
no longer legally available.
- The other compiler that you can use (MinGW) is requires a slightly
convoluted set of steps in order to build an extension.

Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.

True. There really should be no need to recompile a C extension unless
the linkage format of the C compiler changes, which is a very rare event.
Binary compatibility needs to be improved.

In the GCC world, any compiler since 3.2 should generate interchangeable
output.

http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html

In the Windows world, I'm not sure about compatibility across the
VC6/.NET transition, but I think you only need one version for either
side of that one.

John Nagle

[Mike C. Fletcher]

sk**@pobox.com wrote:

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

Sure, write your wrapper-style extensions in ctypes :) . For example,
pygame-ctypes[1] should work on Python 2.5. Of course, you need to get
the PyGame dependencies (SDL) installed via some external mechanism, but
the ctypes-based code should run in Python 2.5 today (with the caveat
that it's not finished software).

[1] http://www.pygame.org/ctypes/

Have fun,
Mike

--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com

[skip]

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

>Can you propose a means to eliminate this limitation?

MikeSure, write your wrapper-style extensions in ctypes :).

I was think more along the lines of how could the Python extension module
API change so that for example, modules compiled for Python 2.6 would
continue to work without warning under Python 2.7. Maybe ctypes is the
answer, but suspect it addresses a different API than I was thinking of.

Skip

[Ben Sizer]

On Feb 9, 5:53 pm, [e-mail] wrote:

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

By putting an intermediate layer between the extensions and the
language. I suppose this is essentially what ctypes does, except from
the other direction.

If someone could explain the limitation in detail, I expect ways could
be found around it. After all, I don't know of any other systems that
require you to recompile all the extensions when you upgrade the
application.

Winamp is one application that comes to mind which has kept plugins
working across many upgrades. I doubt they're still compiling with
Visual Studio 6. Perhaps it works because they have a more restrictive
API that isn't passing non-primitive types across the DLL boundary.

--
Ben Sizer

[skip]

BenIf someone could explain the limitation in detail, I expect ways
Bencould be found around it. After all, I don't know of any other
Bensystems that require you to recompile all the extensions when you
Benupgrade the application.

Python used to work that way. You'd then silently get errors if the API
changed between version A and version B and you neglected to recompile the
extensions you compiled against version A. Maybe the Python extension API
is mature enough now that it can be frozen, but I sort of doubt it.

Skip

[bearophileHUGS]

Skip:

Python used to work that way. You'd then silently get errors if the API
changed between version A and version B and you neglected to recompile the
extensions you compiled against version A.

Can't the compiled module have one or more test functions that can be
used during linking to see if the compiled module respects the
expected standard?

Bye,
bearophile

[Ben Sizer]

On Feb 9, 9:01 pm, [e-mail] wrote:

BenIf someone could explain the limitation in detail, I expect ways
Bencould be found around it. After all, I don't know of any other
Bensystems that require you to recompile all the extensions when you
Benupgrade the application.

Python used to work that way. You'd then silently get errors if the API
changed between version A and version B and you neglected to recompile the
extensions you compiled against version A. Maybe the Python extension API
is mature enough now that it can be frozen, but I sort of doubt it.

The only reason this is an issue is because the system is tightly
bound on a binary level. Decouple that and the problem goes away.
These 'silent' errors will all stem from a small number of specific
things, each of which can be addressed. eg. PyFile_AsFile returns a
FILE*, which is all well and good if both the extension's compiler and
the language's compiler agree on what you get when you dereference
that type, and probably not so good when they don't. The answer there
is not to make assumptions about the structure of complex types across
the boundary. The same may well go for the multitude of macros that
make assumptions about the structure of a PyObject.

It's not really much to do with the maturity, since functions don't
seem to be getting regularly removed from the API. It's more the
choices made about how to implement it.

--
Ben Sizer

[Hendrik van Rooyen]

<sk**@pobox.comwrote:
"Ben Sizer" <ky*****@gmail.comwrote:

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

Yes. - Instead of calling something, send it a message...

- Hendrik

[mensanator]

On Feb 9, 11:39�am, "Ben Sizer" <[e-mail]:

On Feb 9, 1:48 pm, "siggi" <[e-mail]:

@Ben Sizer

Lucky I spotted this...

As a Python (and programming ) newbie *allow me a *- certainly naive -
question:

What is this time consuming part of recompiling an extension, such as
Pygame, from source code to Windows? Is it a matter of spare time to dothe
job? Or do you have to wait for some Windows modules that are necessaryfor
compiling?

The problem is something like this:
*- Python extensions written in C require recompilation for each new
version of Python, due to Python limitations.
*- Recompiling such an extension requires you to have a C compiler set
up on your local machine.
*- Windows doesn't come with a C compiler, so you have to download
one.
*- The compiler that Python expects you to use (Visual Studio 2003) is
no longer legally available.
*- The other compiler that you can use (MinGW) is requires a slightly
convoluted set of steps in order to build an extension.

Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.

So you're saying the knowledgeable people's attitude
is "fuck everyone else as lomg as it's not MY problem"?

And you people complain about Microsoft.

>
--
Ben Sizer

[Siggi]

"Ben Sizer" wrote:
[snip]

Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.

--
Ben Sizer

Thank you, and all those putting in their comments to my thread.
As a python newbie, I conclude now that I will be better off to drop
Windows and install Linux on my next PC, to be able to reap the full
benefits of Python.

Thanks,

siggi

[Steve Holden]

Hendrik van Rooyen wrote:

<sk**@pobox.comwrote:
"Ben Sizer" <ky*****@gmail.comwrote:

> BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

Yes. - Instead of calling something, send it a message...

I suppose you are proposing to use the ISO 19999.333 generic
message-passing interface for this? The one that doesn't actually call a
function to pass a message?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[skip]

>Python used to work that way. You'd then silently get errors if the
API changed between version A and version B and you neglected to
recompile the extensions you compiled against version A.

bearophileCan't the compiled module have one or more test functions
bearophilethat can be used during linking to see if the compiled
bearophilemodule respects the expected standard?

Given the complexity of the formal API how would you test to see if the
extension violated a particular aspect of the API? What if one of the API
bits used is implemented as a C macro (as parts are) and it was changed
simply to fix a bug. Wouldn't you want to know with a high degree of
certainty that you should recompile? How would a test function tell you
that? A simple API versioning scheme does that. It means you have to
recompile when a new version of Python comes out. In fact, you can think of
it as the test function you suggest. It's just that it's noted at the time
a module is imported, not strictly speaking at link time. It tells you,
"Hey buddy. You're using an outdated version of the API." What it can't
tell you is if the parts of the API your particular module uses are used
incorrectly.

Skip

[skip]

Siggi... I conclude now that I will be better off to drop Windows and
Siggiinstall Linux on my next PC, to be able to reap the full benefits
Siggiof Python.

Darn tootin'... (*)

Skip

(*) http://en.wikipedia.org/wiki/You're_Darn_Tootin'

[Ben Sizer]

On Feb 10, 6:31 am, "[e-mail]" <[e-mail]:

On Feb 9, 11:39?am, "Ben Sizer" <[e-mail]:

Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.

So you're saying the knowledgeable people's attitude
is "fuck everyone else as lomg as it's not MY problem"?

And you people complain about Microsoft.

Am I one of "those people"? You don't exactly make it clear.

But yes, there is a lot of "well, it works for me" going around. If
you do that long enough, people stop complaining, so people wrongly
assume there's no longer a problem. This is partly why Python has
various warts on Windows and why the standard libraries are oddly
biased, why configuring Linux almost always ends up involving hand-
editing a .conf file, why the leading cross-platform multimedia
library SDL still doesn't do hardware graphics acceleration a decade
after such hardware became mainstream, and so on.

However, the difference between the open-source people and Microsoft
is the the open-source people aren't being paid by you for the use of
their product, so they're not obligated in any way to help you. After
all, they have already given freely and generously, and if they choose
not to give more on top of that, it's really up to them. Yes, it's
occasionally very frustrating to the rest of us, but that's life. The
best I feel I can do is raise these things on occasion, on the off-
chance that I manage to catch the attention of someone who is
altruistic, knowledgeable, and who has some spare time on their hands!

--
Ben Sizer

[Ben Sizer]

On Feb 10, 8:42 am, Steve Holden <[e-mail]:

Hendrik van Rooyen wrote:

<[e-mail]:
"Ben Sizer" <[e-mail]:

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

Yes. - Instead of calling something, send it a message...

I suppose you are proposing to use the ISO 19999.333 generic
message-passing interface for this? The one that doesn't actually call a
function to pass a message?

I'm assuming you're being facetious here..?

Of course, functions get called at the ends of the message passing
process, but those functions can stay the same across versions while
the messages themselves change. The important part is reducing the
binary interface between the two sides to a level where it's trivial
to guarantee that part of the equation is safe.

eg.
Instead of having PySomeType_FromLong(long value) exposed to the API,
you could have a PyAnyObject_FromLong(long value, char*
object_type_name). That function can return NULL and set up an
exception if it doesn't understand the object you asked for, so Python
versions earlier than the one that implement the type you want will
just raise an exception gracefully rather than not linking.

The other issue comes with interfaces that are fragile by definition -
eg. instead of returning a FILE* from Python to the extension, return
the file descriptor and create the FILE* on the extension side with
fdopen.

--
Ben Sizer

[mensanator]

On Feb 10, 4:07?pm, "Ben Sizer" <[e-mail]:

On Feb 10, 6:31 am, "[e-mail]" <[e-mail]:

On Feb 9, 11:39?am, "Ben Sizer" <[e-mail]:

Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.

So you're saying the knowledgeable people's attitude
is "fuck everyone else as lomg as it's not MY problem"?

And you people complain about Microsoft.

Am I one of "those people"? You don't exactly make it clear.

I'm talking about the people who complain about Microsoft
making the VC6 compiler no longer legally available and
yet are so irresponsible that they use it for the latest
release.

>
But yes, there is a lot of "well, it works for me" going around. If
you do that long enough, people stop complaining, so people wrongly
assume there's no longer a problem. This is partly why Python has
various warts on Windows and why the standard libraries are oddly
biased, why configuring Linux almost always ends up involving hand-
editing a .conf file, why the leading cross-platform multimedia
library SDL still doesn't do hardware graphics acceleration a decade
after such hardware became mainstream, and so on.

However, the difference between the open-source people and Microsoft
is the the open-source people aren't being paid by you for the use of
their product, so they're not obligated in any way to help you.

This argument has become tiresome. The Python community
wants Python to be a big fish in the big pond. That's why
they make Windows binaries available.

After all, they have already given freely and generously, and if they choose
not to give more on top of that, it's really up to them.

Right. Get people to commit and then abandon them. Nice.

Yes, it's
occasionally very frustrating to the rest of us, but that's life.

As the Kurds are well aware.

The best I feel I can do is raise these things on occasion,
on the off-chance that I manage to catch the attention of
someone who is
altruistic, knowledgeable, and who has some spare time on
their hands!

Someone who, say, solved the memory leak in the GMPY
divm() function even though he had no way of compiling
the source code?

Just think of what such an altruistic, knowedgeable
person could do if he could use the current VC compiler
or some other legally available compiler.

>
--
Ben Sizer

[skip]

>However, the difference between the open-source people and Microsoft
is the the open-source people aren't being paid by you for the use of
their product, so they're not obligated in any way to help you.

mensanatorThis argument has become tiresome. The Python community
mensanatorwants Python to be a big fish in the big pond. That's why
mensanatorthey make Windows binaries available.

I suspect the main reason Windows binaries are produced is because a)
Microsoft doesn't ship Python installed on Windows, and b) your garden
variety Windows user doesn't have the tools necessary to build Python from
source. Not being a Windows user myself I don't understand all the ins and
outs of VC6 v. VC7, legal or technical. Is there nothing Microsoft could
have done to make VC7 compatible with the existing VC6-based build
procedure?

Skip

[mensanator]

On Feb 10, 11:03�pm, [e-mail] wrote:

* * >However, the difference between the open-source people and Microsoft
* * >is the the open-source people aren't being paid by you for theuse of
* * >their product, so they're not obligated in any way to help you.

* * mensanatorThis argument has become tiresome. The Python community
* * mensanatorwants Python to be a big fish in the big pond. That'swhy
* * mensanatorthey make Windows binaries available.

I suspect the main reason Windows binaries are produced is because a)
Microsoft doesn't ship Python installed on Windows, and b) your garden
variety Windows user doesn't have the tools necessary to build Python from
source. *
Not being a Windows user myself I don't understand all the ins and
outs of VC6 v. VC7, legal or technical. *Is there nothing Microsoft could
have done to make VC7 compatible with the existing VC6-based build
procedure?

Ya got me, I'm not a softeware developer, I'm an
amateur math researcher. I don't know the ins and
outs either.

>
Skip

[Hendrik van Rooyen]

"Steve Holden" <st***@holdenweb.com>

Hendrik van Rooyen wrote:

<sk**@pobox.comwrote:
"Ben Sizer" <ky*****@gmail.comwrote:

BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.

Can you propose a means to eliminate this limitation?

Yes. - Instead of calling something, send it a message...

I suppose you are proposing to use the ISO 19999.333 generic
message-passing interface for this? The one that doesn't actually call a
function to pass a message?

Actually I am not aware that this ISO standard exists.

My feeling about ISO standards in general are such that
I would rather have *anything* else than an ISO standard.
These feelings are mainly caused by the frustration of trying
to decipher standards written in standardese, liberally sprinkled
with non standard acronyms...

Its very interesting to learn that you can pass a message without
doing a call - when I next need to entertain a children's party as a
magician I will endeavour to incorporate it into my act. Thanks
for the tip.

But more seriously, the concept is that you should couple
as loosely as possible, to prevent exactly the kind of trouble
that this thread talks about. Just as keyword parameters are
more robust than positional parameters, the concept of doing
something similar to putting a dict on a queue, is vastly more
future-proof than hoping that your call will *get through*
when tomorrow's compiler buggers around with the calling
convention.

One tends to forget that calling also builds messages on
the stack.

When you boil it right down, all you need for a minimalistic
interface are four message types:

- get something's value
- set something to a value
- return the requested value
- do something

This is not the most minimalistic interface, but its a nice
compromise.

The advantages of such loose coupling are quite obvious when
you think about them, as you don't care where the worker sits -
on the other side of the world over the internet, or in the same
room in another box, or in the same box on another processor,
or on the same processor in another process, or in the same
process in another thread...

The problem with all this, of course, is the message passing
mechanism, as it is not trivial to implement something that
will address all the cases. A layered approach (ISO ? ; - ) )
could do it...

But Skip asked how to sort it, and this would be
My Way. (TM circa 1960 F Sinatra)

- Hendrik

[Steve Holden]

Ben Sizer wrote:

On Feb 10, 8:42 am, Steve Holden <[e-mail]:

>Hendrik van Rooyen wrote:

>><[e-mail]:
"Ben Sizer" <[e-mail]:
BenPython extensions written in C require recompilation for each new
Benversion of Python, due to Python limitations.
Can you propose a means to eliminate this limitation?
Yes. - Instead of calling something, send it a message...

I suppose you are proposing to use the ISO 19999.333 generic
message-passing interface for this? The one that doesn't actually call a
function to pass a message?

I'm assuming you're being facetious here..?

You're right.

Of course, functions get called at the ends of the message passing
process, but those functions can stay the same across versions while
the messages themselves change. The important part is reducing the
binary interface between the two sides to a level where it's trivial
to guarantee that part of the equation is safe.

eg.
Instead of having PySomeType_FromLong(long value) exposed to the API,
you could have a PyAnyObject_FromLong(long value, char*
object_type_name). That function can return NULL and set up an
exception if it doesn't understand the object you asked for, so Python
versions earlier than the one that implement the type you want will
just raise an exception gracefully rather than not linking.

The other issue comes with interfaces that are fragile by definition -
eg. instead of returning a FILE* from Python to the extension, return
the file descriptor and create the FILE* on the extension side with
fdopen.

I agree that the coupling is rather tight at the moment and could do
with being loosened to the degree you suggest.

My previous post was a knee-jerk reaction to the suggestion that
substituting one mechanism for another equivalent one would, by itself,
solve anything.

I am staying away from the Py3.0 discussions at the moment - does
anybody know whether this problem is being addresses there?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[Steve Holden]

me********@aol.com wrote:

On Feb 10, 4:07?pm, "Ben Sizer" <[e-mail]:

>On Feb 10, 6:31 am, "[e-mail]" <[e-mail]:

>>On Feb 9, 11:39?am, "Ben Sizer" <[e-mail]:
Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.
So you're saying the knowledgeable people's attitude
is "fuck everyone else as lomg as it's not MY problem"?
And you people complain about Microsoft.

Am I one of "those people"? You don't exactly make it clear.

I'm talking about the people who complain about Microsoft
making the VC6 compiler no longer legally available and
yet are so irresponsible that they use it for the latest
release.

I think you'll find those two sets are disjoint.

>But yes, there is a lot of "well, it works for me" going around. If
you do that long enough, people stop complaining, so people wrongly
assume there's no longer a problem. This is partly why Python has
various warts on Windows and why the standard libraries are oddly
biased, why configuring Linux almost always ends up involving hand-
editing a .conf file, why the leading cross-platform multimedia
library SDL still doesn't do hardware graphics acceleration a decade
after such hardware became mainstream, and so on.

However, the difference between the open-source people and Microsoft
is the the open-source people aren't being paid by you for the use of
their product, so they're not obligated in any way to help you.

This argument has become tiresome. The Python community
wants Python to be a big fish in the big pond. That's why
they make Windows binaries available.

? I would suggest rather that "the Python community" (by which you
apparently mean the developers) hope that the fruits of their labours
will be used by as wide a cross-section of computer users as possible.

The goals of open source projects are not those of commercial product
developers: I and others wouldn't collectively put in thousands of
unpaid hours a year to make a commercial product better and protect its
intellectual property, for example.

>After all, they have already given freely and generously, and if they choose
not to give more on top of that, it's really up to them.

Right. Get people to commit and then abandon them. Nice.

Anyone who committed to Python did so without being battered by a
multi-million dollar advertising campaign. The Python Software
Foundation has only recently dipped its toes in the advocacy waters,
with results that are still under evaluation. And the use of the
Microsoft "free" VC6 SDK was never a part of the "official" means of
producing Python or its extensions, it was a community-developed
solution to the lack of availability of a free VS-compatible compilation
system for extension modules.

I agree that there are frustrations involved with maintaining extension
modules on the Windows platform without having a copy of Visual Studio
(of the correct version) available. One of the reasons Python still uses
an outdated version of VS is to avoid forcing people to upgrade. Any
such decision will have fallout. An update is in the works for those
using more recent releases, but that won't help users who don't have
access to Visual Studio.

>Yes, it's
occasionally very frustrating to the rest of us, but that's life.

As the Kurds are well aware.

I really don't think you help your argument by trying to draw parallels
between the problems of compiler non-availability and those of a
population subject to random genocide. Try to keep things in
perspective, please.

>The best I feel I can do is raise these things on occasion,
on the off-chance that I manage to catch the attention of
someone who is
altruistic, knowledgeable, and who has some spare time on
their hands!

Someone who, say, solved the memory leak in the GMPY
divm() function even though he had no way of compiling
the source code?

Just think of what such an altruistic, knowedgeable
person could do if he could use the current VC compiler
or some other legally available compiler.

Your efforts would probably be far better spent trying to build a
back-end for mingw or some similar system into Python's development
system, to allow Python for Windows to be built on a regular rather than
a one-off basis using a completely open source tool chain.

The fact that the current maintainers of the Windows side of Python
choose to use a commercial tool to help them isn't something I am going
to try and second-guess. To do so would be to belittle efforts I would
have no way of duplicating myself, and I have far too much respect for
those efforts to do so.

There are published ways to build extension modules for Windows using
mingw, by the way - have you tried any of them? It's much harder than
sniping on a newsgroup, but you earn rather more kudos.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[Hendrik van Rooyen]

"Ben Sizer" <ky*****@gmail.comwrote:

On Feb 10, 8:42 am, Steve Holden <[e-mail]:

Hendrik van Rooyen wrote:

<[e-mail]:
"Ben Sizer" <[e-mail]:

> BenPython extensions written in C require recompilation for each

new

> Benversion of Python, due to Python limitations.

>Can you propose a means to eliminate this limitation?

Yes. - Instead of calling something, send it a message...

I suppose you are proposing to use the ISO 19999.333 generic
message-passing interface for this? The one that doesn't actually call a
function to pass a message?

I'm assuming you're being facetious here..?

Please see my reply to Steve - and Yes, I believe he was oulling the oiss...

>
Of course, functions get called at the ends of the message passing
process, but those functions can stay the same across versions while
the messages themselves change. The important part is reducing the
binary interface between the two sides to a level where it's trivial
to guarantee that part of the equation is safe.

eg.
Instead of having PySomeType_FromLong(long value) exposed to the API,
you could have a PyAnyObject_FromLong(long value, char*
object_type_name). That function can return NULL and set up an
exception if it doesn't understand the object you asked for, so Python
versions earlier than the one that implement the type you want will
just raise an exception gracefully rather than not linking.

The other issue comes with interfaces that are fragile by definition -
eg. instead of returning a FILE* from Python to the extension, return
the file descriptor and create the FILE* on the extension side with
fdopen.

This sort of thing is exactly what is wrong with the whole concept of
an API...
Its very difficult, if not impossible, to guarantee that *my stuff* and
*your stuff* will work together over time.

Whereas if *my stuff* just publishes a message format, *anything* that
can make up the message can interact with it - but it requires *my stuff*
to be independently executable, and it needs a message passing
mechanism that will stand the test of time.

And it can create a whole new market of "Mini Appliances" each of
which has *your stuff* inside them...

- Hendrik

[mensanator]

On Feb 11, 1:35�am, Steve Holden <[e-mail]:

[e-mail] wrote:

On Feb 10, 4:07?pm, "Ben Sizer" <[e-mail]:

On Feb 10, 6:31 am, "[e-mail]" <[e-mail]:

>On Feb 9, 11:39?am, "Ben Sizer" <[e-mail]:
Hopefully in the future, some of those convoluted steps will be fixed,
but that requires someone putting in the effort to do so. As is often
the case with Python, and indeed many open source projects, the people
who are knowledgeable enough to do such things usually don't need to
do them, as their setup already works just fine.
So you're saying the knowledgeable people's attitude
is "fuck everyone else as lomg as it's not MY problem"?
And you people complain about Microsoft.
Am I one of "those people"? You don't exactly make it clear.

I'm talking about the people who complain about Microsoft
making the VC6 compiler no longer legally available and
yet are so irresponsible that they use it for the latest
release.

I think you'll find those two sets are disjoint.

But yes, there is a lot of "well, it works for me" going around. If
you do that long enough, people stop complaining, so people wrongly
assume there's no longer a problem. This is partly why Python has
various warts on Windows and why the standard libraries are oddly
biased, why configuring Linux almost always ends up involving hand-
editing a .conf file, why the leading cross-platform multimedia
library SDL still doesn't do hardware graphics acceleration a decade
after such hardware became mainstream, and so on.

However, the difference between the open-source people and Microsoft
is the the open-source people aren't being paid by you for the use of
their product, so they're not obligated in any way to help you.

This argument has become tiresome. The Python community
wants Python to be a big fish in the big pond. That's why
they make Windows binaries available.

? I would suggest rather that "the Python community" (by which you
apparently mean the developers) hope that the fruits of their labours
will be used by as wide a cross-section of computer users as possible.

The goals of open source projects are not those of commercial product
developers: I and others wouldn't collectively put in thousands of
unpaid hours a year to make a commercial product better and protect its
intellectual property, for example.

After all, they have already given freely and generously, and if they choose
not to give more on top of that, it's really up to them.

Right. Get people to commit and then abandon them. Nice.

Anyone who committed to Python did so without being battered by a
multi-million dollar advertising campaign.

Multi-million dollar ad campaigns mean nothing to me.
I committed to Python because it's a great language.
I've dabbled in perl, Visual BASIC, UBASIC, REXX, Java,
Scheme, C and C++ but Python is the one I use.

The Python Software
Foundation has only recently dipped its toes in the advocacy waters,
with results that are still under evaluation. And the use of the
Microsoft "free" VC6 SDK was never a part of the "official" means of
producing Python or its extensions, it was a community-developed
solution to the lack of availability of a free VS-compatible compilation
system for extension modules.

I agree that there are frustrations involved with maintaining extension
modules on the Windows platform without having a copy of Visual Studio
(of the correct version) available. One of the reasons Python still uses
an outdated version of VS is to avoid forcing people to upgrade. Any
such decision will have fallout.

Such as anyone who tries to get in the game late.

An update is in the works for those
using more recent releases,

That's good news, although the responsible thing
to do was not relaease version 2.5 until such issues
are resolved.

but that won't help users who don't have
access to Visual Studio.

That can be solved by throwing money at the problem.
But money doesn't help when the solution is on the
far side of the moon.

>

Yes, it's
occasionally very frustrating to the rest of us, but that's life.

As the Kurds are well aware.

I really don't think you help your argument by trying to draw parallels
between the problems of compiler non-availability and those of a
population subject to random genocide.

You missed the point of the analogy.

The US government suggested to the oppressed tribes
in Iraq that they should rise up and overthrow
Saddam Hussein at the end of the first Gulf War.
And what did the US government do when they rose up?
Nothing. They were left to twist in the wind.

Try to keep things in perspective, please.

See if you can see the similarity.

I buy into Python. I spend a lot of effort
developing a math library based on GMPY to use
in my research. I discover a bug in GMPY and
actually go to a lot of effort and solve it.
But _I_ can't even use it because I've been
left to twist in the wind by the fact that
Python 2.5 for Windows was built with an
obsolete compiler that's not even available.

Luckily, unlike the Kurds, my situation had
a happy ending, someone else compiled the fixed
GMPY source and made a 2.5 Windows version
available. But can anyone say what will happen
the next time?

>

The best I feel I can do is raise these things on occasion,
on the off-chance that I manage to catch the attention of
someone who is
altruistic, knowledgeable, and who has some spare time on
their hands!

Someone who, say, solved the memory leak in the GMPY
divm() function even though he had no way of compiling
the source code?

Just think of what such an altruistic, knowedgeable
person could do if he could use the current VC compiler
or some other legally available compiler.

Your efforts would probably be far better spent trying to build a
back-end for mingw or some similar system into Python's development
system, to allow Python for Windows to be built on a regular rather than
a one-off basis using a completely open source tool chain.

No, as I said elsewhere, I'm not a software developer,
I'm an amateur math researcher. My efforts are best spent
as an actual end user to find and report bugs that the
developers never see. Remember, a programmer, because he
wrote it, only _thinks_ he knows how the program works.
Whereas I, the user, _know_ how it works.

>
The fact that the current maintainers of the Windows side of Python
choose to use a commercial tool to help them isn't something I am going
to try and second-guess. To do so would be to belittle efforts I would
have no way of duplicating myself, and I have far too much respect for
those efforts to do so.

And I respect those efforts too. What I don't respect
is irresponsible behaviour.

>
There are published ways to build extension modules for Windows using
mingw, by the way - have you tried any of them?

Yeah, and got nowhere.

It's much harder than sniping on a newsgroup,

That figures. You try and contribute and you get
accused of being a troll.

but you earn rather more kudos.

Guess what kudos I got for solving the GMPY divm()
problem? None. How much effort would it have been
to mention my contribution in the source code
comments (as was the case for other contributers)?
Not that I'm bitter, after all, I'm altruistic.

By the way, on the sci.math newsgroup I promote
Python every chance I get. One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?

>
regards
* Steve
--
Steve Holden * * * [phone] *[phone]
Holden Web LLC/Ltd * * * * *http://www.holdenweb.com
Skype: holdenweb * *http://del.icio.us/steve.holden
Blog of Note: * * * * *http://holdenweb.blogspot.com
See you at PyCon? * * * *http://us.pycon.org/TX2007

[Steve Holden]

me********@aol.com wrote:

On Feb 11, 1:35�am, Steve Holden <[e-mail]:

[...]

>>>After all, they have already given freely and generously, and if they choose
not to give more on top of that, it's really up to them.
Right. Get people to commit and then abandon them. Nice.

Anyone who committed to Python did so without being battered by a
multi-million dollar advertising campaign.

Multi-million dollar ad campaigns mean nothing to me.
I committed to Python because it's a great language.
I've dabbled in perl, Visual BASIC, UBASIC, REXX, Java,
Scheme, C and C++ but Python is the one I use.

Yes, but your decision must surely have been an informed one, and there
must surely be reasons why Python remains your choice.

>The Python Software
Foundation has only recently dipped its toes in the advocacy waters,
with results that are still under evaluation. And the use of the
Microsoft "free" VC6 SDK was never a part of the "official" means of
producing Python or its extensions, it was a community-developed
solution to the lack of availability of a free VS-compatible compilation
system for extension modules.

I agree that there are frustrations involved with maintaining extension
modules on the Windows platform without having a copy of Visual Studio
(of the correct version) available. One of the reasons Python still uses
an outdated version of VS is to avoid forcing people to upgrade. Any
such decision will have fallout.

Such as anyone who tries to get in the game late.

I'm afraid it does seem to work out like that, yes.

>An update is in the works for those
using more recent releases,

That's good news, although the responsible thing
to do was not relaease version 2.5 until such issues
are resolved.

Well that would be an issue for the release team. I'm not sure what
Anthony Baxter (the release manager) would have to say in response to
this point.

>but that won't help users who don't have
access to Visual Studio.

That can be solved by throwing money at the problem.
But money doesn't help when the solution is on the
far side of the moon.

I see your problem, but I don't know what I can do to help you. There
were also, as I remember it, issues with the updated version of Visual
Studio being non-conformant with standards in some significant way, but
I never took part in the discussions on those issues.

>>>Yes, it's
occasionally very frustrating to the rest of us, but that's life.
As the Kurds are well aware.

I really don't think you help your argument by trying to draw parallels
between the problems of compiler non-availability and those of a
population subject to random genocide.

You missed the point of the analogy.

Perhaps because it wasn't a very good one?

The US government suggested to the oppressed tribes
in Iraq that they should rise up and overthrow
Saddam Hussein at the end of the first Gulf War.
And what did the US government do when they rose up?
Nothing. They were left to twist in the wind.

>Try to keep things in perspective, please.

See if you can see the similarity.

I buy into Python. I spend a lot of effort
developing a math library based on GMPY to use
in my research. I discover a bug in GMPY and
actually go to a lot of effort and solve it.
But _I_ can't even use it because I've been
left to twist in the wind by the fact that
Python 2.5 for Windows was built with an
obsolete compiler that's not even available.

Luckily, unlike the Kurds, my situation had
a happy ending, someone else compiled the fixed
GMPY source and made a 2.5 Windows version
available. But can anyone say what will happen
the next time?

Presumably not. I presume you have been reporting your bugs through the
Sourceforge project to keep the developers in touch with the issues you
have found? Normally a package's maintainers will produce updated
installers, but this behaviour is unreliable and (no pun intended)
patchy sometimes.

>>>The best I feel I can do is raise these things on occasion,
on the off-chance that I manage to catch the attention of
someone who is
altruistic, knowledgeable, and who has some spare time on
their hands!
Someone who, say, solved the memory leak in the GMPY
divm() function even though he had no way of compiling
the source code?
Just think of what such an altruistic, knowedgeable
person could do if he could use the current VC compiler
or some other legally available compiler.

Your efforts would probably be far better spent trying to build a
back-end for mingw or some similar system into Python's development
system, to allow Python for Windows to be built on a regular rather than
a one-off basis using a completely open source tool chain.

No, as I said elsewhere, I'm not a software developer,
I'm an amateur math researcher. My efforts are best spent
as an actual end user to find and report bugs that the
developers never see. Remember, a programmer, because he
wrote it, only _thinks_ he knows how the program works.
Whereas I, the user, _know_ how it works.

>The fact that the current maintainers of the Windows side of Python
choose to use a commercial tool to help them isn't something I am going
to try and second-guess. To do so would be to belittle efforts I would
have no way of duplicating myself, and I have far too much respect for
those efforts to do so.

And I respect those efforts too. What I don't respect
is irresponsible behaviour.

>There are published ways to build extension modules for Windows using
mingw, by the way - have you tried any of them?

Yeah, and got nowhere.

>It's much harder than sniping on a newsgroup,

That figures. You try and contribute and you get
accused of being a troll.

I wasn't accusing you of being a troll, rather bemoaning your (in my
opinion) less-than-constructive tone. The points you raise are
important, and I do feel that there ought to be easier solutions for
people in your position.

>but you earn rather more kudos.

Guess what kudos I got for solving the GMPY divm()
problem? None. How much effort would it have been
to mention my contribution in the source code
comments (as was the case for other contributers)?
Not that I'm bitter, after all, I'm altruistic.

I'm sure if you've made a contribution to the code you only have to ask
for your name to be added as a contributor to be mentioned in the source.

By the way, on the sci.math newsgroup I promote
Python every chance I get. One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?

The satisfaction of a job well done? What's my motivation for acting as
a director of the Python Software Foundation when I get accusations of
irresponsibility? Anyway, thanks for taking the time to help maintain gmpy.

This thread is starting to make me think that there's a case to be made
for somehow providing supported build facilities for third-party
extension modules.

This wouldn't be a simple project, but since there's a Windows buildbot
for Python there's no reason why the same couldn't be done for
extensions. I'll raise this with the PSF and see what the response is:
then your carping will at least have had some positive effect ;-)

Stick with it, and let's try to make things better.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[Steven D'Aprano]

On Sun, 11 Feb 2007 01:08:21 -0800, me********@aol.com wrote:

>An update is in the works for those
using more recent releases,

That's good news, although the responsible thing
to do was not relaease version 2.5 until such issues
are resolved.

I realize you're a Windows user, and a Windows user with an AOL email
address at that, so it may come as a shock to learn that the computer
industry doesn't start and finish on Windows. I don't see why the needs of
Windows users like yourself should come ahead of the needs of users on Mac
OS, Linux, Solaris, etc.

>but that won't help users who don't have
access to Visual Studio.

That can be solved by throwing money at the problem.
But money doesn't help when the solution is on the
far side of the moon.

You're mixing metaphors and I don't understand what you mean.

>Yes, it's
occasionally very frustrating to the rest of us, but that's life.

As the Kurds are well aware.

I really don't think you help your argument by trying to draw parallels
between the problems of compiler non-availability and those of a
population subject to random genocide.

You missed the point of the analogy.

The US government suggested to the oppressed tribes
in Iraq that they should rise up and overthrow
Saddam Hussein at the end of the first Gulf War.
And what did the US government do when they rose up?
Nothing. They were left to twist in the wind.

Both the southern Iraqis (mostly so-called "marsh Arabs" and Shiites) and
the northern Kurds rose up against Saddam Hussein. After the Kurdish
rebellion failed, the US and UK belatedly provided them with aid, lots of
aid, and kept the northern no-fly zone going until it was no longer
relevant (2003, the second invasion of Iraq).

It was the southern Iraqis who were left to be slaughtered. Although
technically there was a no-fly zone in the south, it wasn't enforced
when it really counted -- while the rebellion was in full force, the
Iraqi government asked the US for permission to fly into the south.
Permission was given, and the Iraq air force used combat aircraft against
the rebels. Unlike the Kurds, they got no aid, neither money nor military
support.

The end result was that the southern Iraqs were hung out to dry, while the
Kurds ended up a virtually independent state-within-a-state, with their
own "government", their own army, and US and British aircraft protecting
them.

>Try to keep things in perspective, please.

See if you can see the similarity.

I buy into Python. I spend a lot of effort
developing a math library based on GMPY to use
in my research. I discover a bug in GMPY and
actually go to a lot of effort and solve it.

Good on you, and I'm not being sarcastic. But do try to keep a bit of
perspective. Whatever your problem, you're not being bombed or shot.
Frankly, the fact that you not only came up with the analogy, but continue
to defend it, suggests an over-active sense of your own entitlement.

But _I_ can't even use it because I've been
left to twist in the wind by the fact that
Python 2.5 for Windows was built with an
obsolete compiler that's not even available.
Luckily, unlike the Kurds, my situation had
a happy ending, someone else compiled the fixed
GMPY source and made a 2.5 Windows version
available. But can anyone say what will happen
the next time?

Get yourself a compiler, then you won't be relying on the kindness of
strangers.

If that's not practical, for whatever reason, then remember: you're
relying on the kindness of strangers. They don't owe you a thing. If
anything, you owe them.
[snip]

>Your efforts would probably be far better spent trying to build a
back-end for mingw or some similar system into Python's development
system, to allow Python for Windows to be built on a regular rather than
a one-off basis using a completely open source tool chain.

No, as I said elsewhere, I'm not a software developer,
I'm an amateur math researcher. My efforts are best spent
as an actual end user

If you won't scratch your own itch, don't be surprised if nobody else
cares enough to scratch it for you.

to find and report bugs that the
developers never see. Remember, a programmer, because he
wrote it, only _thinks_ he knows how the program works.
Whereas I, the user, _know_ how it works.

Oh wow. That's the most audacious, self-involved and sheer arrogant claim
I've ever heard, and I've heard a lot of nonsense sprouted by arrogant
know-nothings with delusions of grandeur. For the sake of your
credibility, I hope you can support that claim.
[snip]

>It's much harder than sniping on a newsgroup,

That figures. You try and contribute and you get
accused of being a troll.

"I have a problem. I demand that somebody fix it for me!" is hardly
contributing.

If you don't have the technical skills to fix it yourself, have you
considered putting hand in pocket and paying a software developer to do
it? It might even come out cheaper than buying a commercial compiler, and
it would help others. That should appeal to somebody as altruistic as you.

but you earn rather more kudos.

Guess what kudos I got for solving the GMPY divm()
problem? None. How much effort would it have been
to mention my contribution in the source code
comments (as was the case for other contributers)?
Not that I'm bitter, after all, I'm altruistic.

Naturally.

By the way, on the sci.math newsgroup I promote
Python every chance I get.

That's mighty big of you.

One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?

Because you want the bugs fixed so you can get on with whatever coding you
want to do.

Because you're altruistic.

Because you want people to know how clever you are.

Are those enough reasons?

--
Steven.

[mensanator]

On Feb 11, 4:24 am, Steve Holden <[e-mail]:

[e-mail] wrote:

On Feb 11, 1:35?am, Steve Holden <[e-mail]:

[...]

>>After all, they have already given freely and generously, and if they choose
not to give more on top of that, it's really up to them.
Right. Get people to commit and then abandon them. Nice.
Anyone who committed to Python did so without being battered by a
multi-million dollar advertising campaign.

Multi-million dollar ad campaigns mean nothing to me.
I committed to Python because it's a great language.
I've dabbled in perl, Visual BASIC, UBASIC, REXX, Java,
Scheme, C and C++ but Python is the one I use.

Yes, but your decision must surely have been an informed one, and there
must surely be reasons why Python remains your choice.

The Python Software
Foundation has only recently dipped its toes in the advocacy waters,
with results that are still under evaluation. And the use of the
Microsoft "free" VC6 SDK was never a part of the "official" means of
producing Python or its extensions, it was a community-developed
solution to the lack of availability of a free VS-compatible compilation
system for extension modules.

I agree that there are frustrations involved with maintaining extension
modules on the Windows platform without having a copy of Visual Studio
(of the correct version) available. One of the reasons Python still uses
an outdated version of VS is to avoid forcing people to upgrade. Any
such decision will have fallout.

Such as anyone who tries to get in the game late.

I'm afraid it does seem to work out like that, yes.

An update is in the works for those
using more recent releases,

That's good news, although the responsible thing
to do was not relaease version 2.5 until such issues
are resolved.

Well that would be an issue for the release team. I'm not sure what
Anthony Baxter (the release manager) would have to say in response to
this point.

Possibly something like:

"I realize you're a Windows user, and a Windows user with
an AOL email address at that, so it may come as a shock
to learn that the computer industry doesn't start and
finish on Windows. I don't see why the needs of Windows
users like yourself should come ahead of the needs of
users on Mac OS, Linux, Solaris, etc." - Steven D'Arpano

I would hope that it would instead be that the needs of
all users are equal.

>

but that won't help users who don't have
access to Visual Studio.

That can be solved by throwing money at the problem.
But money doesn't help when the solution is on the
far side of the moon.

I see your problem, but I don't know what I can do to help you.

Well, that was the point of this, to get people to
see the problem.

There
were also, as I remember it, issues with the updated version of Visual
Studio being non-conformant with standards in some significant way, but
I never took part in the discussions on those issues.

>>Yes, it's
occasionally very frustrating to the rest of us, but that's life.
As the Kurds are well aware.
I really don't think you help your argument by trying to draw parallels
between the problems of compiler non-availability and those of a
population subject to random genocide.

You missed the point of the analogy.

Perhaps because it wasn't a very good one?

The US government suggested to the oppressed tribes
in Iraq that they should rise up and overthrow
Saddam Hussein at the end of the first Gulf War.
And what did the US government do when they rose up?
Nothing. They were left to twist in the wind.

Try to keep things in perspective, please.

See if you can see the similarity.

I buy into Python. I spend a lot of effort
developing a math library based on GMPY to use
in my research. I discover a bug in GMPY and
actually go to a lot of effort and solve it.
But _I_ can't even use it because I've been
left to twist in the wind by the fact that
Python 2.5 for Windows was built with an
obsolete compiler that's not even available.

Luckily, unlike the Kurds, my situation had
a happy ending, someone else compiled the fixed
GMPY source and made a 2.5 Windows version
available. But can anyone say what will happen
the next time?

Presumably not. I presume you have been reporting your bugs through the
Sourceforge project to keep the developers in touch with the issues you
have found?

Last time I tried, it didn't work and e-mail to the
maintainer didn't get any response.

Normally a package's maintainers will produce updated
installers,

Unless they have stopped doing Windows developement as
part of their job as is the case with GMPY. Luckily,
there's someone out there who does create Windows
binaries.

but this behaviour is unreliable and (no pun intended)
patchy sometimes.

>>The best I feel I can do is raise these things on occasion,
on the off-chance that I manage to catch the attention of
someone who is
altruistic, knowledgeable, and who has some spare time on
their hands!
Someone who, say, solved the memory leak in the GMPY
divm() function even though he had no way of compiling
the source code?
Just think of what such an altruistic, knowedgeable
person could do if he could use the current VC compiler
or some other legally available compiler.
Your efforts would probably be far better spent trying to build a
back-end for mingw or some similar system into Python's development
system, to allow Python for Windows to be built on a regular rather than
a one-off basis using a completely open source tool chain.

No, as I said elsewhere, I'm not a software developer,
I'm an amateur math researcher. My efforts are best spent
as an actual end user to find and report bugs that the
developers never see. Remember, a programmer, because he
wrote it, only _thinks_ he knows how the program works.
Whereas I, the user, _know_ how it works.

The fact that the current maintainers of the Windows side of Python
choose to use a commercial tool to help them isn't something I am going
to try and second-guess. To do so would be to belittle efforts I would
have no way of duplicating myself, and I have far too much respect for
those efforts to do so.

And I respect those efforts too. What I don't respect
is irresponsible behaviour.

There are published ways to build extension modules for Windows using
mingw, by the way - have you tried any of them?

Yeah, and got nowhere.

It's much harder than sniping on a newsgroup,

That figures. You try and contribute and you get
accused of being a troll.

I wasn't accusing you of being a troll, rather bemoaning your (in my
opinion) less-than-constructive tone.

The squeaky wheel gets the grease.

The points you raise are
important, and I do feel that there ought to be easier solutions for
people in your position.

That's all I'm asking for is for others to appreciate
the situation.

>

but you earn rather more kudos.

Guess what kudos I got for solving the GMPY divm()
problem? None. How much effort would it have been
to mention my contribution in the source code
comments (as was the case for other contributers)?
Not that I'm bitter, after all, I'm altruistic.

I'm sure if you've made a contribution to the code you only have to ask
for your name to be added as a contributor to be mentioned in the source.

That wasn't important, I'm not that petty.
It was simply a real-world example.

>

By the way, on the sci.math newsgroup I promote
Python every chance I get. One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?

The satisfaction of a job well done? What's my motivation for acting as
a director of the Python Software Foundation when I get accusations of
irresponsibility?

I apologize. But I hope you see how this appears from
the outside, that the PSF doesn't give a rat's ass about
Windows users with AOL addresses. Sure, that's wrong,
but calling people who bring up these points whiny leeches
doesn't do anything to dispell that notion.

Anyway, thanks for taking the time to help maintain gmpy.

Thanks, I try to help as much as I can. I'm a little
sensitive about gmpy because without it, I would have
to abandon Python and I don't want to abandon Python.

>
This thread is starting to make me think that there's a case to be made
for somehow providing supported build facilities for third-party
extension modules.

And the untouchables would greatly appreciate it.

>
This wouldn't be a simple project, but since there's a Windows buildbot
for Python there's no reason why the same couldn't be done for
extensions. I'll raise this with the PSF and see what the response is:
then your carping will at least have had some positive effect ;-)

Stick with it, and let's try to make things better.

Ok.

>
regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[mensanator]

On Feb 11, 5:33?am, Steven D'Aprano
<[e-mail]:

On Sun, 11 Feb 2007 01:08:21 -0800, [e-mail] wrote:

An update is in the works for those
using more recent releases,

That's good news, although the responsible thing
to do was not relaease version 2.5 until such issues
are resolved.

I realize you're a Windows user, and a Windows user with an AOL email
address at that,

Now I know what it felt like to be a Shiite
living in Iraq.

so it may come as a shock to learn that the computer
industry doesn't start and finish on Windows. I don't see why the needs of
Windows users like yourself should come ahead of the needs of users on Mac
OS, Linux, Solaris, etc.

but that won't help users who don't have
access to Visual Studio.

That can be solved by throwing money at the problem.
But money doesn't help when the solution is on the
far side of the moon.

You're mixing metaphors and I don't understand what you mean.

Yes, it's
occasionally very frustrating to the rest of us, but that's life.

As the Kurds are well aware.

I really don't think you help your argument by trying to draw parallels
between the problems of compiler non-availability and those of a
population subject to random genocide.

You missed the point of the analogy.

The US government suggested to the oppressed tribes
in Iraq that they should rise up and overthrow
Saddam Hussein at the end of the first Gulf War.
And what did the US government do when they rose up?
Nothing. They were left to twist in the wind.

Both the southern Iraqis (mostly so-called "marsh Arabs" and Shiites) and
the northern Kurds rose up against Saddam Hussein. After the Kurdish
rebellion failed, the US and UK belatedly provided them with aid, lots of
aid, and kept the northern no-fly zone going until it was no longer
relevant (2003, the second invasion of Iraq).

It was the southern Iraqis who were left to be slaughtered. Although
technically there was a no-fly zone in the south, it wasn't enforced
when it really counted -- while the rebellion was in full force, the
Iraqi government asked the US for permission to fly into the south.
Permission was given, and the Iraq air force used combat aircraft against
the rebels. Unlike the Kurds, they got no aid, neither money nor military
support.

The end result was that the southern Iraqs were hung out to dry, while the
Kurds ended up a virtually independent state-within-a-state, with their
own "government", their own army, and US and British aircraft protecting
them.

Try to keep things in perspective, please.

See if you can see the similarity.

I buy into Python. I spend a lot of effort
developing a math library based on GMPY to use
in my research. I discover a bug in GMPY and
actually go to a lot of effort and solve it.

Good on you, and I'm not being sarcastic. But do try to keep a bit of
perspective. Whatever your problem, you're not being bombed or shot.
Frankly, the fact that you not only came up with the analogy, but continue
to defend it, suggests an over-active sense of your own entitlement.

But _I_ can't even use it because I've been
left to twist in the wind by the fact that
Python 2.5 for Windows was built with an
obsolete compiler that's not even available.
Luckily, unlike the Kurds, my situation had
a happy ending, someone else compiled the fixed
GMPY source and made a 2.5 Windows version
available. But can anyone say what will happen
the next time?

Get yourself a compiler, then you won't be relying on the kindness of
strangers.

If that's not practical, for whatever reason, then remember: you're
relying on the kindness of strangers. They don't owe you a thing. If
anything, you owe them.

[snip]

Your efforts would probably be far better spent trying to build a
back-end for mingw or some similar system into Python's development
system, to allow Python for Windows to be built on a regular rather than
a one-off basis using a completely open source tool chain.

No, as I said elsewhere, I'm not a software developer,
I'm an amateur math researcher. My efforts are best spent
as an actual end user

If you won't scratch your own itch, don't be surprised if nobody else
cares enough to scratch it for you.

to find and report bugs that the
developers never see. Remember, a programmer, because he
wrote it, only _thinks_ he knows how the program works.
Whereas I, the user, _know_ how it works.

Oh wow. That's the most audacious, self-involved and sheer arrogant claim
I've ever heard, and I've heard a lot of nonsense sprouted by arrogant
know-nothings with delusions of grandeur. For the sake of your
credibility, I hope you can support that claim.

[snip]

It's much harder than sniping on a newsgroup,

That figures. You try and contribute and you get
accused of being a troll.

"I have a problem. I demand that somebody fix it for me!" is hardly
contributing.

If you don't have the technical skills to fix it yourself, have you
considered putting hand in pocket and paying a software developer to do
it? It might even come out cheaper than buying a commercial compiler, and
it would help others. That should appeal to somebody as altruistic as you.

but you earn rather more kudos.

Guess what kudos I got for solving the GMPY divm()
problem? None. How much effort would it have been
to mention my contribution in the source code
comments (as was the case for other contributers)?
Not that I'm bitter, after all, I'm altruistic.

Naturally.

By the way, on the sci.math newsgroup I promote
Python every chance I get.

That's mighty big of you.

One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?

Because you want the bugs fixed so you can get on with whatever coding you
want to do.

Because you're altruistic.

Because you want people to know how clever you are.

Are those enough reasons?

--
Steven

[Steve Holden]

me********@aol.com wrote:

On Feb 11, 4:24 am, Steve Holden <[e-mail]:

>[e-mail] wrote:

>>On Feb 11, 1:35?am, Steve Holden <[e-mail]:

[...]

>

>>By the way, on the sci.math newsgroup I promote
Python every chance I get. One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?

The satisfaction of a job well done? What's my motivation for acting as
a director of the Python Software Foundation when I get accusations of
irresponsibility?

I apologize. But I hope you see how this appears from
the outside, that the PSF doesn't give a rat's ass about
Windows users with AOL addresses. Sure, that's wrong,
but calling people who bring up these points whiny leeches
doesn't do anything to dispell that notion.

The AOL address is nothing to do with it. Accusations of whiny leeching
tend to be made at people whose attitudes aren't constructive and who
express their complaints in ways that seem to imply an expectation of
some kind of right to dictate to open source developers.

>Anyway, thanks for taking the time to help maintain gmpy.

Thanks, I try to help as much as I can. I'm a little
sensitive about gmpy because without it, I would have
to abandon Python and I don't want to abandon Python.

>This thread is starting to make me think that there's a case to be made
for somehow providing supported build facilities for third-party
extension modules.

And the untouchables would greatly appreciate it.

We're all Python users. There are no untouchables. But in the open
source world you tend to have to take ownership of the problems that are
important to you.

Since you say you couldn't get the attention of gmpy's developers you
might need to think about trying to join the team ...

>This wouldn't be a simple project, but since there's a Windows buildbot
for Python there's no reason why the same couldn't be done for
extensions. I'll raise this with the PSF and see what the response is:
then your carping will at least have had some positive effect ;-)

Stick with it, and let's try to make things better.

Ok.

On a point of information, as it happens there's a Board meeting today
and I have tabled the topic for discussion. Unfortunately I can't
guarantee to attend the meeting (I am moving from the UK to the USA this
week) but I will try to do so, and will attempt to report back to c.l.py
within a week.

regards
Steve

PS: Couldn't send this yesterday, or attend the meeting, because BT
Internet termined my DSL service early, mau God rot their profits and
drive them into bankruptcy. I'll report back once I found out how the
discussions went.
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[mensanator]

On Feb 13, 2:24 am, Steve Holden <[e-mail]:

[e-mail] wrote:

On Feb 11, 4:24 am, Steve Holden <[e-mail]:

[e-mail] wrote:
On Feb 11, 1:35?am, Steve Holden <[e-mail]:

[...]

>By the way, on the sci.math newsgroup I promote
Python every chance I get. One fellow thanked me
profusely for recommending Python & GMPY and asked
for some help with a program he was having problems
with. We worked it out fine but his problem made me
suspect there may be more bugs in GMPY. What's my
motivation for tracking them down?
The satisfaction of a job well done? What's my motivation for acting as
a director of the Python Software Foundation when I get accusations of
irresponsibility?

I apologize. But I hope you see how this appears from
the outside, that the PSF doesn't give a rat's ass about
Windows users with AOL addresses. Sure, that's wrong,
but calling people who bring up these points whiny leeches
doesn't do anything to dispell that notion.

The AOL address is nothing to do with it.

Did you read the reply from Steven D'Arpano? He seems to
think it has something to do with it.

Accusations of whiny leeching
tend to be made at people whose attitudes aren't constructive

That's why I brought up the gmpy incident, to show that I don't
have such an attitude. I even said I would pay for a compiler
if that's what it took, which is more than what some open source
developers are willing to do (and I don't blame them).

and who
express their complaints in ways that seem to imply an expectation of
some kind of right to dictate to open source developers.

I never meant to dictate what open source developers should do.
But do they care about the implications of what they do?
Remember, I got onto this thread replying to say that when
an open source developer doesn't think past his own computer,
then that's not the altruistic behaviour that others claim is
the hallmark of open source. Sure, it rubs people the wrong
way when I not so politely ask them to please look at the beam
in their own eye before complaining about the mote in their
neighbor's eye.

>

Anyway, thanks for taking the time to help maintain gmpy.

Thanks, I try to help as much as I can. I'm a little
sensitive about gmpy because without it, I would have
to abandon Python and I don't want to abandon Python.

This thread is starting to make me think that there's a case to be made
for somehow providing supported build facilities for third-party
extension modules.

And the untouchables would greatly appreciate it.

We're all Python users.

That's what I was hoping to hear.

There are no untouchables.

I'll ignore Steven D'Arpano's prattle.

But in the open
source world you tend to have to take ownership of the problems that are
important to you.

That's part of the trouble. I could never write gmpy from scratch,
don't know enough. But I'm very good at understanding existing things.
For 20 years I was a System Test Engineer and still consider myself
a great debugger of both hardware and software.

>
Since you say you couldn't get the attention of gmpy's developers you
might need to think about trying to join the team ...

There's a team?

>

This wouldn't be a simple project, but since there's a Windows buildbot
for Python there's no reason why the same couldn't be done for
extensions. I'll raise this with the PSF and see what the response is:
then your carping will at least have had some positive effect ;-)

Stick with it, and let's try to make things better.

Ok.

On a point of information, as it happens there's a Board meeting today
and I have tabled the topic for discussion. Unfortunately I can't
guarantee to attend the meeting (I am moving from the UK to the USA this
week) but I will try to do so, and will attempt to report back to c.l.py
within a week.

Again, thanks for listening and trying to help. Even if nothing comes
of
it, at least we tried. I figure that sooner or later something has to
be
done and I'd rather see it done sooner. And no, I don't think I'm
entitled to that.

>
regards
Steve

PS: Couldn't send this yesterday, or attend the meeting, because BT
Internet termined my DSL service early, mau God rot their profits and
drive them into bankruptcy. I'll report back once I found out how the
discussions went.
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[Steve Holden]

me********@aol.com wrote:

On Feb 13, 2:24 am, Steve Holden <[e-mail]:

[...]

>>>This wouldn't be a simple project, but since there's a Windows buildbot
for Python there's no reason why the same couldn't be done for
extensions. I'll raise this with the PSF and see what the response is:
then your carping will at least have had some positive effect ;-)
Stick with it, and let's try to make things better.
Ok.

On a point of information, as it happens there's a Board meeting today
and I have tabled the topic for discussion. Unfortunately I can't
guarantee to attend the meeting (I am moving from the UK to the USA this
week) but I will try to do so, and will attempt to report back to c.l.py
within a week.

Again, thanks for listening and trying to help. Even if nothing comes
of
it, at least we tried. I figure that sooner or later something has to
be
done and I'd rather see it done sooner. And no, I don't think I'm
entitled to that.

>regards
Steve

Unfortunately the matter wasn't discussed due to my enforced absence
from the 'Net and pressure of other business. But it's on my radar now
and I will continue to progress it.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007