headers
Armin Rigo | 1 May 2005 13:55
Favicon

A saner directory structure

Hi all,

Sorry for Yet Another directory structure reorganization.  This one shouldn't
have too much effects.  Its purpose was to clean up the mess of pypy/lib/,
which prevented most tests from running at all.

Now, we have:

    dist/pypy/lib/
        Used ONLY for complete pure Python reimplementation of modules.
        The test2 subdirectory just contains regular tests for these.
        These tests run on top of CPython, and are meant to check that
        the reimplementations are correct, independently of PyPy.

    dist/lib-python/2.3.4/
        The unmodified CPython library (used to be lib-python-2.3.4).

    dist/lib-python/modified-2.3.4/
        The files and tests that we have modified from the CPython library.

PyPy runs with sys.path set to

  [... lib-python/modified-2.3.4, lib-python/2.3.4, ...]

so that the modified-2.3.4 directory shadows the 2.3.4 one.  There is a 'test'
package in modified-2.3.4; all the files put there shadow the corresponding
file from 2.3.4/test.  (We use the standard pkgutil module to give the
illusion of a 'test' package that contains all files from both
modified-2.3.4/test and 2.3.4/test).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Hallen | 1 May 2005 17:02
Favicon

Pypy talk at Europython

I assume that we will want to have a Pypy presentation at Europython.

Official last day for submissions is today, though I will be extending the 
submission time for a few days due to some technical problems with the 
submission software, and some technical problems with Strakts Internet 
connection during the weekend.

Who will make the submission?

Jacob
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 1 comment |
headers
holger krekel | 1 May 2005 17:14
Favicon

Re: Pypy talk at Europython

Hi Jacob, 

On Sun, May 01, 2005 at 17:02 +0200, Jacob Hallen wrote:
> I assume that we will want to have a Pypy presentation at Europython.
> 
> Official last day for submissions is today, though I will be extending the 
> submission time for a few days due to some technical problems with the 
> submission software, and some technical problems with Strakts Internet 
> connection during the weekend.
> 
> Who will make the submission?

Armin is scheduled to prepare the submission which will be a talk
mainly about pypy's evolving low level code generation backends 
(LLVM and C in particular).  Although i am now wondering if we 
shouldn't also say a few words about the then-to-be-released 
first PyPy version ...  

We discussed that at least Armin and Carl, and quite possibly
Samuele and Christian (and maybe me with an introduction, talking
a few words about the release) will be giving the talk. 
That probably means we wouldn't mind getting a 60 minute or at
least a 45 minute slot. 

cheers, 

    holger
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Chrigström | 2 May 2005 15:08
Favicon

Re: new unicode checkins / announcing branches

holger krekel wrote:

> i noticed that both of you are doing unicode related 
> checkins.  Could you make sure that you are not 
> duplicating efforts?  

Will do.

> In general, i think it's a good idea to advertise 
> new branches (like the nice "non-fake-unicode" one) 
> on pypy-dev. Better redundant than sorry. 

I appologize for what confusion my clam-like behaviour
has caused. I will be more verbose in the future.
The named branch is where I currently develop the unicode type
and other unicode related stuff (e.g. the unicodedata module).
I plan on having this work complete enough for merging back into
the trunk this week or early next week.

> Um, and does one of you have a nice nickname? :-) 

You can use 'Arre' for me.

Happy hacking,
	/Arre
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Rigo | 3 May 2005 20:02
Favicon

Builtin-in functions

Hi all,

Builtin-in functions differ from Python function in that you can't bind the
former as methods.  We are discovering more and more of cases like that:

class Stuff:
    defaultComparison = cmp

where self.defaultComparison(x,y) is expected to work.  Instead, in PyPy, cmp
is then called with three arguments: self, x, y.

The problem is the number of cases we keep finding all around.  I think that
Guido said it was an internal undefined detail, but clearly a lot of people
depend on it, so we're stuck.

Samuele came up with a nice proposal: the attribute loading code of LazyModule
(i.e. our internal modules) is a natural place to turn our functions into some
kind of built-in functions.  It will turn exactly the function into built-in
ones and leave alone, e.g., the methods of class complex -- which need to be
boundable to their complex instance!

The proposal is thus to wrap functions into a <type 'builtin_function'> which
behaves mostly like the original one, but doesn't have a __get__().

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
(Continue reading)

Permalink | Reply | 1 comment |
headers
holger krekel | 3 May 2005 21:22
Favicon

Re: Builtin-in functions

Hi Armin, 

On Tue, May 03, 2005 at 19:02 +0100, Armin Rigo wrote:
> Builtin-in functions differ from Python function in that you can't bind the
> former as methods.  ... 
> 
> Samuele came up with a nice proposal: the attribute loading code of LazyModule
> (i.e. our internal modules) is a natural place to turn our functions into some
> kind of built-in functions.  ... 

Good idea!   

> The proposal is thus to wrap functions into a <type 'builtin_function'> which
> behaves mostly like the original one, but doesn't have a __get__().

And i see you already hacked this, nice. 

For all the others: PyPy is now passing more than 80% of the 
core python language tests now, see here: 

    http://codespeak.net/~hpk/pypy-testresult/

cheers, 

    holger
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
holger krekel | 4 May 2005 14:55
Favicon

Re: [pypy-svn] r11817 - in pypy/dist/pypy/lib: . test2

Hi Anders, 

also for the sake of others a public comment on 
your checkin. 

On Mon, May 02, 2005 at 21:32 +0200, ale <at> codespeak.net wrote:
> Author: ale
> Date: Mon May  2 21:32:31 2005
> New Revision: 11817
> 
> Added:
>    pypy/dist/pypy/lib/test2/test_codeccallbacks.py

This is not the right place to add modified CPython's 
regression tests anymore.  Modified regression tests should 
go to 

    lib-python/modified-2.3.4/test/

and they should be copied from the non-modified 2.3.4 
directory instead of simply adding them, btw. This allows
us to trace the history of the modified file much better
(a simple 'svn log test_codeccallbacks.py' shows where
it came from. 

The pypy/lib/test2 directory should only contain interpreter
level tests that can load our pypy/lib implementations simply
like so: 

    from pypy.lib import _codecs  # this should just work when
(Continue reading)

Permalink | Reply | 2 comments |
headers
holger krekel | 4 May 2005 22:27
Favicon

importing modules from pypy/lib

On Wed, May 04, 2005 at 14:55 +0200, holger krekel wrote:
>     from pypy.lib import _codecs  # this should just work when
>                                   # run with test_all.py /
>                                   # py.test 

This is actually currently not true, but should be true
in my opinion.  Armin, i see you have done some hack
in pypy/lib/test2/support.py to import modules from 
pypy/lib.  Is this still warranted?  

cheers, 

    holger
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 1 comment |
headers
Armin Rigo | 4 May 2005 23:04
Favicon

Re: importing modules from pypy/lib

Hi Holger,

On Wed, May 04, 2005 at 10:27:48PM +0200, holger krekel wrote:
> (...)  Armin, i see you have done some hack
> in pypy/lib/test2/support.py to import modules from 
> pypy/lib.  Is this still warranted?  

No, you're right.  We could 'import pypy.lib.imp' and avoid the problem that
'import imp' always get the built-in module and never imp.py in CPython.

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
holger krekel | 7 May 2005 10:17
Favicon

Re: [pypy-svn] r12035 - in pypy/dist/pypy: interpreter objspace/std

Hi Armin, Hi Samuele, 

On Sat, May 07, 2005 at 00:12 +0200, arigo <at> codespeak.net wrote:
> Author: arigo
> Date: Sat May  7 00:12:16 2005
> New Revision: 12035
> 
> Modified:
>    pypy/dist/pypy/interpreter/function.py
>    pypy/dist/pypy/interpreter/pycode.py
>    pypy/dist/pypy/objspace/std/dicttype.py
>    pypy/dist/pypy/objspace/std/fake.py
>    pypy/dist/pypy/objspace/std/floattype.py
>    pypy/dist/pypy/objspace/std/inttype.py
>    pypy/dist/pypy/objspace/std/listtype.py
>    pypy/dist/pypy/objspace/std/longtype.py
>    pypy/dist/pypy/objspace/std/objecttype.py
>    pypy/dist/pypy/objspace/std/slicetype.py
>    pypy/dist/pypy/objspace/std/stringtype.py
>    pypy/dist/pypy/objspace/std/tupletype.py
>    pypy/dist/pypy/objspace/std/typetype.py
> Log:
> Replace the calls to xyz.__init__() with known calls to
> XyzClass.__init__(xyz).  Avoids annotator surprizes.

When doing such (and other similarly non-obvious) changes 
could you at least add a few lines in the RPython documentation 
trying to pin down the "restriction"?  

cheers,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane