> >
> > class SubFoo(Foo):
> > def __init__(self, *args, **kw):
> > Foo(self, *args, **kw)
> > ...
Guido:
> I like the idea, but it would mean a major reworking of the grammar
> and the parser. Can I persuade you to keep this on ice until 2.0?
What exactly would the semantics be? While I hate the apply() loops you have
to jump through nowadays to get this behaviour I don't funny understand how
this would work in general (as opposed to in this …
[View More]case). For instance, would
Foo(self, 12, *args, **kw)
be allowed? And
Foo(self, *args, x=12, **kw)
?
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
[View Less]
I've seen repeatedly on c.l.p a suggestion to modify the syntax & the core
to allow * and ** in function calls, so that:
class SubFoo(Foo):
def __init__(self, *args, **kw):
apply(Foo, (self, ) + args, kw)
...
could be written
class SubFoo(Foo):
def __init__(self, *args, **kw):
Foo(self, *args, **kw)
...
I really like this notion, but before I poke around trying to see if it's
doable, I'd like to get feedback on whether y'all think it's a good idea
or not. And if …
[View More]someone else wants to do it, feel free -- I am of course
swamped, and I won't get to it until after rich comparisons.
FWIW, apply() is one of my least favorite builtins, aesthetically
speaking.
--david
[View Less]
Tim Peters wrote:
[see the main list on idle leaks]
> if-pystone-works-ship-it-ly y'rs - tim
Well, on request of uncle Timmy, I do it.
Although it's very early.
A preview of stackless Python can be found under
ftp://ftp.pns.cc/pub/stackless_990606.zip
Current status:
The main interpreter is completely stackless.
Just for fun, I've set max recursion depth to 30000,
so just try it.
PyStone does of course run. My measures were about
3-5 percent slower than with standard Python. I think
…
[View More]this is quite fair.
As a side effect, the exec_statement now behaves
better than before, since
exec <anything>
without globals and locals should update the current
environment, which worked only for exec "string".
Most of the Run_<thing> functions are stackless as well.
Almost all cases could be treated tail recursively.
I have just begun to work on the builtins, and there is
a very bloody, new-born stackless map, which seems to
behave quite well. (It is just an hour old, so don't blame me
if I didn't get al refcounts right).
This is a first special case, since I *had* to build a
tiny interpreter from the old map code.
Still quite hacky, but not so bad.
It creates its own frame and bails out whenever it needs
to call the interpreter. If not, it stays in the loop.
Since this one is so fresh, the old map is still
there, and the new one has the name "map_nr".
As a little bonus, map_nr now also shows up in a
traceback. I've set the line no to the iteration count.
Beware, this is just a proof of concept and will
most probably change.
Further plans:
I will make the other builtins stackless as well
(reduce, filter), also the simple tail-recursive
ones which I didn't do now due to lack of time.
I think I will *not* think of stackless imports.
After loking into this for a while, I think this
is rather hairy, and also not necessary.
On extensions:
There will be a coroutine extension in a few days.
This is now nearly a no-brainer, since I did the
stackless Python with exactly that in mind.
This is the real fruit where I'm after, so please
let me pick it :)
Documentation:
Besides the few new comments, there is nothing yet.
Diff files:
Sorry, there are no diffs but just the modified
files. I had no time to do them now. All files stem
from the official Python 1.5.2 release.
You might wonder about the version:
In order to support extension modules which rely on
some special new features of frames, I decided
to name this Python "1.5.42", since I believe
it will be useful at least "four two" people. :-)
I consider this an Alpha 1 version.
fearing the feedback :-) ciao - chris
--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
[View Less]
> Here's what I think we should do first (I've mentioned this before but
> nobody cheered me on :-).
Go, Guido, GO!!!!
What I'd like in the split you propose is to see which of the items would be
implementable in Python, and try to do the split in such a way that such a
Python implementation isn't ruled out.
Am I correct in guessing that after factoring out the components you mention
the only things that aren't in a "replaceable component" are the builtin
objects, and a little …
[View More]runtime glue (malloc and such)?
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
[View Less]
Guido van Rossum writes:
> Greg Stein writes:
> > For example, can I take the async modules and build a commercial
> > product on them?
Yes, my intent was that they go under the normal Python 'do what thou
wilt' license. If I goofed in any way, please let me know!
> As far as I know, yes. Sam Rushing promised me this when he gave
> them to me for inclusion. (I've had a complaint that they aren't
> the latest -- can someone confirm this?)
Guilty as charged. I'…
[View More]ve been tweaking them a bit lately, for
performance, but anyone can grab the very latest versions out of the
medusa CVS repository:
CVSROOT=:pserver:medusa@seattle.nightmare.com:/usr/local/cvsroot
(the password is 'medusa')
Or download one of the snapshots.
BTW, those particular files have always had the Python
copyright/license.
-Sam
[View Less]
> One possibility might be NSPR, the Netscape Portable Runtime,
> which provides platform-independent threads and I/O on Mac, Win32, and
> Unix. Perhaps a thread implementation could be written that sat on
> top of NSPR, in addition to the existing pthreads implementation.
> See http://www.mozilla.org/docs/refList/refNSPR/.
NSPR looks rather promising! Does anyone has any experiences with it? What I'd
also be interested in is experiences in how it interacts with the "real"…
[View More] I/O
system, i.e. can you mix and match NSPR calls with normal os calls, or will
that break things?
The latter is important for Python, because there are lots of external
libraries, and while some are user-built (image libraries, gdbm, etc) and
could conceivably be converted to use NSPR others are not...
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
[View Less]
In case you haven't heard about it, ActiveState has recently signed a
contract with Microsoft to do some work on Perl on win32.
One interesting aspect of this for Python is the specific work being
performed. From the FAQ on this joint effort, one gets, under "What is
the scope of the work that is being done?":
fork()
This implementation of fork() will clone the running interpreter
and create a new interpreter with its own thread, but running in the
same process space. The …
[View More]goal is to achieve functional equivalence to
fork() on UNIX systems without suffering the performance hit of the
process creation overhead on Win32 platforms.
Emulating fork() within a single process needs the ability to run
multiple interpreters concurrently in separate threads. Perl version
5.005 has experimental support for this in the form of the PERL_OBJECT
build option, but it has some shortcomings. PERL_OBJECT needs a C++
compiler, and currently only works on Windows. ActiveState will be
working to provide support for revamped support for the PERL_OBJECT
functionality that will run on every platform that Perl will build on,
and will no longer require C++ to work. This means that other operating
systems that lack fork() but have support for threads (such as VMS and
MacOS) will benefit from this aspect of the work.
Any guesses as to whether we could hijack this work if/when it is released
as Open Source?
--david
[View Less]
Speaking of licensing issues...
I seem to have read somewhere that the two Medusa files are under a
separate license. Although, reading the files now, it seems they are
not.
The issue that I'm really raising is that Python should ship with a
single license that covers everything. Otherwise, it will become very
complicated for somebody to figure out which pieces fall under what
restrictions.
Is there anything in the distribution that is different than the normal
license?
For example, can I …
[View More]take the async modules and build a commercial product
on them?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
[View Less]
I wrote:
> > Not a Mac programmer, but I recall that when Steve Jobs came back,
> > they published a schedule that said threads would be available a
> > couple releases down the road. Schedules only move one way, so I'd
> > guess ActiveState is premature.
>
> http://www.computerworld.com/home/print.nsf/all/990531AAFA
which was just my way of saying that "did he perhaps
refer to OS X ?".
or are they adding real threads to good old MacOS too?
</F>
All this talk about stack frames and manipulating them at runtime has
reminded me of one of my biggest gripes about Python. When I say "biggest
gripe", I really mean "biggest surprise" or "biggest shame".
That is, Python is very interactive and dynamic. However, when I am
debugging Python, it seems to lose this. There is no way for me to
effectively change a running program. Now with VC6, I can do this with C.
Although it is slow and a little dumb, I can change the C side of my Python
…
[View More]world while my program is running, but not the Python side of the world.
Im wondering how feasable it would be to change Python code _while_ running
under the debugger. Presumably this would require a way of recompiling the
current block of code, patching this code back into the object, and somehow
tricking the stack frame to use this new block of code; even if a first-cut
had to restart the block or somesuch...
Any thoughts on this?
Mark.
[View Less]
