Re: [Python-Dev] My patches

2008-11-01 Thread Georg Brandl
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
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


Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

2008-11-01 Thread Maciej Fijalkowski
 ...


 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
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


Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

2008-11-01 Thread Nick Coghlan
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
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