[pypy-svn] r10792 - pypy/dist/pypy/documentation
hpk at codespeak.net
hpk at codespeak.net
Sun Apr 17 22:14:59 CEST 2005
Author: hpk
Date: Sun Apr 17 22:14:59 2005
New Revision: 10792
Added:
pypy/dist/pypy/documentation/misc.txt
- copied, changed from r10791, pypy/dist/pypy/documentation/future.txt
Removed:
pypy/dist/pypy/documentation/cmodules.txt
pypy/dist/pypy/documentation/developers.txt
pypy/dist/pypy/documentation/future.txt
Modified:
pypy/dist/pypy/documentation/newstructure
pypy/dist/pypy/documentation/redirections
Log:
group some stuff into misc.txt to further
cleanup the documentation directory.
Deleted: /pypy/dist/pypy/documentation/cmodules.txt
==============================================================================
--- /pypy/dist/pypy/documentation/cmodules.txt Sun Apr 17 22:14:59 2005
+++ (empty file)
@@ -1,208 +0,0 @@
-PyPy shares a common need with other python reimplementations:
-reimplementing c-coded modules in Python. The more plain
-python code there is the less code needs to be ported either
-Python or to the implementation language (e.g. C# for IronPython_).
-
-In the course of an email discussion_ Anthony Baxter came up with
-a annotated list of modules and some rough categorization of
-the to-be-or-has-been ported modules. The list doesn't claim
-to be exhaustive and should certainly be worked on.
-
-Probably doable
----------------
-
-These ones are probably achievable, although you might think
-otherwise.
-
-_bisectmodule - already exists
-
-_codecsmodule
-
-_csv - already exists?
-
-_heapqmodule - already exists
-
-_hotshot
-
-_localemodule
-
-_randommodule - already exists but with a lesser generator
-
-_sre - already exists?
-
-_weakref
-
-arraymodule
-
-audioop
-
-binascii
-
-cPickle - already exists
-
-cStringIO - already exists
-
-cgensupport
-
-cmathmodule
-
-collectionsmodule - Raymond Hettinger has an ASPN recipe (which has a 'deque' drop-in replacement):
- http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/259179
-
-cryptmodule - see http://home.clear.net.nz/pages/c.evans/sw/
-
-datetimemodule - already exists
-
-gcmodule
-
-imageop
-
-imgfile
-
-itertoolsmodule - the docs include pure python equivalents in a form
-suitable for cut and pasting
-
-mathmodule
-
-md5module - done
-
-operator - done in PyPy
-
-parsermodule - already exists?
-
-rgbimgmodule
-
-sgimodule
-
-shamodule - done
-
-stropmodule
-
-structmodule
-
-symtablemodule
-
-syslogmodule
-
-timingmodule
-
-unicodedata
-
-yuvconvert
-
-zipimport
-
-Deprecated
-----------
-
-These modules are deprecated
-
-regexmodule
-
-regexpr
-
-rotormodule
-
-mpzmodule
-
-Links in an external library
-----------------------------
-
-These are all wrappers around external C libraries. Rewriting them
-from scratch is really not practical.
-
-_bsddb
-
-_curses_panel
-
-_cursesmodule
-
-_ssl
-
-_tkinter
-
-almodule
-
-bsddbmodule
-
-bz2module
-
-cdmodule
-
-clmodule
-
-dbmmodule
-
-flmodule
-
-fmmodule
-
-gdbmmodule
-
-glmodule
-
-nismodule
-
-puremodule
-
-pyexpat
-
-readline (replace with pyrepl?)
-
-svmodule
-
-termios
-
-tkappinit
-
-zlibmodule
-
-System specific
----------------
-
-These are modules that are wrappers around system calls
-and the like. Rewriting them in pure Python will still
-need a way to invoke the underlying calls - and will probably
-be different for each platform (pypy, pycore, ironpython, &c).
-A lot of these are also a mass of #ifdefs for various broken
-operating systems.
-
-dlmodule
-
-errnomodule
-
-fcntlmodule
-
-fpectlmodule
-
-fpetestmodule
-
-grpmodule
-
-linuxaudiodev
-
-mmapmodule
-
-ossaudiodev
-
-posixmodule
-
-pwdmodule
-
-resource
-
-selectmodule
-
-signalmodule
-
-socketmodule
-
-sunaudiodev
-
-threadmodule
-
-timemodule
-
-
-.. _IronPython: http://ironpython.com/
-.. _discussion: http://codespeak.net/pipermail/pypy-dev/2004q3/001509.html
Deleted: /pypy/dist/pypy/documentation/developers.txt
==============================================================================
--- /pypy/dist/pypy/documentation/developers.txt Sun Apr 17 22:14:59 2005
+++ (empty file)
@@ -1,20 +0,0 @@
-
-
-pypy project developers and contributors::
-
- Armin Rigo Holger Krekel
- Samuele Pedroni Christian Tismer
- Michael Hudson Laura Creighton
- Jacob Hallen Alex Martelli
- Richard Emslie Seo Sanghyeon
- Anna Ravencroft Guido Van Rossum
- Anders Lehmann Tomek Meka
- Jiwon Seo Stephan Diehl
- Jens-Uwe Mager Jonathan David Riehl
- Guenter Jantzen Stefan Schwarzer
- Dinu Gherman Patrick Maupin
- Rocco Moretti Andreas Friedge
- Theo de Ridder Olivier Dormond
- Bob Ippolito Marius Gedminas
-
-PyPy Webpage: http://codespeak.net/pypy
Deleted: /pypy/dist/pypy/documentation/future.txt
==============================================================================
--- /pypy/dist/pypy/documentation/future.txt Sun Apr 17 22:14:59 2005
+++ (empty file)
@@ -1,475 +0,0 @@
-============
-Future plans
-============
-
-.. contents::
-.. sectnum::
-
-This document contains a loose collection of future plans.
-
-.. _newrepolayout:
-
-Improving Repo layout
-=====================
-
-Motivation
-----------
-
-We want to move our subversion tree to the following structure:
-
-- `dist`_: source code + documentation (for developer needs)
-
-- `extradoc`_: talks, papers, newsletters and EU-related information
- that are useful for not-only-developers
-
-- `eu-tracking`: eu-tracking details that involve internal
- budget/cost/audit preparations and documentations (not
- available to anonymous checkouts)
-
-.. _`extradoc`: http://codespeak.net/svn/pypy/extradoc
-.. _`dist`: http://codespeak.net/svn/pypy/dist
-
-More detailed layout (work in progress)
----------------------------------------
-
-(starting at /svn/pypy)::
-
- branch # holds branches
- tag # holds tagged dist-versions
-
- dist # holds current development
- pypy # current dist/pypy
- documentation # developer documentation (inside pypy!)
- py # and other 'externals'
- setup.py # should be there at some point
- README.txt # tell how to run PyPy, the translator, tests
- LICENSE.txt # copyright notices for tree parts including pypy
-
- extradoc # non-dist documentations (papers etc.pp.)
- talk # various pypy-talks
- paper # various pypy-related papers (including our own)
- sprint # sprint related information (reports etc.pp.)
- irclog # IRC logs (snipped appropriately)
- eu-info # legal guidelines/rules partcipation
- eu-forms # Accession forms (empty)
- proposal # several versions
- newsletter # ...
- press # ...
-
- eu-tracking # strong focus on eu-internal details
- timesheets # monthly timesheets
- monthly-reports
- deliverables # deliverable/documents
- minutes # meeting protocols
- budget.sxc
- calendar.sxc
- ...
- www # website-related stuff (needs its own reconsideration)
-
-
-The idea is that developers can use a simple url::
-
- svn co https://codespeak.net/svn/pypy/dist dist-pypy
-
-in order to get everything neccessary for sourcecode, documentation
-and test development. Obviously, if you care about the EU-funding
-or web site application/contents you can do an appropriate checkout
-as well. The extradoc contains information interesting to
-developers and other open source projects (seeking funding or not).
-
-Note, that having documentation inside the source tree will help
-with keeping a closer eye on documentation - especially when we
-have special ref-integrity tests for the documentation (which itself
-should reference real source-code/functions at some point). For
-example, the refactoring of unitest.py-style tests to `py.test`_ based ones
-"forgot" to modify our test-documentation in the too-far-away doc-folder.
-We should move to a scheme where such an omission will raise real
-test errors.
-
-.. _`py.test`: http://codespeak.net/py/current/doc/test.html
-
-.. _goals:
-
-Brainstorming of goals
-=========================
-
-This is a loose collection of goals we brainstormed at
-some earlier point.
-
-**Infrastructure and tools**
-
-Supporting the PyPy project by producing and enhancing the tools.
-
-Support the development process with reusing existing or developing
-new debugging opensource tools.
-
-- provide access over http/https and ssh server
-
-- build extensions for automatic document extraction
-
-- implement a search facility over all content
-
-- maintain and enhance website infrastructure
-
-- setup a mirror repository which is kept up-to-date and which
- can be used readonly in case of failure of the main repository.
-
-- Design a strict backup policy.
-
-- help with automated testing
-
- XXX add what more do we want to do?
-
-- http-server to present runtime/introspection information aiding
- debugging and understanding of PyPy internals
-
-- automated (unit-)testing framework with html/pdf reports
-
-**Synchronisation with Standard Python**
-
-- Keeping PyPy in sync with potential changes to Standard Python.
-
-- Support a subset of the CPython API for compatibility with extension modules.
-
-- Facilitate porting of extension modules to PyPy.
-
-- What's new since 2.2? see http://www.python.org/doc/2.3.3/whatsnew -- Thank you amk!
-
-**PEPS**
-
-+ PEP 218: A Standard Set Datatype -- set module --
-
-+ PEP 263 defining Python Source Code encodings
-
-+ PEP 273 Importing Modules from Zip Archives -- zipimport module --
-
-+ PEP 277: Unicode file name support for Windows NT
-
-+ PEP 278: Universal Newline Support
-
-+ PEP 279: enumerate()
-
-+ PEP 282: The logging Package
-
-+ PEP 285: A Boolean Type
-
-+ PEP 293: Codec Error Handling Callbacks
-
-+ PEP 301: Package Index and Metadata for Distutils
-
-+ PEP 302: New Import Hooks
-
-+ PEP 307: Pickle Enhancements
-
-**Check and see we have implemented these**
-
-* Extended Slices
-
-* The yield statement is now always a keyword
-
-* new built-in function enumerate()
-
-* Two new constants, True and False
-
-* The int() type constructor will now return a long integer instead of
- raising an OverflowError when a string or floating-point number is too
- large to fit into an integer. This can lead to the paradoxical result
- that isinstance(int(expression), int) is false.
-
-* Built-in types now support the extended slicing syntax
-
-* A new built-in function, sum(iterable, start=0), adds up the numeric
- items in the iterable object and returns their sum. sum() only accepts
- numbers, meaning that you can't use it to concatenate a bunch of strings.
-
-does it handle mixed floats and ints?
-
-* list.insert(pos, value) used to insert value at the front of the list
- when pos was negative. The behaviour has now been changed to be consistent
- with slice indexing, so when pos is -1 the value will be inserted before
- the last element, and so forth.
-
-so to insert at the front?
-
-* list.index(value), which searches for value within the list and
- returns its index, now takes optional start and stop arguments to limit
- the search to only part of the list.
-
-* Dictionaries have a new method, pop(key[, default]), that returns the
- value corresponding to key and removes that key/value pair from the
- dictionary. If the requested key isn't present in the dictionary,
- default is returned if it's specified and KeyError raised if it isn't.
-
-* There's also a new class method, dict.fromkeys(iterable, value), that
- creates a dictionary with keys taken from the supplied iterator iterable
- and all values set to value, defaulting to None.
-
- Also, the dict() constructor now accepts keyword arguments to simplify
- creating small dictionaries:
-
- >>> dict(red=1, blue=2, green=3, black=4)
- {'blue': 2, 'black': 4, 'green': 3, 'red': 1}
-
-
-* The assert statement no longer checks the __debug__ flag, so you can no
- longer disable assertions by assigning to __debug__. Running Python with
- the -O switch will still generate code that doesn't execute any assertions.
-
-So what if you want to disable assertions just within one module?
-
-* Most type objects are now callable, so you can use them to create new
- objects such as functions, classes, and modules. (This means that the
- new module can be deprecated in a future Python version, because you
- can now use the type objects available in the types module.) For example,
- you can create a new module object with the following code:
-
- >>> import types
- >>> m = types.ModuleType('abc','docstring')
- >>> m
- <module 'abc' (built-in)>
- >>> m.__doc__
- 'docstring'
-
-* A new warning, PendingDeprecationWarning was added to indicate features
- which are in the process of being deprecated. The warning will not be
- printed by default. To check for use of features that will be deprecated
- in the future, supply -Walways::PendingDeprecationWarning:: on the
- command line or use warnings.filterwarnings().
-
-* The process of deprecating string-based exceptions, as in
- raise "Error occurred", has begun. Raising a string will now trigger
- PendingDeprecationWarning.
-
-* Using None as a variable name will now result in a SyntaxWarning warning.
- In a future version of Python, None may finally become a keyword.
-
-* The xreadlines() method of file objects, introduced in Python 2.1,
- is no longer necessary because files now behave as their own
- iterator. xreadlines() was originally introduced as a faster way to
- loop over all the lines in a file, but now you can simply write
- for line in file_obj. File objects also have a new read-only encoding
- attribute that gives the encoding used by the file; Unicode strings
- written to the file will be automatically converted to bytes using
- the given encoding.
-
-* The method resolution order used by new-style classes has changed,
- though you'll only notice the difference if you have a really
- complicated inheritance hierarchy. Classic classes are unaffected by
- this change. Python 2.2 originally used a topological sort of a
- class's ancestors, but 2.3 now uses the C3 algorithm as described in
- the paper *A Monotonic Superclass Linearization for Dylan*. To
- understand the motivation for this change, read Michele Simionato's
- article *Python 2.3 Method Resolution Order*, or read the thread
- on python-dev starting with the message at
- http://mail.python.org/pipermail/python-dev/2002-October/029035.html.
- Samuele Pedroni first pointed out the problem and also implemented the fix
- by coding the C3 algorithm.
-
-* Python runs multithreaded programs by switching between threads
- after executing N bytecodes. The default value for N has been
- increased from 10 to 100 bytecodes, speeding up single-threaded
- applications by reducing the switching overhead. Some multithreaded
- applications may suffer slower response time, but that's easily
- fixed by setting the limit back to a lower number using
- sys.setcheckinterval(N). The limit can be retrieved with the new
- sys.getcheckinterval() function.
-
-* One minor but far-reaching change is that the names of extension
- types defined by the modules included with Python now contain the
- module and a "." in front of the type name. For example, in Python
- 2.2, if you created a socket and printed its __class__, you'd get
- this output:
-
- >>> s = socket.socket()
- >>> s.__class__
- <type 'socket'>
-
- In 2.3, you get this:
-
- >>> s.__class__
- <type '_socket.socket'>
-
-* One of the noted incompatibilities between old- and new-style
- classes has been removed: you can now assign to the __name__ and
- __bases__ attributes of new-style classes. There are some
- restrictions on what can be assigned to __bases__ along the lines of
- those relating to assigning to an instance's __class__ attribute.
-
-**String Changes**
-
-* The in operator now works differently for strings. Previously, when
- evaluating X in Y where X and Y are strings, X could only be a
- single character. That's now changed; X can be a string of any
- length, and X in Y will return True if X is a substring of Y. If X
- is the empty string, the result is always True.
-
- >>> 'ab' in 'abcd'
- True
- >>> 'ad' in 'abcd'
- False
- >>> '' in 'abcd'
- True
-
-* The strip(), lstrip(), and rstrip() string methods now have an
- optional argument for specifying the characters to strip. The
- default is still to remove all whitespace characters:
-
-* The startswith() and endswith() string methods now accept negative
- numbers for the start and end parameters.
-
-* Another new string method is zfill(), originally a function in the
- string module. zfill() pads a numeric string with zeros on the left
- until it's the specified width. Note that the % operator is still
- more flexible and powerful than zfill().
-
-* A new type object, basestring, has been added. Both 8-bit strings
- and Unicode strings inherit from this type, so isinstance(obj, basestring)
- will return True for either kind of string. It's a completely abstract
- type, so you can't create basestring instances.
-
-* Interned strings are no longer immortal and will now be
- garbage-collected in the usual way when the only reference to them
- is from the internal dictionary of interned strings.
-
-**Replace PyPy Core**
-
-Building a complete Python interpreter written in Python,
-using a subset of Python that avoids dynamic featureslll
-which would impair the objectives of RPython.
-
-- Design and implement the PyPy bytecode interpreter and
- build an object space library in RPython.
- The resulting interpreter must cover the complete Python
- language specification. -- mostly done, test coverage.
-
-- Port the built-in Python library to PyPy (functions, types and
- modules currently implemented in C) -- types needs refactoring,
- the rest is mostly done. Anthony Baxter has given us a very useful
- list of the cmodules_ we need to consider porting.
-
-- Decide on a case-by-case basis which features are to
- be implemented using RPython or just general Python. -- moving target.
-
-- Implement a Python parser and bytecode compiler in Python.
- -- we have something, but it is not well integrated.
-
-- A partial Python implementation that passses 75% of the official
- Python test suite that don't depend on extension modules.
- -- write this test and then pass it.
-
-**The PyPy Translation**
-
-- Analysis and translation of the PyPy core into efficient low-level code
- (C, Pyrex, Java, others). - moving target
-
-- Provide a Runtime Library for the translated versions
- of PyPy. - not even started
-
-- Create a code analysis tool for a subset of the Python
- language (RPython). Coordinate the definition of RPython
- being the implementation language of the core.
-
- - we can analyse functions, but not classes, modules, spaces etc.
-
-- Complete implementation of Python, conforming to the language
- definition and passing all relevant tests of the official Python
- test suite. -- global goal, which we will think more about when
- it is very close to being done.
-
-**Stackless Integration + More Performance Hacks**
-
-- Identification and Implementation of Optimisations through modifications
- of the Translator.
-
-- Enable Massive Parallelism in a Single Thread.
-
-- Provide support for real-time parallelism.
-
-- Allow Pickling of a Running Program.
-
-- Enhance the translator to support continuation passing
- style by integrating technology from the Stackless project.
-
-- Implement the necessary runtime system to support massive parallelism.
-
-- Implement a single-threaded, pre-emptive scheduler with
- priorities, complementing the OS threads.
-
-- Study approaches concerning code size vs. speed trade-offs.
-
-- Implement and compare different object layout and memory management
- strategy or strategies.
-
-- Enhance multimethod dispatching.
-
-- Implement schemes of pointer tagging.
-
-- Create reports and merge the results back into the optimization effort.
-
-**Psyco Integration**
-
-- Outperform the state-of-the art (Psyco, Stackless).
-
-- Enhance PyPy to dynamically adapt to its run-time environment and
- to the characteristics of the running program. Dramatically
- increase speed by enabling Just-In-Time compilation and
- specialization.
-
-- Address multiple processor architectures.
-
-- Apply and enhance techniques from the Psyco project. Promote parts
- of the static translator to be used for run-time specialization.
-
-- Design and implement a back-end component for dynamically emitting
- machine code for multiple processor architectures. Enable dynamic
- foreign function calls.
-
-- Research optimisation heuristics for the Just-In-Time compiler.
-
-- A Just-In-Time compiler for PyPy !!! Outperform the
- state-of-the art (Psyco, Stackless).
-
-**Embed in Specialized Hardware**
-
-if we get funding.
-
-**Implement Security, Distribution and Persistence**
-
-- Research and validate the flexibility of PyPy by building key middleware
- features into the language itself.
-
-- Analyze and implement security models at the language level.
-
-- Implement the "RExec" restricted execution model. (It was removed
- from the official Python implementation because it is false security.)
-
-- Analyze and implement distributed execution models at the language level.
-
-- Implement network-transparent execution of Python programs. (Typical
- libraries require programs to be aware of the remote execution model.)
-
-- Analyze and implement persistence at the language level. -- talk to
- Patrick O'Brien who is really hot for the idea.
-
-- Implement an orthogonally persistent object space for Python programs.
- (Persistence is never fully orthogonal without advanced language support.)
-
-**PyPy A la Carte**
-
-- Develop tools that will allow to chose from available features and runtime
- restrictions to build a custom PyPy version.
-
-- Analyse and integrate all results from the results of other workpackages.
- This involves identifying and resolving conflicts which could prevent
- a combintation of desired optimization goals.
-
-- Implement user interfaces to select features and runtime restrictions.
- Provide a way to automatically build a PyPy custom version for different
- memory, performance and extension requirements.
-
-- Make a build- and configuration tool that allows to build custom PyPy
- versions suitable for specialized environments such as small or very large
- computing devices.
-
-.. _cmodules: http://codespeak.net/pypy/index.cgi?doc/cmodules.html
-
Copied: pypy/dist/pypy/documentation/misc.txt (from r10791, pypy/dist/pypy/documentation/future.txt)
==============================================================================
--- pypy/dist/pypy/documentation/future.txt (original)
+++ pypy/dist/pypy/documentation/misc.txt Sun Apr 17 22:14:59 2005
@@ -1,11 +1,36 @@
-============
-Future plans
-============
+======================
+Miscallenous fragments
+======================
.. contents::
.. sectnum::
-This document contains a loose collection of future plans.
+This document contains a loose collection of goals, plans and
+fragmentary documentation. (We don't want these pieces to clutter
+our documentation directory as single files, to be honest.)
+
+.. _developers:
+
+pypy project developers and contributors
+========================================
+
+The following list is not up-to-date and should
+be computed automatically, anyway::
+
+ Armin Rigo Holger Krekel
+ Samuele Pedroni Christian Tismer
+ Michael Hudson Laura Creighton
+ Jacob Hallen Alex Martelli
+ Richard Emslie Seo Sanghyeon
+ Anna Ravencroft Guido Van Rossum
+ Anders Lehmann Tomek Meka
+ Jiwon Seo Stephan Diehl
+ Jens-Uwe Mager Jonathan David Riehl
+ Guenter Jantzen Stefan Schwarzer
+ Dinu Gherman Patrick Maupin
+ Rocco Moretti Andreas Friedge
+ Theo de Ridder Olivier Dormond
+ Bob Ippolito Marius Gedminas
.. _newrepolayout:
@@ -88,6 +113,219 @@
.. _`py.test`: http://codespeak.net/py/current/doc/test.html
+
+Porting C Modules in Python
+================================
+
+PyPy shares a common need with other python reimplementations:
+reimplementing c-coded modules in Python. The more plain
+python code there is the less code needs to be ported either
+Python or to the implementation language (e.g. C# for IronPython_).
+
+In the course of an email discussion_ Anthony Baxter came up with
+a annotated list of modules and some rough categorization of
+the to-be-or-has-been ported modules. The list doesn't claim
+to be exhaustive and should certainly be worked on.
+
+Probably doable
+---------------
+
+These ones are probably achievable, although you might think
+otherwise.
+
+_bisectmodule - already exists
+
+_codecsmodule
+
+_csv - already exists?
+
+_heapqmodule - already exists
+
+_hotshot
+
+_localemodule
+
+_randommodule - already exists but with a lesser generator
+
+_sre - already exists?
+
+_weakref
+
+arraymodule
+
+audioop
+
+binascii
+
+cPickle - already exists
+
+cStringIO - already exists
+
+cgensupport
+
+cmathmodule
+
+collectionsmodule - Raymond Hettinger has an ASPN recipe (which has a 'deque' drop-in replacement):
+ http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/259179
+
+cryptmodule - see http://home.clear.net.nz/pages/c.evans/sw/
+
+datetimemodule - already exists
+
+gcmodule
+
+imageop
+
+imgfile
+
+itertoolsmodule - the docs include pure python equivalents in a form
+suitable for cut and pasting
+
+mathmodule
+
+md5module - done
+
+operator - done in PyPy
+
+parsermodule - already exists?
+
+rgbimgmodule
+
+sgimodule
+
+shamodule - done
+
+stropmodule
+
+structmodule
+
+symtablemodule
+
+syslogmodule
+
+timingmodule
+
+unicodedata
+
+yuvconvert
+
+zipimport
+
+Deprecated
+----------
+
+These modules are deprecated
+
+regexmodule
+
+regexpr
+
+rotormodule
+
+mpzmodule
+
+Links in an external library
+----------------------------
+
+These are all wrappers around external C libraries. Rewriting them
+from scratch is really not practical.
+
+_bsddb
+
+_curses_panel
+
+_cursesmodule
+
+_ssl
+
+_tkinter
+
+almodule
+
+bsddbmodule
+
+bz2module
+
+cdmodule
+
+clmodule
+
+dbmmodule
+
+flmodule
+
+fmmodule
+
+gdbmmodule
+
+glmodule
+
+nismodule
+
+puremodule
+
+pyexpat
+
+readline (replace with pyrepl?)
+
+svmodule
+
+termios
+
+tkappinit
+
+zlibmodule
+
+System specific
+---------------
+
+These are modules that are wrappers around system calls
+and the like. Rewriting them in pure Python will still
+need a way to invoke the underlying calls - and will probably
+be different for each platform (pypy, pycore, ironpython, &c).
+A lot of these are also a mass of #ifdefs for various broken
+operating systems.
+
+dlmodule
+
+errnomodule
+
+fcntlmodule
+
+fpectlmodule
+
+fpetestmodule
+
+grpmodule
+
+linuxaudiodev
+
+mmapmodule
+
+ossaudiodev
+
+posixmodule
+
+pwdmodule
+
+resource
+
+selectmodule
+
+signalmodule
+
+socketmodule
+
+sunaudiodev
+
+threadmodule
+
+timemodule
+
+.. _IronPython: http://ironpython.com/
+.. _discussion: http://codespeak.net/pipermail/pypy-dev/2004q3/001509.html
+
+
.. _goals:
Brainstorming of goals
Modified: pypy/dist/pypy/documentation/newstructure
==============================================================================
--- pypy/dist/pypy/documentation/newstructure (original)
+++ pypy/dist/pypy/documentation/newstructure Sun Apr 17 22:14:59 2005
@@ -5,9 +5,11 @@
optionaltool.txt
checking_ReST.txt
-revreport
+misc
cmodules.txt # move to revreport somehow?
developers.txt
+ newrepolayout.txt
+ goals.txt
index.txt
# references all the major chapters
@@ -20,9 +22,6 @@
modules
functions
-future.txt
- newrepolayout.txt
- goals.txt
coding-style.txt
restrictedpy.txt
Modified: pypy/dist/pypy/documentation/redirections
==============================================================================
--- pypy/dist/pypy/documentation/redirections (original)
+++ pypy/dist/pypy/documentation/redirections Sun Apr 17 22:14:59 2005
@@ -15,7 +15,10 @@
'checking_ReST.html' : 'coding-style.html#pypy-documentation',
'optionaltools.html' : 'coding-style.html#optionaltool',
- 'newrepolayout.html' : 'future.html#newrepolayout',
- 'goals.html' : 'future.html#goals',
+ 'newrepolayout.html' : 'misc.html#newrepolayout',
+ 'goals.html' : 'misc.html#goals',
+
+ 'developers.html' : 'misc.html#developers',
+ 'cmodules.html' : 'misc.html#cmodules',
}
More information about the Pypy-commit
mailing list