61–70 of 150 posts
Earlier quoted context omitted.
The value of PyPy is that it is a thing you can just drop in to make your code faster. If PyPy wants to gain any traction they pretty much have to concentrate on the version with the most existing code.
most of my existing production code is 3.4, hence my question.
Earlier quoted context omitted.
> But bottom line, tons of python code out there needs more performance and has no dependency on numpy or any C extensions. What they need is nice JIT engines like PyPy and not to switch languages. If no one invested in improving implementations for modern languages and switched to something lower level all the time, we would still be using Fortran for business applications.
We still are using FORTRAN for Business Applications and I fail to see the need to switch them to a slower language to modernize them. Unless the switch is solving a program leave them alone. This is why in R there is still plenty of FORTRAN code. Personally I LOVE Python but I always feel it is the 2nd best choice. I do use Python but it rarely is the best tool to use for the problem you are solving. Maybe Pypy will…
Actually, the time-critical loops are usually implemented in C or Fortran. Much of SciPy is a thin layer of code on top of the scientific routines that are freely available at http://www.netlib.org/. Netlib is a huge repository of incredibly valuable and robust scientific algorithms written in C and Fortran. It would be silly to rewrite these algorithms and would take years to debug them. SciPy uses a variety of methods to generate “wrappers” around these algorithms so that they can be used in Python. Some wrappers were generated by hand coding them in C. The rest were generated using either SWIG or f2py. Some of the newer contributions to SciPy are either written entirely or wrapped with Cython.
A second answer is that for difficult problems, a better algorithm can make a tremendous difference in the time it takes to solve a problem. So using scipy’s built-in algorithms may be much faster than a simple algorithm coded in C.
http://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fast...
> We would also like to thank our contributors (7 new ones since PyPy 2.6.0) and encourage new people to join the project. PyPy has many layers and we need help with all of them This doesn't match my experience of the PyPy project. I found a tiny bug in the stdlib matching against CPython, went into IRC to ask a question about test running to be sure I got it right and was quickly engaged in conversation about why I…
Here's Neovim's "entry-level" label, for example:
https://github.com/neovim/neovim/issues?q=is%3Aopen+is%3Aiss...
Earlier quoted context omitted.
Personally I'd be quite excited to see a bug I reported fixed the same-day - of course people's expectations are different it's not always easy to balance these things.
I can understand that, I certainly would have been stoked about a bug report being fixed on the same day; I hadn't reported the bug though. I was working on providing a bug report with a patch alongside it and (perhaps foolishly) mentioned the bug informally as context as to why I was doing this.
I don't think its reasonable to expect a projects core developers, when they become aware of a bug through mechanisms other than formal bug reports, to deliberately stall confirming and resolving the problem because the person raising the issue is entitled to a crack at fixing it.
python 3.4 please ;_;
In any case the 3.3 branch seemed good when I compiled it last, it'd be nice to see a partial release.
> We would also like to thank our contributors (7 new ones since PyPy 2.6.0) and encourage new people to join the project. PyPy has many layers and we need help with all of them This doesn't match my experience of the PyPy project. I found a tiny bug in the stdlib matching against CPython, went into IRC to ask a question about test running to be sure I got it right and was quickly engaged in conversation about why I…
On the flip side of this thread, some projects have started to adopt specific tagging in their issue systems for folks looking to get started as contributors. I really like this as it's clear communication to both new contributors and to existing contributors that the issue in question is an on-ramp for the project. Here's Neovim's "entry-level" label, for example: https://github.com/neovim/neovim/issues?q=is%3Aopen+…
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
Earlier quoted context omitted.
Personally I'd be quite excited to see a bug I reported fixed the same-day - of course people's expectations are different it's not always easy to balance these things.
One of the rewards of participating in OSS is to make your name visible, this can then be used as creds to gain commit rights or to talk at conferences as well as proof of competence when looking for a job. Interestingly, I've had the same experience when reporting and asking how to contribute to Python 3, not by a core dev but somebody "stealing" my bug and quickly submitting a patch!
Earlier quoted context omitted.
I can understand that, I certainly would have been stoked about a bug report being fixed on the same day; I hadn't reported the bug though. I was working on providing a bug report with a patch alongside it and (perhaps foolishly) mentioned the bug informally as context as to why I was doing this.
> I hadn't reported the bug though. I don't think its reasonable to expect a projects core developers, when they become aware of a bug through mechanisms other than formal bug reports, to deliberately stall confirming and resolving the problem because the person raising the issue is entitled to a crack at fixing it.
Earlier quoted context omitted.
Is this a complaint or a compliment to the developers?
He didn't want to report a bug, he wanted to contribute to the project. I can think of a few reasons why. They lost a new potential committer by "being pragmatic" about it, but ignoring inter-personal relationships, like so often.
Earlier quoted context omitted.
We still are using FORTRAN for Business Applications and I fail to see the need to switch them to a slower language to modernize them. Unless the switch is solving a program leave them alone. This is why in R there is still plenty of FORTRAN code. Personally I LOVE Python but I always feel it is the 2nd best choice. I do use Python but it rarely is the best tool to use for the problem you are solving. Maybe Pypy will…
R != Business Application.