Re: [Python-Dev] My patches
Tarek Ziadé schrieb: > On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>> >>> What about having two level of devs ? >>> >>> + core developers + standard library developers >>> >>> [cut] >> >> >> So I'd suggest thinking about developer responsibilities more in terms >> of areas of expertise rather than "levels" of developers. Those of us >> that happen to understand the guts of the compiler or the VM aren't more >> competent globally or more trusted than those maintaining the various >> modules in the standard library - just interested in different things. > > Right, > > I would like to share my experience about this, if it can be helpful. > > I have focused so far in distutils, which, I believe > was not in the top priority of core developers during the last year. > (If this is not true > please forgive me). I think it's safe to say that anything not directly involved in Python 3000 changes was not top priority for most core developers. > Anyway, so I am starting to become quite specialized in this part of > Python, and I pushed patches for it in the tracker. > > The patches I wrote that made it so far took between 4 to 8 months to > be applied. > > I have really simple patches for distutils that are just adding tests, > that are waiting for > review. I guess these patches will be reviewed in a few months, I am > failry confident > about that. I know core developers are drowned into more important topics. > And this area of Python is being highly discussed to be refactored, maybe > outside the stdlib at some point, but there are a *lot* of simple > things to do today in there. > > So basically, if I want to be efficient in distutils I need to become > a core developer, > and this means (Guido said) I need to start providing patches for the > rest of the Python > code and eventually (after a few years I guess) maybe become a core developer. I don't think this is what Guido meant. Or, put differently, it depends on what being a "core developer" means. If it isn't the same as "committer", maybe. However, there is nothing wrong with being a committer and an expert on part of the code. > Then I'll be able to work in distutils because at that point in the > future I'll be trusted. > > I can't do that ! I don't have the time to become a Python core code expert. > But in my everyday work I became a packaging / deploying specialist. > > So my point is : if I am "trusted" at some point in the work I am doing in > distutils, will I have a commit access there ? If I'm not mistaken, nobody will object to that. In the beginning you should find another developer who reviews your (pending) checkins, so that code style and other conventions are maintained. The most important thing for distutils is of course backwards compatibility, so that nobody is forced to rewrite their setup.py scripts. Especially for distutils, there is the SIG mailing list which is meant as the authoritative group for distutils decisions. (I'm not subscribed to it, so perhaps you've already discussed your intended changes there.) cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
> ... > > We know it is the plan for PyPy to work in this way, and also that > Jython and Ironpython works like that (using the host vm's GC), so it > seems to be somehow agreeable with the python semantics (perhaps not > really with __del__ but they are not really nice anyway). > PyPy has a semi-advanced generational moving gc these days. It's not as well tuned as JVMs one, but it works quite well. Regarding semantic changes, there is a couple which as far as I remember are details which you should not rely on anyway (At least some of the below applies also for Jython/IronPython): * __del__ methods are not called immediately when object is not in a cycle * all objects are collected, which means objects in cycles are broken in arbitrary order (gc.garbage is always empty), but normal ordering is preserved. * id's don't always resemble address of object in memory * resurrected objects have __del__ called only once in total. I think for example last one is so obscure detail that if someone relies on it it's his problem :) Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] VPython 0.1
On Fri, Oct 24, 2008 at 12:53 AM, J. Sievers <[EMAIL PROTECTED]> wrote: > "M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > > [snip] >> BTW: I hope you did not use pybench to get profiles of the opcodes. >> That would most certainly result in good results for pybench, but >> less good ones for general applications such as Django or Zope/Plone. > > Algorithm used for superinstruction selection: > > 1) idea: LOAD_CONST/LOAD_FAST + some suffix > 2) potential suffixes: > $ grep '..*(..*--..*)$' ceval.vmg | grep 'a1 a2 --' > INSTRUCTIONS > 3) delete any instruction that I felt wouldn't be particularly frequent > from INSTRUCTIONS (e.g. raise_varargs) > 4) use awk to generate superinstruction definitions > > Not only is this relatively unbiased but also very low effort. > > -jakob > Thanks Jakob. I'm glad to see that you've done this. I had been hoping to see super instructions tried on the python VM for years but never found the time to do it myself. -gps ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
Maciej Fijalkowski wrote: >> ... > >> We know it is the plan for PyPy to work in this way, and also that >> Jython and Ironpython works like that (using the host vm's GC), so it >> seems to be somehow agreeable with the python semantics (perhaps not >> really with __del__ but they are not really nice anyway). >> > > PyPy has a semi-advanced generational moving gc these days. It's not > as well tuned as JVMs one, but it works quite well. Regarding semantic > changes, there is a couple which as far as I remember are details > which you should not rely on anyway (At least some of the below > applies also for Jython/IronPython): > > * __del__ methods are not called immediately when object is not in a cycle > > * all objects are collected, which means objects in cycles are broken > in arbitrary order (gc.garbage is always empty), but normal ordering > is preserved. > > * id's don't always resemble address of object in memory > > * resurrected objects have __del__ called only once in total. Yep, I'm pretty those are all even explicitly documented as implementation details of CPython (PEP 343's with statement was largely added as a cross-implementation way of guaranteeing prompt cleanup of resources like file handles without relying on CPython's __del__ semantics or writing your own try/finally statements everywhere). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
