On Wed, Jul 7, 2010 at 15:17, Terry Reedy <tjre...@udel.edu> wrote: > 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 can say that all the VM representatives have all said they like the idea. -Brett > > 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 > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
