Implement AIX pollset in Modules/selectmodule.c

Either create new pollset object or use pollset to provide implementation of Python epoll API on AIX.

You should probably also add support to the new selectors module.

I don't mean to be rude, but AIX is IMO a niche platform: proprietary Unices are doomed to disappear sooner or later.
As such, I'm not convinced that adding an AIX-specific polling interface is really worth it.

CF,

If you don't mean to be rude, then don't be rude.  I never claimed that AIX is the most widely used or most important platform. It implements POSIX and Open Group specifications correctly, so it is a good cross-check that features are implemented portably without Linux or BSD assumptions.

This enhancement issue is not a demand that you or anyone else in the Python community volunteer to implement it. AIX is a very lucrative business and deployed in many businesses that the Python community would like to reach. Maybe you should broaden your viewpoint and think about why support for a "niche platform" could be beneficial for Python.

Python already supports various "select" APIs: see select and selectors modules. I don't know pollset: is it something like epoll on Linux?

@David: Would you like to work on a patch?

pollset is the AIX equivalent of Linux epoll (or kqueue). The API is almost identical to epoll except with different interface names and a few minor tweaks. I will try to work on it. I mainly opened this issue as a placeholder to discuss the implementation and for anyone else who wanted to help.

> David Edelsohn added the comment:
>
> This enhancement issue is not a demand that you or anyone else in the Python community volunteer to implement it. AIX is a very lucrative business and deployed in many businesses that the Python community would like to reach. Maybe you should broaden your viewpoint and think about why support for a "niche platform" could be beneficial for Python.

Sorry, but I stand by my claim: making Python work on AIX by fixing compilation bugs, or non-portable assumptions like the one in #19293 is a good thing, and such bugs should be fixed.
But adding a large chunk of AIX-specific code, which will only be used by a handful of users, and more importantly only debuggable and maintainable by a couple of contributors, is a whole different story.

My reaction would be the same if someone were to suggest implementing something similar for e.g. the Hurd (that's an example, I know there are more AIX users).

Also, AFAICT we don't have any *stable* AIX buildbot yet: at the very least, making the current test suite pass - and not merely by skipping tests - and having a stable AIX buildbot would be a prerequisite.

Furthermore, apparently AIX isn't an officially supported platform, see http://www.python.org/getit/other/

Having someone volunteer to write a patch isn't enough to have it merged.

But I'd like to have Martin's opinion, since he's the author and PEP 11, and usually has good insights on those issues.

(note that we have a devpoll implementation for Solaris)

CF,

Pre-built binaries of Python for AIX are available on the Bull Freeware and Perzl sites of Open Source Software for AIX. The "GetIt" page should be updated and the packages can be made available through python.org

Other parts of your reasoning are somewhat circular because most of the problems on AIX are Linux-isms (or BSD-isms where BSD has not yielded to Linux behavior). So you argue against adding lots of AIX-specific code, yet fixing some of the tests more generally will require adding lots of AIX-specific code.

I am trying to focus on features and functionality that will make Python more useful to more AIX users. Hopefully that would grow the Python user base and developer base on AIX and lead to more support for Python on AIX. Fixing every corner case test is more a pedantic argument than something that is useful to the general Python user.

A lot of the Python buildbot testsuite failures are due to a locale issue that has not been my highest priority.

> Other parts of your reasoning are somewhat circular because most of the problems on AIX are Linux-isms (or BSD-isms where BSD has not yielded to Linux behavior). So you argue against adding lots of AIX-specific code, yet fixing some of the tests more generally will require adding lots of AIX-specific code.

It shouldn't require a lot of AIX-specific code, as long as AIX is
POSIX-compliant.
If some tests are failing because on Linux-isms assumptions - either
in the stdlib, or in the tests - as I said, we'll be happy to fix
them: just open relevant issues.

Once again, this issue is not about whether or not we want to support
AIX (I'm personally happy to have as many Unices supported as
possible), but rather whether or not we want to add large chunks of
OS-specific code, whereas the currently generic POSIX primitives -
such as select() and poll() - work on all POSIX-compliant platforms.
Adding platform-specific code has a cost, and IMO, the cost isn't
worth it for AIX.

I can understand that your point of view differs, either because of
your job or personal interest, that's why I'd like to know if there's
a consensus, or semi-official policy among the CPython project.

Feel free to bring this up on the python-dev mailing list!