On Tue, Nov 27, 2012 at 3:19 PM, Trent Nelson <tr...@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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
