From lac at strakt.com  Sat Mar 13 07:56:31 2004
From: lac at strakt.com (Laura Creighton)
Date: Sat, 13 Mar 2004 07:56:31 +0100
Subject: [pypy-dev] OSCON turned down my proposal for a PyPy interim report
Message-ID: <200403130656.i2D6uVUr025700@ratthing-b246.strakt.com>

Said there were too many good proposals this year.  Maybe
we need a larger Python section, then.

Laura

From nc-jantzegu at netcologne.de  Sun Mar  7 20:18:28 2004
From: nc-jantzegu at netcologne.de (=?iso-8859-1?Q?G=FCnter_Jantzen?=)
Date: Sun, 7 Mar 2004 20:18:28 +0100
Subject: [pypy-dev] Multimethods again
References: <20040217215858.GA5729@vicky.ecs.soton.ac.uk>
Message-ID: <003c01c40478$f94d8410$9cc308c2@Lieschen2>

Hello Armin,

maybe it is already well known, but recently I saw that David Mertz
contributed an article about
(and an implementation of)  multimethods in his famous column "Charming
Python" at
http://www-106.ibm.com/developerworks/linux/library/l-pydisp.html
about one year ago. His work also covers preference policies for unambigious
method resolution

Best regards
G?nter


----- Original Message -----
From: "Armin Rigo" <arigo at tunes.org>
To: <pypy-dev at codespeak.net>
Sent: Tuesday, February 17, 2004 10:58 PM
Subject: [pypy-dev] Multimethods again


> Hello everybody,
>
> I just found out a neat way to do simple multimethods in Python, so I
thought
> I'd share it with you :-)
>
> The following is only for dispatching over two arguments.  The idea is to
use
> a pair(a,b) object that is just like a tuple (a,b), but with methods.  Any
> (regular Python) method that you put in the class of pair(a,b) works like
a
> multimethod dispatching on both a and b.  The metaclass hack is only a
> syntactic convenience.
>
> I don't know if this is relevant to PyPy.  It's probably one of the
shortest
> multimethod implementations for Python, whereas PyPy's is probably one of
the
> longest :-)
>
> Armin
>
> # ______________________________________________
>
> class extendabletype(type):
>     """A type with a syntax trick: 'class __extend__(t)' actually extends
>     the definition of 't' instead of creating a new subclass."""
>
>     def __new__(cls, name, bases, dict):
>         if name == '__extend__':
>             return bases[0]   # return existing base
>         else:
>             return type.__new__(cls, name, bases, dict)
>
>     def __init__(self, name, bases, dict):
>         if name == '__extend__':
>             for key, value in dict.items():
>                 setattr(self, key, value)
>
>
> def pair(a, b):
>     """Return a pair object."""
>     tp = typeofpair(a.__class__, b.__class__)
>     return tp((a, b))   # tp is a subclass of tuple
>
> pairtypecache = {}
>
> def typeofpair(cls1, cls2):
>     """type(pair(a,b)) is typeofpair(a.__class__, b.__class__)."""
>     try:
>         pair = pairtypecache[cls1, cls2]
>     except KeyError:
>         name = 'typeofpair(%s, %s)' % (cls1.__name__, cls2.__name__)
>         bases1 = [typeofpair(base1, cls2) for base1 in cls1.__bases__]
>         bases2 = [typeofpair(cls1, base2) for base2 in cls2.__bases__]
>         bases = tuple(bases1 + bases2) or (tuple,)  # 'tuple': ultimate
base
>         pair = pairtypecache[cls1, cls2] = extendabletype(name, bases, {})
>     return pair
>
> # ____________________________________________________________
>
>
> class A(object):
>     pass
>
> class B(object):
>     pass
>
> class C(A):
>     pass
>
> class D(B):
>     pass
>
> a = A()
> b = B()
> c = C()
> d = D()
> assert isinstance(pair(a,b), typeofpair(A, B))
>
>
> class __extend__(typeofpair(A, B)):
>
>     def add((a, b)):
>         print "a+b"
>
>     def sub((a, b)):
>         print "a-b"
>
>
> class __extend__(typeofpair(C, B)):
>
>     def add((c, b)):
>         print "c+b"
>
>
> # alternate less magic syntax
> def sub((a, d)):
>     print "a-d"
> typeofpair(A, D).sub = sub
>
>
> pair(a,b).add()
> pair(a,b).sub()
> pair(c,d).add()
> pair(c,d).sub()
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev


From DavidA at activestate.com  Sun Mar 21 16:02:36 2004
From: DavidA at activestate.com (David Ascher)
Date: Sun, 21 Mar 2004 16:02:36 +0100
Subject: [pypy-dev] OSCON turned down my proposal for a PyPy interim
	report
In-Reply-To: <200403130656.i2D6uVUr025700@ratthing-b246.strakt.com>
References: <200403130656.i2D6uVUr025700@ratthing-b246.strakt.com>
Message-ID: <405DAE8C.7060400@ActiveState.com>

Laura Creighton wrote:

> Said there were too many good proposals this year.  Maybe
> we need a larger Python section, then.

Lots of good talks were rejected.  It's a chicken-and-egg problem.  The 
more people stuff the Python sections in a given year, the easier it is 
to argue for more time allocated to Python on the +1'th year.

--da

From hpk at trillke.net  Thu Mar 25 13:27:58 2004
From: hpk at trillke.net (holger krekel)
Date: Thu, 25 Mar 2004 13:27:58 +0100
Subject: [pypy-dev] status of PyPy
Message-ID: <20040325122758.GC6332@solar.trillke>

hi pypy-dev, 

just wanted to drop some information about what is currently
going on with PyPy.  Our last sprint took place in Amsterdam
late december and since then most of us were quite busy with 
lots of other stuff and/or with negotiating with the European
Union regarding our accepted PyPy proposal. 

Now the negotiations are still dragging on and we have to 
plan and commit ourselves for two years which is no easy task.  
So we are to invest all the time we can into that because we 
could still loose the contract. 

During the last three month codng mostly took place in peripheral 
parts of pypy, one of them a new testing framework with some 
surprising features but more about that later :-)  These three
month already feel like an eternity ... 

The next big challenge for PyPy is translation into low level 
code.  We had some small breakthroughs (producing efficient 
low-level code for a sieve of erasthosthenes python implementation)
but getting it to work for more complex programs like PyPy
itself remains an open challenge. The next sprint should bring us
a lot closer. 

Speaking of which, i guess we definitely will hold a one-week
sprint before EuroPython, probably starting on 30th of June. 
Please mark that in your calendar.  And make sure that
you don't miss out yet another great python conference 
after Pycon :-) 

Btw, expect some nice report from Armin from Pycon with special
respect to pypy-related topics (he promised it because us other 
people have to deal with EU details).  I can't wait :-) 

There also is the idea that we try to do a sprint around 
Python UK 2004 in April.  No concrete planning has taken place, 
though, because all of us were so insanely busy.  If someone could
help with organizing a PyPy sprint there that would be wonderful! 

so much, for now, have fun,

    holger krekel


From faassen at infrae.com  Fri Mar 26 16:00:50 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri, 26 Mar 2004 16:00:50 +0100
Subject: [pypy-dev] status of PyPy
In-Reply-To: <20040325122758.GC6332@solar.trillke>
References: <20040325122758.GC6332@solar.trillke>
Message-ID: <406445A2.6070403@infrae.com>

holger krekel wrote:
> Speaking of which, i guess we definitely will hold a one-week
> sprint before EuroPython, probably starting on 30th of June. 

30th of may, I assume?

Regards,

Martijn

From hpk at trillke.net  Sun Mar 28 11:33:47 2004
From: hpk at trillke.net (holger krekel)
Date: Sun, 28 Mar 2004 11:33:47 +0200
Subject: [pypy-dev] status of PyPy
In-Reply-To: <406445A2.6070403@infrae.com>
References: <20040325122758.GC6332@solar.trillke>
	<406445A2.6070403@infrae.com>
Message-ID: <20040328093347.GQ6332@solar.trillke>

[Martijn Faassen Fri, Mar 26, 2004 at 04:00:50PM +0100]
> holger krekel wrote:
> >Speaking of which, i guess we definitely will hold a one-week
> >sprint before EuroPython, probably starting on 30th of June. 
> 
> 30th of may, I assume?

yes, thanks, 30th of May is certainly more it.  My brain obviously
hasn't learnt about month-wrap arounds ... 

cheers,

    holger

From arigo at tunes.org  Mon Mar 29 19:18:11 2004
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 29 Mar 2004 18:18:11 +0100
Subject: [pypy-dev] PyCON bits
Message-ID: <20040329171811.GA17842@vicky.ecs.soton.ac.uk>

Hello!

As promized, here are a few bits of news from PyCON...  This isn't a complete
report (there are blogs out there for that).  It's just a few PyPy-oriented
notes.


The sprints: I participated in the Python Core sprint.  There was some lack of
a concrete objective, Guido and Tim Peters didn't show up a lot (I know Guido
was ill).  So people just formed loose groups, changing over the days, doing a
wide range of small stuff.  I did a few bits on performance in CPython and
some core stuff, mostly with Martin von Loewis, who embarked on the cruisade
against start-up time.


Mitchell Kapor's keynote (Using Python to Develop a Large-Scale Open Source 
Application: A Report from the Field): the two main points stressed by 
Mitchell is that Python needs (1) more performance and (2) more security.  
Looks familiar?


IronPython (Jim Hugunin): Python for .NET.  Seems to be very fast, up to 40%
better than CPython.  The trick is to contrieve as much as possible (and
more!) the Python semantics so that they fit into existing .NET built-in
operations.  .NET itself is then able to optimize them extremely agressively.  
The result is generally significantly faster than CPython.

What we could learn from IronPython is how the common cases are speeded up by
a lot of boilerplate "fast-path" code (i.e. there is a 8x8 table for calling a
function with 0 to 7 arguments when the function expects 0 to 7 arguments).  
The other thing we could learn is how to use .NET as a PyPy target platform,
what the tricks and the main limitations are.  But Jim doesn't release code
before he thinks it is finished :-(


Starkiller (Michael Salib): this is a purely static source-to-source
Python-to-C++ translator, which does type inference.  It works by analysing a
graph which closely mirrors the Python source code.  As expected, it has some
trouble with the most dynamic features like exec/eval, but it is relatively
advanced in some directions like OO.  Some control structures (like 'for') are
not implemented.

Bob Ippolito came up with an incredibly cool idea: we can already generate
control flow graphs, which give a low-level pre-processed version of a Python
source; so we should just feed that into Starkiller, which would analyse it
and translate it into C++.  Starkiller shouldn't try to parse the source and
analyse at the source syntax level -- we can do better with the control flow
graphs.  But we shouldn't try to reimplement type inference -- Starkiller does
a better job at that.  Starkiller is precisely the component we are missing in
our translation project!

Starkiller isn't released yet, as far as I know.  I'll talk to Michael about
it.  Hopefully we can get the core of Starkiller under a non-GPL license (some
old web pages from 2001 talk about an upcoming GPL release of Starkiller).

Bob Ippolito talked about attending the PyPy sprint at EuroPython.  (He was at
the Stackless sprint.)  We should talk to Michael as well.


Guido's keynote (Python 3000): some directions for the next major rewrite of
Python.  I have a rant against both issues in the language evolution that he
talked about: a syntax for types, and much more iterators.  As far as I can
see, both are essentially a way to improve the performance and reduce the
simplicity of the language.  I'm ok with performance tricks that don't show up
on the user, but not with the ones that require him to learn new ways of
getting the job done when there is already one.  Particularly when we have the
theory to recover most of that performance automatically.

"""Q: Will python 3k be built in python?
A: Ask Armin (Rigo) and Laura (Creighton).  If they succeed it's possible for 
Pypy to be the base for Python 3K.  Guido thinks it's about as likely as 
Python 3K being written on top of Parrot..."""

Let's prove him wrong!


A bientot,

Armin.


From mwh at python.net  Mon Mar 29 19:43:22 2004
From: mwh at python.net (Michael Hudson)
Date: Mon, 29 Mar 2004 18:43:22 +0100
Subject: [pypy-dev] Re: PyCON bits
References: <20040329171811.GA17842@vicky.ecs.soton.ac.uk>
Message-ID: <2mwu53k0qt.fsf@starship.python.net>

Armin Rigo <arigo at tunes.org> writes:

> Mitchell Kapor's keynote (Using Python to Develop a Large-Scale Open Source 
> Application: A Report from the Field): the two main points stressed by 
> Mitchell is that Python needs (1) more performance and (2) more security.  
> Looks familiar?

What does he actually mean by (2)?

> IronPython (Jim Hugunin): Python for .NET.  Seems to be very fast, up to 40%
> better than CPython.  The trick is to contrieve as much as possible (and
> more!) the Python semantics so that they fit into existing .NET built-in
> operations.  .NET itself is then able to optimize them extremely agressively.  
> The result is generally significantly faster than CPython.
>
> What we could learn from IronPython is how the common cases are speeded up by
> a lot of boilerplate "fast-path" code (i.e. there is a 8x8 table for calling a
> function with 0 to 7 arguments when the function expects 0 to 7 arguments).  

Hmm.  I wonder what memory consumption is like...

> The other thing we could learn is how to use .NET as a PyPy target platform,
> what the tricks and the main limitations are.  But Jim doesn't release code
> before he thinks it is finished :-(

Boo :-(

> Starkiller (Michael Salib): this is a purely static source-to-source
> Python-to-C++ translator, which does type inference.  It works by analysing a
> graph which closely mirrors the Python source code.  As expected, it has some
> trouble with the most dynamic features like exec/eval, but it is relatively
> advanced in some directions like OO.  Some control structures (like 'for') are
> not implemented.
>
> Bob Ippolito came up with an incredibly cool idea: we can already generate
> control flow graphs, which give a low-level pre-processed version of a Python
> source; so we should just feed that into Starkiller, which would analyse it
> and translate it into C++.  Starkiller shouldn't try to parse the source and
> analyse at the source syntax level -- we can do better with the control flow
> graphs.  But we shouldn't try to reimplement type inference -- Starkiller does
> a better job at that.  Starkiller is precisely the component we are missing in
> our translation project!

Sounds cool.  Do you know how C++ specific it might be?

> Guido's keynote (Python 3000): some directions for the next major rewrite of
> Python.  I have a rant against both issues in the language evolution that he
> talked about: a syntax for types, and much more iterators.  As far as I can
> see, both are essentially a way to improve the performance and reduce the
> simplicity of the language.  I'm ok with performance tricks that don't show up
> on the user, but not with the ones that require him to learn new ways of
> getting the job done when there is already one.  Particularly when we have the
> theory to recover most of that performance automatically.
>
> """Q: Will python 3k be built in python?
> A: Ask Armin (Rigo) and Laura (Creighton).  If they succeed it's possible for 
> Pypy to be the base for Python 3K.  Guido thinks it's about as likely as 
> Python 3K being written on top of Parrot..."""
>
> Let's prove him wrong!

Indeed!

Cheers,
mwh
(who came as close to unsubscribing from python-dev as he's ever been today)

-- 
  Lisp nearing the age of 50 is the most modern language out
  there. GC, dynamic, reflective, the best OO model extant including
  GFs, procedural macros, and the only thing old-fashioned about it 
  is that it is compiled and fast.   -- Kenny Tilton, comp.lang.python


From tismer at stackless.com  Mon Mar 29 19:56:39 2004
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 29 Mar 2004 19:56:39 +0200
Subject: [pypy-dev] Re: PyCON bits
In-Reply-To: <2mwu53k0qt.fsf@starship.python.net>
References: <20040329171811.GA17842@vicky.ecs.soton.ac.uk>
	<2mwu53k0qt.fsf@starship.python.net>
Message-ID: <40686357.8020201@stackless.com>

Michael Hudson wrote:

> Armin Rigo <arigo at tunes.org> writes:
...

>>Let's prove him wrong!
> 
> Indeed!

Sure!

> Cheers,
> mwh
> (who came as close to unsubscribing from python-dev as he's ever been today)

Because of decorators, so much growing iterator C implementations,
optimization and growing featurism?

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From mwh at python.net  Mon Mar 29 20:02:18 2004
From: mwh at python.net (Michael Hudson)
Date: Mon, 29 Mar 2004 19:02:18 +0100
Subject: [pypy-dev] Re: PyCON bits
References: <20040329171811.GA17842@vicky.ecs.soton.ac.uk>
	<2mwu53k0qt.fsf@starship.python.net><40686357.8020201@stackless.com>
Message-ID: <2msmfrjzv9.fsf@starship.python.net>

Christian Tismer <tismer at stackless.com> writes:

>> Cheers,
>> mwh
>> (who came as close to unsubscribing from python-dev as he's ever been today)
>
> Because of decorators, so much growing iterator C implementations,
> optimization and growing featurism?

Not so much that (I'm the author of the decorators patch, after all)
but long threads about changing something that has no chance of
changing in a stupid way.

Last week's climbing holiday meant two things:

1) fiddly details about programming languages don't seem that exciting
   right now, and
2) i read that big dumb thread in one sitting.

Cheers,
mwh

-- 
  Make this IDLE version 0.8.  (We have to skip 0.7 because that 
  was a CNRI release in a corner of the basement of a government 
  building on a planet circling Aldebaran.)
                             -- Guido Van Rossum, in a checkin comment


From tismer at stackless.com  Mon Mar 29 20:09:01 2004
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 29 Mar 2004 20:09:01 +0200
Subject: [pypy-dev] Re: PyCON bits
In-Reply-To: <2msmfrjzv9.fsf@starship.python.net>
References: <20040329171811.GA17842@vicky.ecs.soton.ac.uk>
	<2mwu53k0qt.fsf@starship.python.net><40686357.8020201@stackless.com>
	<2msmfrjzv9.fsf@starship.python.net>
Message-ID: <4068663D.7020006@stackless.com>

Michael Hudson wrote:

> Not so much that (I'm the author of the decorators patch, after all)

Sure, it is just not ending.

> but long threads about changing something that has no chance of
> changing in a stupid way.

Yup. py-dev is reaching the frequency of the main list, years ago.
Time for a clean python-dev-dev list :)

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From bob at redivi.com  Tue Mar 30 02:57:40 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon, 29 Mar 2004 19:57:40 -0500
Subject: [pypy-dev] Re: PyCON bits
In-Reply-To: <2mwu53k0qt.fsf@starship.python.net>
References: <20040329171811.GA17842@vicky.ecs.soton.ac.uk>
	<2mwu53k0qt.fsf@starship.python.net>
Message-ID: <3E8DFFB4-81E5-11D8-93BA-000A95686CD8@redivi.com>


On Mar 29, 2004, at 12:43 PM, Michael Hudson wrote:

> Armin Rigo <arigo at tunes.org> writes:
>
>> Mitchell Kapor's keynote (Using Python to Develop a Large-Scale Open 
>> Source
>> Application: A Report from the Field): the two main points stressed by
>> Mitchell is that Python needs (1) more performance and (2) more 
>> security.
>> Looks familiar?
>
> What does he actually mean by (2)?

Sandboxing arbitrary code is my guess (controlling its access to the 
filesystem, resource allocation, etc).  Because, of course, doing it at 
the process boundary is probably too OS specific for something like 
chandler that has to run on windows.

-bob