Slashdot Mirror

I highly recommend "How to Think Like a Computer Scientist: Learning with Python." It's a great introduction to programming using a language that doesn't get in the way. Python is also a great language for starting procedurally and "graduating" to OO. Besides being a great book, it's available for free in LaTeX, PDF, PostScript, and HTML. Needless to say, both the language and the book are available "using any web browser." As for JavaScript, I have tried to keep it at arm's length for as long as possible.

It is, all by itself, a compelling reason to learn C++ if you don't already know it.

And even if you for some reason want to avoid C++, there's a good chance that you'll be able to use it. I spend my days coding a QT application in Python using PyQT.
I have, on occasion, had to read a couple of lines of C++ code (in the rare case when the QT documentation lacks some detail), but never needed to produce a single line of C++ myself.

I went to this page. And correct me if I'm wrong, but you have to pay?

:)

See: http://www.cpan.org/ports/#win32

However! If you don't know Perl, perhaps I can point you in the direction of Python instead? It is far superior, being both easier for the beginner and more powerful for the advanced programmer. There are some excellent tutorials...

I went to this page. And correct me if I'm wrong, but you have to pay?

:)

See: http://www.cpan.org/ports/#win32

However! If you don't know Perl, perhaps I can point you in the direction of Python instead? It is far superior, being both easier for the beginner and more powerful for the advanced programmer. There are some excellent tutorials...

Yes, the odbc module is in the public domain, but it isn't being maintained, and there are some known problems.

Yes, the odbc module is in the public domain, but it isn't being maintained, and there are some known problems.

Being nine years old with an aptitude for math and computers should allow your son to grok much of Python and especially the Pygame modules for easy game writing in Python. Pygame runs well in both Linux and Win32 (based on the SDL libraries, also free). There are plenty of short, easy examples of graphics and sound and animation using Pygame.

LiveWires has some Python courses specifically for non-programmers and young people, some with a slant toward games.

You might also look at Guido van Robot, a Python-based robot programming environment for children. Maybe it won't allow for 'real' game writing, but the concepts seem sound and it might be a more gentle intro.

Python and Pygame. Python is not only easy to learn but also a powerful real-world programming language. It might not be quite as ideal for a 9 year old as languages/environments designed to be more playful and task-specific, but it's probably the best "real" language out there for the application. Besides, from what I've heard, a lot of people learned Basic around 9 or so and Python is definitely easier (if not to grasp the basics of then at least to do anything useful with) than Basic :)

yep, mixed tabs and spaces is bad. Guido included this on his list of python regrets at Pycon 2003. FWIW, emacs python-mode is fantastic, and vim usually annoys the heck out of me until i remember to set up .vimrc properly.

I agree, ODBC is a critical feature for a "glue" language like Python. There's mxODBC, but commercial use costs $75 per end-user or $1,250 per developer. Most of Python's other database modules are free, but ODBC is needed to fill a lot of gaps.

import psyco
psyco.full()

• Win32All - Windows 32 extensions & the Pythonwin IDE
• wxPython - A GUI library based on wxWindows. Far superior to the included TCL/TK libraries.
• Psyco - Runtime compiler, mentioned above
• Py2Exe - Takes in Python scripts, spits out executables (note: use in conjunction with Psyco for best effect)
• Boa Constructor - A wxWindows GUI design tool. It's a full blown IDE as well, but I have only used it to design GUI layouts, I code in Pythonwin.

...can be found here.

I prefer Ruby, but there seem to be a lot of healthy discussions of various language features and ideas across the scripting language community. The "Python comparison page", for example, has a link to John Ousterhout's paper on why scripting languages are useful - even thought he wrote the paper about Tcl, it's just as applicable to Python or Ruby.

You do, of course, mean: "Wonder why it's easier to put a camel through a mobile phone than a British comedy troupe .

1.16 Why is it called Python?

At the same time he began implementing Python, Guido van Rossum was also reading the published scripts from "Monty Python's Flying Circus" (a BBC comedy series from the seventies, in the unlikely case you didn't know). It occurred to him that he needed a name that was short, unique, and slightly mysterious, so he decided to call the language Python.

Wonder why it's easier to put a camel through a mobile phone than a snake.

Thats not correct. The parent poster is reffering to the fact that methods in Python have a argument called self, which you sometimes have to type, sometimes to declare, sometimes not.
I'm well aware of that. But 'self' is not a keyword. If you don't like to type it, use something shorter, say: 's'.
I have no clue what you mean by "declaring" and "sometimes not". It is always there, it can be called differently. And you never declare things in Python.

For the C++/Java folks, self is the equivalent of this. No one likes code like that: self.doThis(); self.doThat();
Except when you have class member 'thing', method argument 'thing', and a local argument 'thing'. In C++ you can also have a global variable called 'thing'. You might argue that it's a bad style, but I've seen codes that do that and play tricks with undescores to sort out the mess. In short, in C++/Java you're allowed to be incosistent: 'thing' and 'this.thing' mean the same, sometimes. Python doesn't have to save keystrokes because it's relatively succinct. I like the 'self' idea because it defines the context for me without looking it up in other places. You don't like it and that's fine with me - that's life.

But how should a class of PYthon 3.0 load a class from Python 1.0 over installatino boundaries?
You just start Python 1.0 as a subbrocess of Python 3.0 process and have a proxy class in Python 3.0 to look like Python 1.0 class that communicates with the subprocess. A page or two of coding.
And why does Python evolve that uncoordinated?
I don't think it can be called uncoordinated - at best you may call the changes too big. The changes go through a well defined process - PEPs. And there is a vote. So in a sense you should blame the majority. Guido only breaks the ties. With Ruby it's Matz's opinion that matters read his opinions in an interview. He hinder Ruby's support for international encondings (see this post).

IMHO it would make sense to define now a Python 7.0, or something. And put everything into it you want, and then let the implementations evolve from the current point towards 7.0. So everyone knows what the final language will look like and kows that the current state is only an interims state.
You've just described what's called Python 3k. The idea has been entertained for a while on Python lists. The problem I have is that I cannot code for something that doesn't exist so I prefer to code for what's out there today. I guess it works for me and it doesn't for you - that's life.

Actually, Python has a large (relative to the popularity of Python in other domains) and happy number-cruncher community. Numeric users include Lawrence Livermore Labs and NASA.

Actually, Python has a large (relative to the popularity of Python in other domains) and happy number-cruncher community. Numeric users include Lawrence Livermore Labs and NASA.

"In the article it rather sounds like they just assumed Python performance would be an indicator of performance for interpreted languages generally, but is there anything to back this up?"

No, there isn't. I will say upfront that I am heavily baised for Python, and do everything I can in it, but when it comes to raw speed, the last numbers I saw show that Perl is about twice as fast. Those benches are for python 2.1 tho, which is quite a ways out of date.

Since then, python in 2.3 has gotten about 30% faster and apparently the devs think that it can take Parrot.

However, I don't code in Python for raw speed, I code in it for productivity and maintainablity, and there it saves me a tremendous amount of time over most everything else, but your milage may vary. For the kind of stuff I do, I swig out to native C once in a blue moon, but mostly the speed thing isn't an issue for me.

Unfortunately, the author compiled python using cygwin, which is extremely *slooooow*. Why on earth he chose to download the python source and compile it under cygwin instead of using the windows binaries provided on python.org that the rest of the world uses remains a mystery. Based on the same false premises that lead gentoo users to compile night and day, perhaps? ;)

It is also misleading that python is often referred to as "fully interpreted" (often several times in one sentence) and compared to "semi-compiled java". Python is byte compiled, just like java.

As a programmer who uses python almost exclusively, I have rarely have need to optimise, although I have written a few C extension modules (which is fairly simple), and occasionally used psyco (which is trivial, and in my experience has almost always resulted in a big increase).

Python is slower than the languages tested in many situations, but the results of this particular benchmark aren't worth the electronic paper they're printed on. Oh well, it's pretty damn hard to compare language speed, I guess Christopher guy did his best.

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!

5 Create the all-in-one inbox Email, phone calls, instant messages - they should all go into a single app.

His wish is their command: Quotient.

Don't be fooled by the unadorned web site: Quotient is a multiprotocol server plus client plus repository, supporting POP, IMAP, SIP, IRC and IM, and based on Twisted, an event-based, multiprotocol networking framework. Quotient comes from the Twisted guys themselves.

It's a remarkable architecture, and implemented in a very nice programming language. :^)

That's true. Computer languages that don't stick close to "regular" human expression are very popular and growing quickly. Languages that resemble written English are dwindling rapidly.

After all, code is meant to be written, not read, and programmers should strive to write such that their work can't be understood by anyone not an expert in the language they're using.

Put another way: as long as I have to fix other people's code, or I want my boss to be able to read my code without me spending an afternoon explaining it to him, I really hope it doesn't look like a string of line noise. English-like constructs may be distracting for some, but they're pretty handy for the rest of us.

That's true. Computer languages that don't stick close to "regular" human expression are very popular and growing quickly. Languages that resemble written English are dwindling rapidly.

After all, code is meant to be written, not read, and programmers should strive to write such that their work can't be understood by anyone not an expert in the language they're using.

Put another way: as long as I have to fix other people's code, or I want my boss to be able to read my code without me spending an afternoon explaining it to him, I really hope it doesn't look like a string of line noise. English-like constructs may be distracting for some, but they're pretty handy for the rest of us.

This makes me wonder if they will do the old bait and switch for .net implementations - i.e. mono. Or Sun could do even do this for Java. I'm glad I'm starting to learn Python.

I hate to break it to you, but that joke went straight over your head.

So when will someone do Ruby?

Scientific Applications on Linux

The site lists both free and commerical applications.

For a drafting program, I would recommend QCad which is a nice GPL 2D drafting package. Unfortunatly I am not aware of any GPL 3D drafting programs which are either robust or mature enough for industrial use. Periodically I attempt to get TurboCad running under Wine, but while it seems to be getting closer to working, still no success yet.

Don't overlook the Python Programming Language which has a variety of extensions which make it very suitable for number crunching applications. Its is fairly easy to learn how to make GUI-based applications for specialized purposes, and its speed of development combined with robust error-checking and interpreted execution mode makes it ideal for implementing small engineering solutions.

The DI-194 is a nice and cheap device that they used to give away for free, and offers simple 4-channels of analogue input over RS-232. It uses an intentionally obscure protocol to talk over the serial port, so you'll be needing the Dataq DI-194 Linux driver. I've been trying to contact the author (I'm working on Python bindings for this driver) for a few weeks and had no luck, so don't expect to get help from him.

Python can do this, and any arithmetic with arbitrarily large numbers (up to the limit of available memory).

Zope is a very powerful, yet friendly content management system. If you ever get beyond the basics of a bunch of text and images, it allows Python scripts. Zope is written using Python. Everything I've seen about it seems pretty nice, and I haven't heard a bad word against it.

For example, Python has evolved into an extremely intuitive yet powerful programming language.
Perl was also fairly new in its time.
There's GNU Emacs which is one of the most powerful text editors in existence.
There's the Apache Webserver. Although webservers aren't new, I would hardly call Apache a copy of anything.
I'm not sure whether the first publicly-released blog software was open source, but I think it might have been.
OpenBSD was, AFAIK, the first secure-by-default modern Unix system.
Linux (the kernel) has also done (or been modified to do) several things not done before.
X11 started as a project out of MIT (which I would guess was open-source, even though the phrase hadn't been coined yet.)
GNU readline is also something that is exclusive to open source
I'd guess that ls --color was something new to free software, as well, just because I douby anyone with a pure profit motive would consider it worth the time to implement. :-)
The Debian Project has made several innovations in operating system integration.

Anyway, there are plenty of examples. You just have to look.

Advice to people implementing gesture recognition systems: "In the face of ambiguity, refuse the temptation to guess."

-Don

The Zen of Python (by Tim Peters)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Sigh. I hate trolls, but I will respond anyhow.

You'll take note that the error messages are database related. It has nothing to do with php not being able to handle the logic or programming needs of the website.

What is happening in this case is the database server has too many active connections at one time, and is denying the php script from any more connection attempts.

Another point. A wiki can be built using more languages than php. There are python powered wikis too, to name but one example.

Hm.. you could probably do this with Python and have people who'd actually be able to help (ie: this would be _my_ PDA dream. :)

FYI, the IDLE IDE & debugger (included as the standard editor) is itself written in... Python. So I imagine there would be no problem using something like that as the basis for an OS.

Also.. the Grail web browser (also written in Python, although I think it's not been updated for Python 2.x) allows the running of Python scripts that are embedded in web pages.

There's even a Python port to the PocketPC and to PalmOS, so the runtime environment for a mini-PythonOS would already mostly be in place. Plus if you use the Psyco x86 run-time-compiler for Python - you would not sacrifice much speed for your apps as opposed to them being written in C.

Software is advancing, but the paradigim shifts in the languages is happening much more slowly than the hardware. It's easy to make a widget (CPU) work twice as fast as the previous model because the problem is well defined. But it's more difficult developing the *language* that you think in when you solve those problems.

Computer languages, of course, are trending towards spoken human languages. Eventually we'll be able to describe a problem in spoken English like Star Trek (eg: "raise shields, set phasers to burninate and teleport all green chicks from the planet to my ready room unless we get attacked") and the computer will be able to do what we ask. But it's going to be a while. Taking dictation and understanding & reacting to the logic behind the spoken sentence are two entirely different problems.

Until then, we have Python. It's doing stuff in production environments that was not really possible due to hardware constraints 10 years ago. It's an interpreted partly functional programming language. For example, last month I had about 300MB of log files from which I needed to extract specific data and reformat and merge with another data set. Yah, sure, the program took about 2 minutes to run and used about 50MB of memory at it's peak, but it took less than 15 minutes to write and was only about 50 lines. It would have taken me an entire day to do something like that in C.

It sounds like it's moving towards Python with the addition of Lisp-ish functions and itterators.

Any programmers looking at C#, I recommend also checking out Python, it is a wonderful language. Particularly with Win32 extensions (Windows-specific extensions, but most useful feature is an amazing editor / debugger, Pythonwin) Psyco runtime compiler and wxPython for cross-platform GUI building.

I took the red pill [python.org].

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Programmers will love this language. It's the Python of spoken languages!

These are some of the free (speech or beer) software I'd install on a family, non-gaming machine:

• Web Browser: Mozilla or Mozilla Firebird
• E-mail: Mozilla (cross-platform), Mozilla Thunderbird (cross-platform), Evolution (Gnome), or KMail (KDE)
• Office Suite: OpenOffice.org
• Media Player: QuickTime (Windows), Zinf (cross-platform), RealPlayer (cross-platform), WinAmp (Windows), MPlayer (Windows), XMMS (Linux)
• Image Viewer: IrfanView (Windows)
• Instant Messaging: Gaim (cross-platform)
• Personal Information Management: Palm Desktop Software (great PIM suite even if you don't own a Palm)
• Other: Acrobat Reader (although I'm weary of their DRM), Java 2 Runtime Environment, Macromedia Flash and Shockwave players, Ad-Aware (spyware remover for Windows), ZoneAlarm, Sygate Personal Firewall (firewall, alternative to ZoneAlarm), Grisoft AVG Anti-Virus, FileZilla, WinRAR (not free, shareware with nag window), Ofoto desktop software (basic photo album and touch-ups, even if you don't use Ofoto's online services)

Some other software I'd install on my own desktop (dev), in decreasing order of importance:

• Cygwin, bascially all packages
• UltraEdit32 (45-day trial shareware)
• TightVNC
• Ghostscript and GSView
• Java 2 SDK
• Eclipse
• Borland JBuilder Personal
• ActiveState Perl, Python, Tcl/Tk (yes, even though they are in Cygwin), Jython
• GIMP
• POV-Ray
• At least one of Apache, Tomcat, or Plone (Zope)
• HTTrack (a website copier)

I am surprised not to see the PERL GOD, Larry Wall up on that list. He might not be powerful, but he is influential.

Yeah, he's single-handedly responsible for the rise of the python.

The Python vote is seconded. I got interested in this language a year ago because a co-worker was experimenting with it and loved it. I took 20 minutes to run through a tutorial - an hour I was proficient and had re-written our entire project's build and archival system in it. The langage is clean and logical - docs are awesome.

Now it seems like every test and tool application I write to support development of our major products - is in Python. It's just so much easier, faster - and stable - than the equivalent app in C would be given the same time constraints.

No web Python referal would be complete without mentioning the Zope framework. I've not used it, but I gather it's to web development as nuclear weapons are to hand grenades. So integral to the Python experience that the author of Python [created it / works there /worked there] I can't remember which, but it was one of the above.

Take 20 minutes to run through a Python tutorial as referenced from their main page, try making some simple scripts with it - and tell me you're not hooked.

Also: don't forget the Psyco just-in-time compiler which magically makes time-critical things faster without you doing anything.

Also 2: Bittorrent was written in Python and bundled into an executable with Py2exe! How's that for battle-tested! The user interface looks bad, but that's the author's fault. :)

Also 3: Check out the Win32All package for MFC wrapper libraries and the best free editor (Pythonwin).

Also 4: Activestate has a commercial Python implementation that may help (I've not used it, but someone must have a use for it).

Python 2.3.1 final was released this week. Where was the Slashdot story about that one?

Python 2.3 was released this summer a bit early to accommodate Apple's deadline for OS 10.3. Had there been no such deadline, I suspect this would have been the actual 2.3 release.

That having been said, I haven't noticed any serious problems with the "rushed" 2.3 release.

The Python project provides convenient installers for Windows, so I've never relied on ActivePython. Besides, they're still a version behind anyway. But ActiveTcl and ActivePerl still seem to be the most convenient binary distributions on Win32. Hope they're still maintained.

Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.

Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).

Here is cheap development under Linux (or Windows for that matter):

Load Zope on your Linux server.

Learn Python, if you don't know it already.

Build web based apps quickly and easily via any web browser that supports frames from any location that can route to the server.

Zope has built-in functionality for http server, ftp server, Berkley DB, and allows you to access external SQL databases as needed.

Using simple templates and python programs you can build sophisticated applications quickly.

XS4ALL is also the host of Python's official web site, so in a small way - probably a very very small way - this is also a victory for open source!

Version 1.12 - Note: Features/bugs listed may not apply to some SCO products/versions

NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

Additional suggestions, detailed specific recommendations, comments, requested.

Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

In particular avoid these functions:

(please help with this list - "list 4")

Known bugs in SCO products:

Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

In particular don't depend on these compiler features:

(please help with this list if and when GCC loses SCO support)

6. Don't put in messages that display only on SCO's platforms.

Avoid putting in code like (and especially not commenting):

#if defined(_SCO_DS)
/* SCO OpenServer */ darlsux() ;
#elif defined(__UNIXWARE__)
/* UnixWare gcc */ darlsux() ;
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
#else
/* SCO UnixWare cc */ darlsux() ;
#endif
#elif defined(M_UNIX)
/* ODT 3 or earlier */
#else
/* Other platform */
#endif

7. Don't remove support in your makefile for building the application on SCO's platforms.

8. Don't rename your functions and variables with names that conflict with SCO-spe

Version 1.12 - Note: Features/bugs listed may not apply to some SCO products/versions

NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

Additional suggestions, detailed specific recommendations, comments, requested.

Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

In particular avoid these functions:

(please help with this list - "list 4")

Known bugs in SCO products:

Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

In particular don't depend on these compiler features:

(please help with this list if and when GCC loses SCO support)

6. Don't put in messages that display only on SCO's platforms.

Avoid putting in code like (and especially not commenting):

#if defined(_SCO_DS)
/* SCO OpenServer */ darlsux() ;
#elif defined(__UNIXWARE__)
/* UnixWare gcc */ darlsux() ;
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
#else
/* SCO UnixWare cc */ darlsux() ;
#endif
#elif defined(M_UNIX)
/* ODT 3 or earlier */
#else
/* Other platform */
#endif

7. Don't remove support in your makefile for building the application on SCO's platforms.

8. Don't rename your functions and variables with names that conflict with SCO-spe