iguananaut

If I had the funding to do so, I would love to improve use of Sage for computational physics, particularly for particle physics and QFT. It would be great if Sage could serve easily as a full replacement for Mathematica in those areas, but currently lacks some library support.

FWIW, although there are no binary releases that include Python 3 yet, if you build from scratch with ./configure --with-python=3 you can use Sage with Python 3 and you'll find that the vast majority of stuff works (though with no promises).

No, the goal is to have it actually in Debian. One argument that's been made against this is that Debian moves to slowly, and an old (but supported!) version of Sage is not useful to its current core user base of research mathematicians who often need the bleeding edge and/or are developing new code directly in Sage.

My counter argument is that we want to expand Sage's user base beyond a small core of researchers, and improve its usability as a Mathematica replacement for students and some scientists who are less interested in things like bleeding edge combinatorics research (they might be but not necessarily the majority). As a Mathematica replacement Sage isn't there yet, but it's good to get a head start on making easier to package and install, as part of that effort. Like for me, if it can solve some differential equations for me and do some integrals I don't care if the version I got through apt is a couple years old.

As for the upstream issues part of the problem there is that some of the upstream dependencies of Sage refuse to accept patches needed for them to integrate with Sage. That's a long story. I think the best approach there, which has already been tried in past approaches to patching for Debian, is to maintain Sage-specific forks of that software that include the necessary patches (IMO they should also be swappable with the originals via update-alternatives if possible). As far as I know there's nothingf legally preventing that, but more the effort involved in maintaining a fork and a package for that fork.

In the long term, I think, it would make sense to completely replace and rewrite some of the code that these external dependencies are used for. But in many cases there's an enormous amount of work involved, and that would only be possible with significant funding. And quite possibly not worth the effort compared to other ways that effort could be spent.

The good news on that front is most of the problem is not Sage itself but some of its dependencies. Of course some of the problem children are core dependencies and can't just be made optional. But fast progress is being made. I have most of Sage running on Windows, currently with an unfortunate Cygwin dependency. However I have hopes to work on native Windows ports of some of the trickier dependencies, notably GAP and Cysignals.

"Sage upstream (you) does have to change some of its practises"

This is also being worked on and there's progress being made.

I'm still pushing to completely separate Sage-the-library from Sage-the-distribution. There's been a little pushback but nothing that can't be overcome with basic configuration management practices.

I'm actually one of the few people being paid to work on Sage, and this is one of the tasks I have interest in.

Although my personal work is more focused on Windows support for the time being, this is definitely on the docket. We had a workshop about two months ago in France focused specifically on packaging Sage, and there are some excellent folks from LogiLab who are making serious progress on the Debian packing. I hope to circle back around to that myself after I've made more progress on Windows.

bpython is a very nice lightweight replacement for the standard Python interpreter. Nothing but <3 for bpython. But it's not really comparable in scope and capabilities to IPython; the latter is much more heavy-weight but for myriad good reasons.

As other replies have already eluded, this isn't really comparable to JavaScript. Also good luck crunching huge datasets on clusters from within your browser with a pure JavaSCript implementation.

The difficulty that you're having wrapping your brain around the concept of empathy is good evidence that that assumption should not be made for conference attendees.

That said, these policies are not even about you. They're there so that people who might be victims of harassment can feel safe in the knowledge that there are procedures in place for addressing it in the rare event that it occurs, and that conference organizers will take it seriously. That benefits everybody too. Don't assume you will never be harassed. I'm a straight white male and I have been made to feel unsafe and uncomfortable before by another person, at PyCon even. I'm not an emotionally fragile glass doll that you and others in this thread seem to be strawmanning. It really doesn't take much to be made to feel unsafe by another person's behavior. If you've never experienced that yourself it's because you simply aren't as likely to as other people.

In my case it was minor enough, and I felt in enough control that it wasn't worth reporting. But I'm glad to know I could have done something about it had things escalated.