I’ve been playing around with https://nono.sh/ , which adds a proxy to the sandbox piece to keep credentials out of the agent’s scope. It’s a little worrisome that everyone is playing catch up on this front and many of the builtin solutions aren’t good.
HN user
synparb
I'm also a long time conda user and have recently switched to pixi (https://pixi.sh/), which gives a very similar experience for conda packages (and uses uv under the hood if you want to mix dependencies from pypi). It's been great and also has a `pixi global` similar to `pipx`, etc the makes it easy to grab general tools like ripgrep, ruff etc and make them widely available, but still managed.
I've added fasthtml (and its dependencies) to conda-forge, so it's available in conda/mamba now.
I use numba quite a bit at work and it's fantastic. I recently, however, did a comparison between numba, cython, pythran and rust (ndarray) for a toy problem, and it yielded some interesting results:
https://github.com/synapticarbors/ndarray_comparison/blob/ma...
Most surprising among them was how fast pythran was with little more effort than is required of numba (still required an aot compilation step with a setup.py, but minimal changes in the code). All of the usual caveats should be applied to a simple benchmark like this.
Another relatively new addition to the python statistical sampler space is Austin[1], that has a lot of similar features to py-spy. I haven't made a direct comparison yet between the two.
It looks like Github, after some push back across various forums, reverted the change and the network graph is back.
I'm actively looking for alternatives since I found this to be a super useful feature in terms of seeing the state of a repository and the relationship between active branches. I've seen https://gitup.co/, but it doesn't have a view that is organized by commit date.
See also this article:
http://www.politifact.com/truth-o-meter/statements/2016/oct/...
Here appears to be the text of that paper:
http://projects.iq.harvard.edu/cces/news/perils-cherry-picki...
And here is a follow-up from the original authors (standard academic back-and-forth):
https://fs.wp.odu.edu/jrichman/wp-content/uploads/sites/760/...
First class multi-dimensional arrays with natural indexing syntax would be a huge draw. You get that in Numpy, Julia, Fortran and it is extremely powerful in terms of expressing the types of operations that are common across many scientific domains.
It's much more entertaining and useful to read about the overhaul from Transit itself: https://medium.com/transit-app/transit-4-0-is-now-live-2329f...
Conda is 100% free and open source, but is developed by Continuum, which is a company (but one that contributes heavily to many of the key components of the open-source pydata/scipy ecosystem, and whose CEO basically created numpy/scipy for the community at the expense of his academic career). Personally I have had nothing but good interactions with people from Continuum and the software they develop. They (as a company and as the individuals in it) do an incredible amount for the open source community and we all benefit from that. They seem to have worked out a sustainable model for running a company and working in/contributing to open source.
The actual package distribution/management (it is also a replacement for virtualenv) is conda (http://conda.pydata.org/). Since it can be confusing, the difference between conda, anaconda and miniconda is described here: http://conda.pydata.org/docs/faq.html#general-questions
You should also check out https://conda-forge.github.io/, which is building high quality, community curated conda packages for a lot of stuff that isn't available from the main Continuum channel.
While I still think it a bit unfair, the exact quote is "...but to a first approximation, no one is using it". So I think (assuming fijal's numbers of 0.5-1% are roughly correct) it is not completely unreasonable to say that PyPy adoption is very limited to date, which was the point of what he was saying (although I think it could have been said more diplomatically).
I tried looking on the Moore Foundation website and the grant wasn't listed yet. Here's one to Numfocus though from last year: https://www.moore.org/grantee-detail?granteeId=2114
I'll echo @dagw's comments. Cython has been rock solid for me for a long time and it is my go to for any sort of external c/c++ library interfacing. That said, I find myself using Numba more and more in the places that I can as Numba has gotten significantly better in the last 6 months or so. It's still not a complete replacement for cython (and I don't think it ever will or intends to be), but for hot spot numerical calculations it's really nice since it's much faster to test things out since it doesn't involve the boiler plate required by Cython, and doesn't require the (often slow) compilation times.
In Numba 0.21.0, on-disk caching of jit'd code was also introduced, which was one of the major sticking points for us to put Numba into production in areas where we needed faster start-up times. Before we could really only use Cython because we required the start-up times available only from AOT compilation.
That all said, Numba has been a bit buggy for me at times, although these get squashed pretty quickly. I've only found a single bug in Cython in all of the years I've been using it, and it's amazing how quickly Robert Bradshaw or Stefan Behnel respond and fix things considering Cython is not their full time job.
pyvim (https://github.com/jonathanslenders/pyvim) is also a pretty slick vim clone in python that uses the python prompt toolkit (https://github.com/jonathanslenders/python-prompt-toolkit)
Here is a simple example I just threw together of calling a Rust function from within Cython: https://github.com/synapticarbors/rust-cython-test
I use cython extensively in my work and it's super productive for me as well, but I could see maybe toying with Rust more in the future for some really specialized things.
Could you point to a link about how to seamlessly plug Julia into the jvm? I haven't seen any documentation or examples.
Julia also adopted this syntax, and I'm not sure if I like it. In numpy at least, I find myself doing element-wise multiplication much more frequently than matrix multiplication, so '.*' always feels clumsy. I'd rather have special syntax for the matrix multiply (and I was a long time matlab user before moving to numpy).
A %*% B != A @ B
I remember there being talk of eventually being able to call Julia from within Python. I've also been quite happy using Numba as an alternative to Cython for some things when I need speed. It's a lot more light-weight with less boilerplate, although still a little rough around the edges.
Another suggestion would be for Github to offer more generous academic accounts. Currently it looks like they offer free micro accounts (5 private repos) for students, but I think scientists would be more apt to use Github if they offered unlimited private repositories to any academic users. This would match Bitbuckets current academic offerings.
Although I would say in academia I've seen a rapid expansion of Python as both a Matlab replacement and for doing non-HPC work, at least in the field I work in (computational chemistry and biomolecular simulation).
There is also Seaborn: http://stanford.edu/~mwaskom/software/seaborn/index.html
and Vincent: https://github.com/wrobstory/vincent
Also the code examples given on AstroML to work well for figuring out how to make publication quality figures in Matplotlib: http://www.astroml.org/book_figures/
I feel like http://aspen.io/ sort of does something like this already. Written in Python and just uses the filesystem to generate content rather than a MVC.
I attempted to implement the Julia technique in Cython using BLAS dgemm but was not able to beat Jake's original version. Not sure if I am doing something wrong or linking against a non-optimal BLAS library on my machine. Comments/feedback is welcome:
This has been my experience as well for "real world" tests, although I'm still excited about the project. I think once they get a graphical annotate in place akin to `cython -a`, this will help quite a bit in terms of figuring out what is going on.
I think Jake was pretty straight forward in saying in the post that he isn't a fortran expert and was looking for someone to offer up a better version if he was doing something non-optimal.
Not that Julia ever misrepresented/misused a language in a benchmark on its front page, say like calling pure python code numpy. . . . (http://web.archive.org/web/20120215054907/http://julialang.o...)
Also, thanks for sharing the Julia distance links. The explanation of how the speed-up is achieved is really useful:
https://groups.google.com/d/msg/julia-dev/hd1beLPrsVk/6n88H_...