Hi Armin,
I am not trying to force you (or anyone) to use Py3. I have been working on
this in a private branch for a little bit, and I am happy to continue to do
so. As I said earlier in the thread, I had gotten the impression that these
changes would not make you or the other PyPy devs happy, so
I am having some trouble wrapping my head around it. Reading through
rpython/tools/pairtype.py, it looks like it could be one or more of a
number of things:
- An implementation of javascript-style prototypes. (The similarity: you
don't subclass an object in js - you use the base object as a protot
A question came up in the discussion of a pull request: What is the
allowable scope? I propose pypy/ and rpython/ as those are fairly
intertwined.
Comments?
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
A quick overall response: I know that a lot of what I am talking about *is
possible* using RPython. That is one reason why I am starting where I am.
That doesn't necessarily make it easy (or as easy as it could be).
On Thu, Apr 16, 2015 at 11:39 AM, Ronan Lamy wrote:
> Why Py3?: I like Py3 be
Just bundled up a few of the more mechanical changes into a PR and sent it
upstream.
On Thu, Apr 16, 2015 at 8:55 AM, VanL wrote:
> Hi Maciej,
>
> On Thu, Apr 16, 2015 at 3:48 AM, Maciej Fijalkowski
> wrote:
>
>> Hi Van.
>>
>> First of all I'm really so
Hi Maciej,
On Thu, Apr 16, 2015 at 3:48 AM, Maciej Fijalkowski
wrote:
> Hi Van.
>
> First of all I'm really sorry if we ever gave an impression that
> working on porting RPython to Python 3 would not be welcomed and I
> would like to strongly disagree with that.
>
> What we did say (or wanted to
On Wed, Apr 15, 2015 at 11:51 PM, Ronan Lamy wrote:
> 4. At some point in the future, I plan on reworking the rpython
>> toolchain in various ways - use python 3 function and type annotations
>> so as to make the flow of types be easier to see, fully split out the
>> rpython and non-rpython bit
Hi everyone,
For the last little bit I have been working on porting the rpython
toolchain to Python 3. My initial goal is to get either pypy2 or pypy3 to
build with either pypy2 or pypy3.
I had gotten the impression from some previous statements that these
efforts would not be welcome, so I was d
Hi Amaury,
On Fri, Dec 5, 2014 at 9:58 AM, Amaury Forgeot d'Arc
wrote:
> lib_pypy is a portion of the stdlib.
> It contains the modules that CPython implements in C, and that PyPy
> decided to implement in pure Python.
>
> They describe a different version of Python, and have different features.
Hi all,
I’ve been doing some experiments with pypy and I would interested in making
parts of the codebase more 3x compatible. As a first step, I notice that
there are slight differences between the lib_pypy shipped in the 2.7 and
3.2 releases. How would people feel about reducing the duplication b
On 9/21/2011 5:12 AM, Armin Rigo wrote:
Hi Geoffrey,
On Mon, Sep 19, 2011 at 9:40 PM, Geoffrey Thomas wrote:
I'm looking at building a real application using PyPy's sandbox mode, and am
having a harder time than I'd expect finding any examples of people using
the sandbox in the "real world".
On 8/21/2011 2:32 PM, Carl Friedrich Bolz wrote:
Solving the problem of persisting source code is *seriously* hard, and
I agree with Armin, I'm not going to invest any time in it.
One interesting side note: The implementors of v8 decided that the best
and most compact representation of sourc
On Jul 16, 2011 5:13 AM, "Armin Rigo" wrote:
>
> Hi,
>
> On Sat, Jul 16, 2011 at 12:32 AM, VanL wrote:
> > I think that a better (read: closer term, and more likely to be
performant)
> > answer is to create multiple interpreters, *each with their own GIL,
On 7/15/2011 2:31 PM, Maciej Fijalkowski wrote:
I know, this is kind of hand-waving what has to be done, I would
probably start with having two interpreters in one executable,
probably by having two object spaces.
Cheers,
fijal
And if I may ask, what are you trying to achieve?
Two (or more)
On 7/15/2011 1:50 PM, Maciej Fijalkowski wrote:
By design, a single process thing is slightly less secure. If you say
find a way to corrupt random memory, you can modify the other process,
it's still only very slightly though. The sandboxing approach should
work quite nicely, the hard part would
I have a couple questions about the sandboxing feature:
- Currently this is a two-process model, but early on the assertion was
made that this could be done in a single process, perhaps but not
necessarily separated by two OS-level threads. Is this (still?) true?
What would you need to invoke
Thanks for the reply.
On 6/14/2011 10:49 AM, Benjamin Peterson wrote:
2011/6/14 VanL:
Is it possible to create an embeddable libpypy.so/dll? Are there any visible
entry points into code created by the pypy toolchain?
No
In examining this, I noted the translation option -- shared
(http
Is it possible to create an embeddable libpypy.so/dll? Are there any
visible entry points into code created by the pypy toolchain?
Thanks,
Vna
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
18 matches
Mail list logo
