On Fri, May 25, 2012 at 1:25 AM, Joachim Durchholz <[email protected]> wrote: > Am 25.05.2012 05:22, schrieb Aaron Meurer: > >>> I meant functools. They have several new functions that make it easier to >>> work with parameter lists. >> >> >> Which ones specifically do you want to use, and what for? > > > Ah, I have discontinued work on that one, due to other factors, so I'd have > to dig the details up. It's just one example of the many things listed on > http://docs.python.org/whatsnew/2.6.html . > Heh. I even got the module name wrong, it wasn't functools, it was inspect. > I used getargspec (I think). Then I found out these functions are > unavailable in 2.5 and that I had to use a lower-level API from inspect and > had to rewrite the entire error handling code path (which was a bit large > even before that). > > >>> 100%. It's just another option to be 3-compatible. >>> Might help in those cases where 2to3 gives us grief (this tends to crop >>> up >>> in the mailing list occasionally). >> >> >> The main addition of Python 2.6 was the 2to3 conversion tool, which we >> use. But actually it doesn't matter what version has it, because we >> only use it for development, not at run time (and indeed, it's better >> to use the version of 2to3 from Python 3.2 if you can). > > > In that case, 2to3 is an even less preferrable alternative than I thought. > > I guess the workflow document needs a section on Python version anyway. It > should be mentioned that 2to3 cannot be run from a 2.5 environment. > Seems that best practice is: > - develop in 2.6 or 2.7 > - if you test 3.x: > - run 2to3 in 3.2 (is the 2.7 2to3 better than the 3.1 one?)
I don't remember the details, but I think the Python 3 one is faster and the Python 2.6 one has some bugs that due to Python's silly bug fix policy will not be fixed. I could have some of those facts wrong, though. You shouldn't have to worry about it, though, because if you run ./bin/use2to3 that uses Python 3, thanks to the shebang line. > - run the tests in whatever of 2.5/2.6/2.7/3.1/3.2 you have installed > > BTW I found out that tox sits on top of virtualenv, it's not an alternative. > So I guess it's adding enough value to be worth installing it. > > My current plan is to do a writeup of "how to run the test suite", and add a > section to the workflow document. (Which has become far too long and is > serving different purposes, so I'm also thinking about splitting it up.) That would be fine. Also, figuring out how to make section links (i.e., the table of contents) work correctly in GitHub's wiki would help a lot. > > >>> However, this is easier said than asserted. Anybody running SymPy over >>> the >>> web might expose security problems of Python 2.5 to an arbitrary >>> attacker. >>> So to the very least our instructions for setting up a SymPy console on >>> the >>> WWW should carry a warning that 2.5 is a no-no for that usage. (If we >>> don't >>> add that warning, we'll risk a mention of SymPy in a CVE report. That's >>> not >>> the kind of publicity we want.) >> >> >> But if this happens it's the fault of the web developer for using the >> unsupported version of Python, not ours. > > > We should not set up things in a way that invites a security hole. > > This is the reason why there are circuit breakers in doors that give access > to moving parts of machinery, "are you sure" confirmation dialogs, > protecting caps over self-destruct buttons. > PHP has been violating this with reckless abandon, which is why PHP software > tends to be such a festering hole of security problems. > > To the very least, the docs that describe setting up SymPy on the WWW should > explicitly warn against using 2.5. And that warning must be updated whenever > a Python versions stops getting security fixes. > (I'm administering an Internet server, so security threats tend to loom big > from my perspective, more appropriate or not.) > > >> We support (and always will >> >> support) the most recent version of Python and all major versions down >> to our lowest version (with the exception of Python 3.0), so SymPy >> cannot be an excuse for not using a newer Python version. > > > It could be said > > >> On the other hand, what does happen very often is that someone is >> forced to use an older Python version on a machine they either don't >> control or don't wish to control (e.g., some super conservative linux >> repo that runs old versions of all it's software). >> >> For example, I've jailbroken my iPhone, and using Cydia I've installed >> Python and git, and with those, SymPy. The version of Python on >> Cydia is 2.5.1. It's a rather obscure package as far as Cydia goes, >> so I'm not sure how soon it will be updated. > > > Urk. > > Have you tried Python for iOS? ( http://pythonforios.com/ ) I haven't personally downloaded this app, but I've seen it. Actually, it seems that it comes with SymPy. I don't know how many other non-standard library libraries it comes with (SymPy is the only one mentioned in the description), but it seems that SymPy is a selling point for it. At least three of the screen shots on the App Store show SymPy being imported and "sympy.__version__" being called (it has 0.7.1) > It's even in the Appstore, so I guess it's approved and everything and > doesn't need a jailbreak. > Requires iOS 5.0 or later, I don't know how much that restricts it. > > >> Now, don't get me wrong, I'm not saying we should keep supporting >> Python 2.5 because that's the version on Cydia, or even that we should >> keep supporting Python 2.5. All I'm saying is that we should try to >> determine if people are still using it and can't upgrade before we do >> drop it, especially since (to me at least) the benefits of dropping it >> are somewhat small. > > > +1 > > >> By the way, Mac OS X 10.5 shipped with Python 2.5, and Mac OS X 10.6 >> shipped with Python 2.5 and 2.6. Just to give you an idea. Mac OS X >> 10.6 was released in August 2009, so anyone who bought a Mac computer >> before than and didn't bother upgrading the OS or installing Python >> has Python 2.5. >> >> It may sound esoteric, but I'm willing to bet that there are a lot of >> schools out there with computers that are at least that old, and >> un-upgraded, for example. > > > Yes, the Apple ecosystem has a bad policy on security upgrades, too. That's because you have to balance security upgrades with compatibility. If you take Python code that's written specifically for one version and drop it on the next version, unless it was also tested on that version too, there's a pretty good chance it won't work. The chances of this go up by a lot when you start talking about entire libraries (like SymPy). If this wasn't true, then everyone would be using Python 3.2 right now. By the way, their policy isn't so bad. They dropped Python 2.5 support in Mac OS X 10.7 (the most recent version). I couldn't find at what point Python 2.5 stopped being supported, but I imagine it was at some point between the two Mac OS X releases, if not later. > > Well, maybe it's really not feasible. > > OTOH now that Macs are starting to get targetted by malware authors, maybe > they're going to upgrade Python. They have. The latest version of Mac OS X comes with the latest versions of Python, 2.6 and 2.7. It doesn't come with Python 3, but that's a porting issue, not a security one. Mac OS X 10.6 didn't ship with Python 2.7 because Python 2.7 hadn't been released yet at that point (Python 2.7.0 final was released in July 2010). > Running system scripts with an interpreter that has known unfixed bugs is > just inviting a privilege escalation, so if Apple ever gets their act > together, Python will be among the first things in the upgrade pipeline (and > possible one of those that take longer, so I'm still not holding my breath). This talk of security is pointless. As far as I'm concerned, the decision to keep or drop Python 2.5 support boils down to two questions: - Do our users use Python 2.5, without the ability to upgrade? - Are there sufficient new feature in Python 2.6 to warrant isolating any such users? So far I haven't seen any data on the first question (which is admittedly hard to get), and have seen little actual use cases that give a strong argument on the second question. Once again, I don't actually oppose or support dropping Python 2.5 support yet at this point. This is the right time to start thinking about it, though, because we will hopefully release soon (I'll start another thread about that tomorrow), and as I said, it would be nice to warn users about these things in our release notes like we did with Python 2.4 and SymPy 0.7.0 (I misspoke earlier by the way. SymPy 0.7.0 was the last version to support Python 2.4). If there are any SymPy users out there who want to make the case for keeping Python 2.5 support a little longer, now's the time to do it. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
