On 7/7/2010 3:32 PM, Brett Cannon wrote: > That's the idea. We already have contributors from the various VMs who > has commit privileges, but they all work in their own repos for > convenience. My hope is that if we break the stdlib out into its own > repository that people simply pull in then other VM contributors will > work directly off of the stdlib repo instead of their own, magnifying > the usefulness of their work. I was wondering if you had more than 'hope', but thinking about it now, I think it premature to ask for commitments. Once a Python3 stdlib hg subrepository is set up and running, the logic of joining in should be obvious -- or not. I am now seeing that a more complete common Python-level test suite is also important. Being able to move Python code, that only uses the stdlibk,between implementations and have it just work would be good for all of them. >> 3. What version of Python would be allowed for use in the stdlib? I would >> like the stdlib for 3.x to be able to use 3.x code. This would be only a >> minor concern for CPython as long as 2.7 is maintained, but a major concern >> for the other implementation currently 'stuck' in 2.x only. A good 3to2 >> would be needed. > > This will only affect py3k. Good. The Python3 stdlib should gradually become modern Python3 code. (An example archaism -- the use in difflib of dicts with arbitrary values used as sets -- which I plan to fix.) >> I generally favor having Python versions of modules available. My current >> post on difflib.SequenceMatcher is based on experiments with an altered >> version. I copied difflib.py to my test directory, renamed it diff2lib.py, >> so I could import both versions, found and edited the appropriate method, >> and off I went. If difflib were in C, my post would have been based on >> speculation about how a fixed version would operate, rather than on data. >> > > The effect upon CPython would be the extension modules become just > performance improvements, nothing more (unless they have to be in C as > in the case for sqlite3). As pre- and jit compilation improve, the need for hand-coded C will go down. For instance, annotate (in a branch, not trunk) and compile with Cython. >> 4. Does not ctypes make it possible to replace a method of a Python-coded >> class with a faster C version, with something like >> try: >> connect to methods.dll >> check that function xyx exists >> replace Someclass.xyy with ctypes wrapper >> except: pass >> For instance, the SequenceMatcher heuristic was added to speedup the >> matching process that I believe is encapsulated in one O(n**2) or so >> bottleneck method. I believe most everything else is O(n) bookkeeping. > There is no need to go that far. All one needs to do is structure the > extension code such that when the extension module is imported, it > overrides key objects in the Python version. Is it possible to replace a python-coded function in a python-coded class with a C-coded function? I had the impression from the issue discussion that one would have to recode the entire class, even if only a single method really needed it. > Using ctypes is just added complexity. Only to be used if easier than extra C coding. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4