Which source files/functions/line numbers should I take a look at, as
specifically as possible?
On Tue, Jul 31, 2012 at 9:55 AM, Maciej Fijalkowski wrote:
> On Tue, Jul 31, 2012 at 3:41 PM, Steven Jackson
> wrote:
> > I am definitely open to working on Numpy first, my only hesitation was
> that
Hi Ronny (2012.07.31_17:12:15_+0200)
> i would dare to say that Distributions that manage semi-compatible,
> but distro specific "forks" of open source projects
> instead of aiming for a distro compatible upstream
> create quite some grief for developers.
Weighed up against making grief for users.
Hi,
i would dare to say that Distributions that manage semi-compatible,
but distro specific "forks" of open source projects
instead of aiming for a distro compatible upstream
create quite some grief for developers.
after all users don't tend to notice those incompatibilities,
but it breaks the
Hi Armin (2012.07.31_16:26:50_+0200)
> My point of view is that this goes in the same pack of
> incompatibilities introduced by some distributions as splitting the
> install path (which we recommend to install as one block in
> /opt/pypy-1.9).
Most distros won't use /opt. We tend to follow the FHS
Hi Stefano,
On Tue, Jul 31, 2012 at 1:34 PM, Stefano Rivera wrote:
> And I do my best to minimize that. In this case, I thought it was worth
> the delta.
My point of view is that this goes in the same pack of
incompatibilities introduced by some distributions as splitting the
install path (which
On Tue, Jul 31, 2012 at 3:41 PM, Steven Jackson
wrote:
> I am definitely open to working on Numpy first, my only hesitation was that
> it might be hard to get spun up, and scipy seemed like something I could
> slice off and do (some of) by myself without accidentally conflicting with
> ongoing dev
I am definitely open to working on Numpy first, my only hesitation was that
it might be hard to get spun up, and scipy seemed like something I could
slice off and do (some of) by myself without accidentally conflicting with
ongoing development efforts.
If, as your replies have indicated, Numpy isn
I believe the reason is that they prefer to focus the development
effort into the more "basic" Numpy and from that go on. Numpy is not
fully implemented
I am working (actually, right now I am only in the "thinking" state)
on some modules of NumPy, maybe we could coordinate and give this a
boost.
Hi Steven.
Thanks for getting to us about it.
On Tue, Jul 31, 2012 at 1:25 PM, Steven Jackson
wrote:
> I know there is no current plan to implement scipy in pypy, but searching
> the PyPy website, I was not able to find the reason.
>
> If it is not to be included as a feature due to lack of inte
Hi Christian (2012.07.31_13:05:48_+0200)
> >vaguely inline
Hrm, I never finished that sentance, because I went back and made the
point earlier in the mail.
> Your backport makes sense, but the reasoning should be identical
> between cpython and pypy.
> If cpython does not do it, pypy does not do
I know there is no current plan to implement scipy in pypy, but searching
the PyPy website, I was not able to find the reason.
If it is not to be included as a feature due to lack of interest or
developer time, I am offering to begin rewriting scipy in pure python (I
have quite a bit of free time
On 31.07.12 12:35, Stefano Rivera wrote:
Hi Armin (2012.07.31_12:10:01_+0200)
I think that PyPy shouldn't do that, because CPython doesn't. If
Debian/Ubuntu also hacked CPython to do that, then fine; we are then
free to point users to them (blame them?) for issues :-)
We did seriously consider
On Tue, Jul 31, 2012 at 12:35 PM, Stefano Rivera wrote:
> Hi Armin (2012.07.31_12:10:01_+0200)
>> I think that PyPy shouldn't do that, because CPython doesn't. If
>> Debian/Ubuntu also hacked CPython to do that, then fine; we are then
>> free to point users to them (blame them?) for issues :-)
>
Hi Armin (2012.07.31_12:10:01_+0200)
> I think that PyPy shouldn't do that, because CPython doesn't. If
> Debian/Ubuntu also hacked CPython to do that, then fine; we are then
> free to point users to them (blame them?) for issues :-)
We did seriously consider hacking cpython to do that, before in
Hi Stefano,
On Tue, Jul 31, 2012 at 11:44 AM, Stefano Rivera wrote:
>> PyPy contains no logic to create or search for __pycache__. A grep
>> tells me that neither does CPython 2.7.
>
> A Debian/Ubuntu pypy does, though.
I think that PyPy shouldn't do that, because CPython doesn't. If
Debian/Ub
Hi Armin (2012.07.31_09:25:08_+0200)
> PyPy contains no logic to create or search for __pycache__. A grep
> tells me that neither does CPython 2.7. You are probably confused by
> py.test creating them.
A Debian/Ubuntu pypy does, though. And IIRC, that's what travis CI is
using.
It's the pep3147
Hi Marcus, Armin,
On Tue, Jul 31, 2012 at 09:25 +0200, Armin Rigo wrote:
> Hi Marcus,
>
> PyPy contains no logic to create or search for __pycache__. A grep
> tells me that neither does CPython 2.7. You are probably confused by
> py.test creating them.
... creating them during a pypy test run
Hi Marcus,
PyPy contains no logic to create or search for __pycache__. A grep
tells me that neither does CPython 2.7. You are probably confused by
py.test creating them.
A bientôt,
Armin.
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.pyt
18 matches
Mail list logo
