Mailman 3 December 2003 - pypy-dev

heard at the Sprint ...
by Laura Creighton Dec. 20, 2003

Dec. 20, 2003

Alex: What? assert 1 is 0 is True for sufficiently large values of 0 ?! (It was a bad test, not a problem with 0L conversion ....)

1 0

Does anybody really use frame->f_tstate ?
by Christian Tismer Dec. 19, 2003

Dec. 19, 2003

Hi colleagues, this is my second attempt to get rid of the f_tstate field in frames. I need to find every user of this field. What am I talking about? Well, Python always has a thread state variable which is a unique handle to the current thread. This variable is accessed in many places, and there exists a fast macro to get at it. Every executing Python frame also gets a copy on creation. In some cases, this frame->f_tstate field is used, in other cases the current tstate variable is used. … [View More] If this sounds foreign to you, please stop reading here. ------------------------------------------------------------- I would like to get rid of the frame->f_tstate, and I'm trying to find out if there is a need for it. I don't need it, for Stackless, it is the opposite, it disturbs. There was a small thread about this in June this year, where Guido convinced me that it is possible to create a traceback on a frame that comes from a different thread. http://mail.python.org/pipermail/python-dev/2003-June/036254.html Ok, this is in fact possible, although I don't think anybody has a need for this. My question to all extension writers is this: If you use frame->f_tstate at all, do you use it just because it is handy, or do you want to use it for some other purpose? One purpose could be that you really want to create a traceback on a different than the current thread. I have never seen this, but who knows, so that's why I'm asking the Python world. In most cases, a traceback will be created on a frame that is currently processd or just has been processed. Accessing a frame of a different thread that is being processed might make sense for special debugger cases. My proposal is -------------- a) change semantics of PytraceBack_Here to use the current tstate. b) if such a special purpose exists, create a new function for it. c) if urgent, different needs exist to keep f_tstate, then let's forget about this proposal. Especially for Stackless, I'd be keen of getting rid of this. thanks for input -- chris -- Christian Tismer :^) <mailto:tismer@tismer.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/ [View Less]

1 1

Built-in modules at app-level
by Armin Rigo Dec. 18, 2003

Dec. 18, 2003

Hello world, Just a fast note about what we want to do at some point: write all built-in modules at application-level. Example: file module/__builtin__.py (or appspace/__builtin__.py): """ Built-in functions, exceptions, and other objects. """ def sum(sequence, total=0): for item in sequence: total = total + item return total def _interp_pow(self, w_base, w_exponent, w_modulus=None): if w_modulus is None: w_modulus = self.space.w_None return self.space.pow(… [View More]

1 0

Re: [pypy-dev] Package directory test conflicts with module file test.py
by Laura Creighton Dec. 18, 2003

Dec. 18, 2003

In a message of Thu, 18 Dec 2003 13:00:50 +0100, Stefan Schwarzer writes: >In src/pypy/tool there's a file test.py . As all test directories >are called "test" (and I want to add one), this would conflict >with the existing module. > >For example, if you say > >from pypy.tool.test import main > >the package test's __init__.py would be loaded, but that doesn't >contain a function "main". ;-) > >My suggestion is to rename test.py to something alse. Suggestions … [View More]

1 0

Package directory test conflicts with module file test.py
by Stefan Schwarzer Dec. 18, 2003

Dec. 18, 2003

In src/pypy/tool there's a file test.py . As all test directories are called "test" (and I want to add one), this would conflict with the existing module. For example, if you say from pypy.tool.test import main the package test's __init__.py would be loaded, but that doesn't contain a function "main". ;-) My suggestion is to rename test.py to something alse. Suggestions for the name? Stefan

1 0

Inactive code in pypy/tool/test.py
by Stefan Schwarzer Dec. 16, 2003

Dec. 16, 2003

In pypy/tool/test.py, class MyTextTestResult, method interact, some code follows a return statement and thus is inactive. Was the return statement left in accidentically or what's going on here? :-) Stefan

2 1

Re: [pypy-svn] rev 2354 - pypy/trunk/src/pypy/objspace/std/test
by Michael Hudson Dec. 16, 2003

Dec. 16, 2003

alex(a)codespeak.net writes: > Author: alex > Date: Tue Dec 16 12:06:48 2003 > New Revision: 2354 > > Modified: > pypy/trunk/src/pypy/objspace/std/test/test_dictobject.py > Log: > Added a test for dicts' str representation > > > Modified: pypy/trunk/src/pypy/objspace/std/test/test_dictobject.py > ============================================================================== > --- pypy/trunk/src/pypy/objspace/std/test/test_dictobject.py (original) > +… [View More]

1 0

Questions
by Richard Emslie Dec. 12, 2003

Dec. 12, 2003

Hi, I've been reading through the source code and the docs, and getting some jist of what is going on. I guess what I was expecting to see something more like the CPython code but in python (like why do we have different object spaces, although I see the errors of my ways now :-) ) and was failing to understand the big picture. So reading between the lines, does this sound anything quite like what we are trying to achieve... The abstraction of the object spaces are so we can perform … [View More]

3 4

IronPython
by Laura Creighton Dec. 11, 2003

Dec. 11, 2003

Alex Martelli tells me that Jim Hugunin has ported Python to .NET and his new Python port is 70% faster than CPython 2.3 on pystones. Anybody have any more information, webpage, code? Laura

3 2

Sprint tracks
by Armin Rigo Dec. 9, 2003

Dec. 9, 2003

Hello PyPy, we have done some more discussion on how to plan the upcoming sprint. Here is our idea. Holger will do an overview presentation of PyPy's current architecture. Armin (or someone else, please stand up :-) will introduce the following four possible tracks for the sprint: * types.py * annotations * interactive/doc tools * builtins and miscanellea In a few words: * types.py This is essentially moving type declarations to app-level. The interp-level code would only be concerned … [View More]about providing implementations for objects (either internal objects like Code or Function, or StdObjSpace objects like W_IntObject). This involves (a) writing the app-level types as almost-usual class declarations; (b) writing a mechanism to link them with interp-level classes; (c) fixing the StdObjSpace to use this mechanism (which should be straightforward because it already works almost like that). * annotations This is the part about translating PyPy into low-level code. We have the beginnings of a nice general annotation scheme which should be finished and linked with the type inference and code generation. The goal is then to have something that can really analyze and produce code for complex examples (up to PyPy itself). * interactive/doc tools Introspecting and interacting with a running PyPy process on various levels. This should make debugging and understanding pypy structures easier, and provide more direct feed-back. Depending on interest and experience we could build various nice user interfaces to do that. Refactoring the current interactive.py/py.pymodule is also a good starting point. * builtins and miscanellea There are still a few crucial builtins to be implemented to make typcial python programs work. Running the CPython test suite is an obvious goal. Writing some more tests especially for the interpreter-level builtins also makes sense. And of course there is a larger number of less-essential built-in modules that need to be ported. The two big introduction sessions should make it possible to get everyone up to speed and start hacking in pairs. Note that we can still add/remove tracks depending on interest. Don't be scared by the above tracks, most of them can be further subdivided into more independent jobs. We might want to list all the "jobs" that need to be done on the board so that if you are fed up with your current track you can pick something :-) Furthermore at the end of the week we should all invest an afternoon into documenting the various architecture bits and pieces. It probably is more fun if we do it all at the same time. cheers and see you all in Amsterdam (well not all, just the sprinters :-), Armin & Holger [View Less]

1 0