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?)
- 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.)
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/ )
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.
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.
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).
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
