Hi there,
On Mon, Jun 4, 2012 at 4:27 PM, holger krekel wrote:
> I am wondering, however, how many people really have that py2/py3 need
I'm not sure that's precisely the right question, as you indicate
yourself already:
> OTOH,
> a good solution could trigger needs - that's how a lot of techno
Hey Armin,
Cool, having a shared GC and a shared JIT would be pretty neat features indeed!
Regards,
Martijn
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Hi there,
On Thu, May 31, 2012 at 11:18 PM, holger krekel wrote:
> After all, this is only an intermediate solution until
> everthing happily runs on Python3 anyway, right? ;)
Well, I'm more thinking about it as a means to get to such a
situation, not as an intermediate solution. If you have an
On Thu, May 31, 2012 at 11:12 AM, holger krekel wrote:
> Hi Martijn,
>
> On Wed, May 30, 2012 at 19:24 +0200, Martijn Faassen wrote:
>> Hi there,
>>
>> Just throwing in my little bit: any change that is made that would
>> make it easier to run Python 2 and
Hey,
> Can you describe what sort of semantics you have in mind?
Sure, I've discussed them before. The goal would be to have a Python 3
based project and use Python 2 modules/packages,
or the other way around. That way it should become much easier to
adopt Python 3, even in existing projects. To
Hi there,
Just throwing in my little bit: any change that is made that would
make it easier to run Python 2 and Python 3 interpretors in the same
process would interesting, as I'm still vaguely dreaming (nothing
more) of a combined interpreter that can run both Python 2 and Python
3 code.
Regards
Hey there,
On Tue, May 1, 2012 at 11:27 AM, Armin Rigo wrote:
> * First question: 'transaction'. The name is kind of bogus, because
> it implies that it must be based on transactional memory. Such a name
> doesn't make sense if, say, you are running the single-core emulator
> version. What the
Hey,
On Sat, Feb 18, 2012 at 11:20 AM, Stefan Behnel wrote:
> Amaury Forgeot d'Arc, 18.02.2012 10:08:
>> I made some modifications to pypy, cython and lxml,
>> and now I can compile and install cython, lxml, and they seem to work!
>>
>> For example::
>> html = etree.Element("html")
>> bod
Hi there,
On Sat, Feb 18, 2012 at 10:56 AM, Maciej Fijalkowski wrote:
> I somehow doubt it's possible to make this run fast using cpyext
> (although there are definitely some ways). Maybe speeding up
> ElementTree would be the way if all we want to get is a fast XML
> processor? I doubt this is
Hey,
http://wiki.cython.org/enhancements/pypy
Nice overview of the discussion so far as far I could follow it. I
hope others contribute!
Regards,
Martijn
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Hey,
On Tue, Feb 14, 2012 at 4:28 PM, mark florisson
wrote:
[snip]
>> There is no way to map that to Python unless you use something like
>> ctypes (but ctypes is not considered to be right for this purpose).
>
> Why is ctypes not right? Cython could actually generate a C function
> with a known
On Tue, Feb 14, 2012 at 4:19 PM, Armin Rigo wrote:
> Hi Martijn,
>
> On Tue, Feb 14, 2012 at 14:47, Martijn Faassen wrote:
>> But Cython-based code does talk to C APIs, so there is a problem.
>> Python code in PyPy needs to be able to interface with C APIs first in
>>
Hi there,
So if I understand the direction of this discussion correctly, it is
suggested that to interface PyPy with Cython in a non-hackish way the
best strategy might be to modify Cython to generate Python code. This
way, there's no need to expose all sorts of PyPy internals on a C API
level, an
Hey,
Thanks guys for bringing the discussion back on track!
Regards,
Martijn
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Hi Stefan, others,
I've recommended to Maciej to take this discussion off-list with
Stefan. I think a few mailing list etiquette mistakes were made in
this discussion so far. I don't think this is worth a flame war and
it's in my interest if you both work it out - Stefan's contributions
added to M
Hey,
On Sat, Dec 10, 2011 at 12:20 AM, Armin Rigo wrote:
> On Fri, Dec 9, 2011 at 23:55, Martijn Faassen wrote:
>> Yes, I figured merging would be the main benefit, that makes sense.
>> Hopefully it can be made to work in parallel with the Python 2
>> implementation eventua
Hey,
On Fri, Dec 9, 2011 at 6:27 PM, Armin Rigo wrote:
> On Fri, Dec 9, 2011 at 17:57, Martijn Faassen wrote:
>> Oh, I was assuming that PyPy would have one branch supporting both
>> python 2 and python 3. Is that currently not the case? What are the
>> reasons behind n
Hi there,
Armin:
> like what you would get if you imported in the same Python both the
> "default" and the "py3k" branch (with the proper amount of import
> hacks to keep them from conflicting).
On Fri, Dec 9, 2011 at 4:50 PM, Amaury Forgeot d'Arc wrote:
> I was thinking of two object spaces wi
Hi there,
On Fri, Dec 9, 2011 at 4:18 PM, Bengt Richter wrote:
> PMJI, but I was thinking that if you had both py272 and py3k modules it
> would seem
> natural to keep them in separate directories,
True, I imagine you'd normally give them different module names. The
standard library however is
Hey,
On Fri, Dec 9, 2011 at 2:36 PM, Amaury Forgeot d'Arc wrote:
> 2011/12/9 Armin Rigo
>>
>> Getting two completely separate interpreters in one process is trivial
>> in PyPy
> Well, not so trivial; I played with this idea last evening.
Awesome! I'm glad someone who actually sounds like he kn
Hey Armin,
Thanks for your response!
On Fri, Dec 9, 2011 at 12:31 PM, Armin Rigo wrote:
> On Thu, Dec 8, 2011 at 20:12, Martijn Faassen wrote:
>> Anyway, separate from the binding, I'm wondering about the challenge of two
>> Pythons in one runtime - how hard would it be t
Hey Stefan,
On 12/08/2011 01:54 PM, Stefan Behnel wrote:
So, assuming that Martijn was actually referring to legacy code, I agree
that it won't solve the problem at hand. But that doesn't mean it would
be impossible to benefit from it.
Not sure what you mean here - I was referring to using ex
Hey,
On 12/08/2011 11:35 AM, Alex Gaynor wrote:
I don't think it can, or should be done, here's why: Say you have a
Python 2 dictionary {"a": 3}, and you pass this over to py3k land, what
does it become? Logically it becomes a {b"a": 3}, two problems: a) it
now has bytes for keys, which means
Hi PyPy folks,
I've said so before in comments on your blog, but much kudos to the
project, you guys have been doing a great job! Some time ago I tried
PyPy against an artificial life experiment of mine which implemented a
simple stack-based language in Python and was pleasantly surprised to
24 matches
Mail list logo
