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
