Good question. All the pythons I see are 2.x (OSX, RHEL).
On May 22, 2013, at 12:18 PM, Josh Hursey <jjhur...@open-mpi.org> wrote: > Is this Python 2.x or 3.x? I ask because they are not 100% compatible due to > changes in the language syntax. Meaning not all 2.x compilant Python programs > work with a 3.x interpreter. IIRC there is a way to write a 2.x compliant > Python program so that it is also 3.x compliant, but my Python knowledge does > not go deep enough to tell you exactly how to do that. > > If we are going to require Python in the build path, we should be specific on > this point and check in the configure script. > > -- Josh > > > On Wed, May 22, 2013 at 11:03 AM, Jeff Squyres (jsquyres) > <jsquy...@cisco.com> wrote: > On May 22, 2013, at 10:00 AM, "Barrett, Brian W" <bwba...@sandia.gov> wrote: > > >> Hmmm...the issue is that perl usually is included in the distro, but > >> python often is not - you have to add that module. > > This seems to be a key argument, but I'm not sure it's still true. > > I'm a RHEL guy; I see that RHEL has installed python by default since RHEL4 > (i.e., many, many years ago). Are there other Linux distros that really > don't install Python by default? This would surprise me. > > I see python on my OS X Lion, and apparently in every OS X since (at least) > Leopard (Tony at Absoft checked for me). > > I don't know about Python+Solaris, but I don't know if we (OMPI) care, either. > > >> IIRC, that was the > >> rationale for allowing perl. Others (e.g., me) had played with using > >> python before, but switched to perl (a) for the prior rationale, and (b) > >> to avoid proliferating language requirements. > >> > >> I happen to like python myself, but believe there is some value in > >> avoiding adding yet another language to our list of requirements. > > > > I (strongly) agree with Ralph. We made a decision (way back in the 1.0 > > timeframe) that we would use perl for a scripting language when absolutely > > necessary. And even at that, I believe we only require Perl for developer > > builds or distribution builds where an assembly file doesn't already exist > > for that compiler. > > I believe that that is still true -- that's one of the reasons I sent around > this RFC (because introducing python at end-user "make" time is a Big Change). > > > I have no problem with the change to generated bindings from a single > > configuration file/set of files, a bit of a problem with that happening at > > at configure / build time on a release distribution (we don't require > > anything other than /bin/sh at configure / build time right now), > > FWIW: the current Bourne shell scripts that generate the use mpi bindings are > pretty... horrible. We have no intention of continuing to use Bourne shell > scripts for future code generation. > > A little more rationale for scripting/generating at "make" time in general: > the problem is that Fortran compiler support is literally all over the map; > it's really not feasible to maintain a single .F90 file with preprocessor > macros to cover all the differences, because some differences require > different coding approaches (e.g., inline in a module vs. separate/individual > .F90 files -- the contents of these two are quite different). > > That being said, we *could* pre-generate all possibilities and ship them all > in a tarball (i.e., only invoke a generator script at developer/make dist > time). Note that that would lead to a bit more complexity, and could lead to > even more than 7 copies in the tarball (7 is pretty much the minimum -- and > that's with very heavy use of preprocessor macros). > > Hence, in a perfect world, we could generate at "make" time only exactly what > the user's Fortran compiler needed. > > > and a > > strong problem with using Python instead of the Perl that we've previously > > agreed we'd use when all other options are unavoidable. > > I'm asking because: > > - the contributor (Craig) has been around for years; he has a proven track > record of maintaining what he has contributed > - the contributor wants to fundamentally advance our Fortran support > - the contributor has a strong preference for Python > - from my anecdotal evidence, Python is pretty ubiquitous these days (is that > wrong?) > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > -- > Joshua Hursey > Assistant Professor of Computer Science > University of Wisconsin-La Crosse > http://cs.uwlax.edu/~jjhursey _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
