MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld) [LWN.net]

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 10, 2008 6:39 UTC (Mon) by jamesh (subscriber, #1159)
In reply to: MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld) by tialaramex
Parent article: MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

The sleep problem has apparently been fixed for pygtk applications on Python 2.6:

http://blogs.gnome.org/johan/2008/01/04/enough-wakeups-in...

PyGTK used to sleep properly before the Py_MakePendingCalls() calls were added, but it
prevented ctrl+C and other UNIX signals from working which made people sad.  Calling this
function regularly fixed the signal problem but prevented applications from sleeping for
extended periods.

Python 2.6 adds a new API for checking whether signal handlers need to run that does not
require polling (added specifically for extensions like PyGTK), which should let it sleep as
you'd expect them to.

(Log in to post comments)

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 10, 2008 10:59 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Exactly as I said, the suggested "fix" is that you can upgrade to some future version (Python
2.6 isn't out) and use this new API to work around the problem.

If this was some minor library being worked on by a volunteer in their spare time, fair
enough, we can always just avoid that library - but people are proposing that we write large
and important programs in this language now.

Look what it took to even get this concession, 18 months later, that the next version would
have a fix, someone had to grab Guido at a conference and basically shake him up and down so
he'd go investigate.

In a toy language, or a prototyping language, these sorts of problems are easily forgivable.
But today people want to recommend Python for writing real software that will go out to end
users or into production systems. Indeed most Linux distributions include such software, and
you'll find it running on your machine easily enough, it's the program with the GUI that
freezes whenever it's doing any work, or the one that wakes up needlessly every few
milliseconds, chewing through the whole laptop battery in an hour and a half - and far from
being concerned about this total failure, the Python developers hail it as a success.

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 10, 2008 14:02 UTC (Mon) by beoba (guest, #16942) [Link]

Exactly as I said, the suggested "fix" is that you can upgrade to some future version (Python 2.6 isn't out) and use this new API to work around the problem.

What would you rather they do? Go back in time and change 2.5 before its release? Bringing attention to flaws is good, but unreasonable expectations don't help anyone.

The "new API" comes in the form of a new function which is being added to the standard library's "signal" module.

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 10, 2008 18:25 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Python 2.5.2 was released just a couple of weeks ago.

But Python aspires to the (completely unrealistic) ideal that such releases should be both
backward and forward compatible. The result is that software can still break (thanks to the
universe's unlimited capability to build bigger idiots no amount of rules about backward and
forward compatibility can prevent new releases from breaking old software) but Python refuses
to import important fixes like this to the stable tree because someone might try to run a
(fixed) program against 2.5.1 and that wouldn't work.

In reality some people are using Python to develop major applications. Those people, including
the OLPC project are in the unfortunate situation of having to fork Python 2.5 and maintain
their own version with this fix in it. So even the compatibility goal is sabotaged.

And it's all very well to say "Go back in time" but this specific bug was reported eighteen
months ago - and the problem really dates back to Python's implementation of signal handling
years ago, turning an asynchronous signal into something you have to poll regularly. It's fine
in principle to have a major release cycle which takes years, but you still need to achieve
timely resolution of bugs. Python's current "no compromise" approach doesn't do that.

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 11, 2008 4:34 UTC (Tue) by beoba (guest, #16942) [Link]

Python 3 is not planned to be forward compatible, hence the change in major version number.

2.5.2 is a bugfix release within the 2.5 branch. The aforementioned problem is being solved by
adding a new function call to the standard library, which inherently makes it a target for
2.6.

It sounds like you're complaining without any intent of seeking a resolution to your
complaint. At this point, there isn't really anything else to discuss. Patches welcome.

Python

Posted Mar 11, 2008 10:44 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Of course it's possible to resolve this complaint, but only by taking it seriously. Here's a
thought, why don't you present an example of something that would actually have broken if
Python had taken this fix in some form for 2.5.2 ?

No ? The maintainers working on this bug didn't either. 

Rather than offer an actual rationale you've just recited policy, "inherently makes it a
target for 2.6" isn't a statement about some universal and "inherent" truth but of the
maintainer's policy.

So there's your patch, find the "policy" document that says fixes like this can't go into a
bugfix release, and change it to say "We aim to be pragmatic about taking fixes early." Or
else take the Twisp and Catsby route, and just add a policy statement that Python is not for
use in production software. Either is an adequate response to my complaint (well originally it
wasn't a complaint, just a statement that Python and Mono's C# remain inadequate for serious
application development in 2008).