the basic difference between php global functions and their python counterpart is in their scope:

python top-level functions are part of the module where they are defined.
when they are imported, they are called with defining_module.function_name()
therefore there is less risk of conflicting names.

php ‘global’ functions are really global, iirc, no matter from where they are called. thus they are much more likely to create naming problems, e.g. be overwritten by some third-party library, etc.

In general, it’s a preference thing. “Static” in this context is just another word for “global”, so although either way will get you some evil looks (particularly if you’re only using classes as namespaces), it works.

But:

• PHP can very easily be set up to autoload classes, making it so that static functions aren’t loaded in til you have need of them (or others in the same class). It can’t do the same for individual functions (yet), though. I’m not sure whether Python has an equivalent for either one, but i haven’t seen it yet.

• Unlike global functions, static member functions can generally be made private, so it’s easier to expose only the bits you intend for outsiders to use. Well, except in Python, where you have to jump through some hoops to get private members.

• PHP didn’t have namespace support til recently, meaning every top-level function was crammed into the same namespace. That’s changed, but PHP namespaces are still rather hideous. 😛

• It seems Python doesn’t like making member functions static. Other languages have a keyword for that purpose; in Python, apparently you need an annotation (excuse me, “decorator”).

Python namespaces everything: Everything is in a module, and everything defined in a module has module scope rather than global scope (you have to go out of your way and do evil things to add something to “all” scopes). So name collisions aren’t an issue. In PHP, on the other hand, if you just go ahead and define a function, you put it in the same scope everyone is using for global names. You either explicitly use a namespace to prevent that, or you use a class as “namespace” (though the class should probably be in a namespace itself). The added bonus is that classes benefit from autoloaders, whereas functions do not IIRC.

There are philosophical differences too. The Python community is (and long has been) very open to utilizing multiple paradigms. Classes, higher-order functions and simple procedural programming are all equally accepted ways of doing stuff, as long as they fit the problem. And module-level data + functions does just what, so unless you need polymorphism or want a strong association with a particular class, there’s little benefit of attaching a non-method to a class.
In contrast, the PHP community (at least since the majority stopped screwing around and giving PHP the bad reputation it built up over the years) seems to be focused heavily on object-oriented programming. Free functions simply don’t fit into this paradigm, whereas static is widely accepted. I don’t quite get the logic behind that, but such is the convention.

Finally, note that staticmethod is not only eschewed because we don’t like the concept of static methods. Sometimes we do want static methods, but then we usually prefer classmethod, which does basically the same thing but gives more power to the method (it receives the class object, and can thus there can be polymorphism among classmethods). staticmethod is sometimes considered to be entirely redundant.