[Python-Dev] Handling support for newer OS features at run time

[Gregory P. Smith]

On Tue, Nov 27, 2012 at 3:19 PM, Trent Nelson <trent at snakebite.org> wrote:

> On Tue, Nov 27, 2012 at 03:09:12PM -0800, Matthias Klose wrote:
> > Am 27.11.2012 23:49, schrieb Trent Nelson:
> > >     I don't think we've currently got the ability to do this, right?
> > >     Is there a precedent set anywhere else?  I suspect it's not as
> > >     much of an issue on *NIX platforms as you'll typically compile
> > >     from source.  Windows, not so much.
> > >
> > >     Thoughts?  A single binary that dynamically loads applicable
> > >     modules seems cleaner but will obviously take more work.  Other
> > >     approach would be to start distributing multiple versions of
> > >     Python based on the underlying Windows version.  Not the nicest
> > >     approach.
> >
> > Usually I have to build a python package on a build daemon running the
> > kernel of the latest stable (or latest stable long term support)
> > release.  Thus if a configure test checks the current kernel, then you
> > may get an unexpected answer and a missing feature. It is somehow
> > different that I already build different binaries (per release), but
> > the hard-coding of kernel features during configure time looks like
> > the same issue. Currently working around it by patching configure to
> > remove the test and hard-code it for a particular build. Another
> > solution maybe would to have something like --enable-kernel=<version>
> > (as found in glibc), and hope that you can deduce the features from
> > the kernel version.
>
>     Hmmm.  How often do Linux kernel versions expose new features that
>     we can make use of in Python?  i.e. do you run into this problem
>     often?  Can you cite some recent examples?
>

Here's an example of using the pipe2() system call. The code is only
compiled in if the C library supports it. If the C library supports it, the
system call can still return an error because the running kernel doesn't
support it (ENOSYS). In that case it falls back to the legacy code:


http://hg.python.org/cpython/file/618ea5612e83/Modules/_posixsubprocess.c#l738

-gps


>
>     I'm not sure how much could be shared between Windows and Linux with
>     what you've just described.  With Windows, specifically with regards
>     to providing dynamic select.poll() support, I was thinking of having
>     multiple modules:
>
>         Python33\
>             DLLs\
>                 select.pyd
>                 select_win6.pyd
>                 select_win7.pyd
>                 select_win8.pyd
>
>     And Python would automatically import the appropriate one.  I don't
>     think this would be that useful on Linux -- as you say, the decision
>     is typically made at ./configure time.
>
>         Trent.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121127/9e642f9f/attachment-0001.html>