fwiw: macports is at py3.3 On May 22, 2013, at 9:27 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:
> 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/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
