Re: [Python-Dev] Python-3000 upgrade path
Thomas Wouters wrote: developers and people who develop their own software. I would like to hear from people who have concrete doubts about this upgrade path. I don't mean Disclaimer: I'm not involved in Py3k, and not even tried it once. And don't know the details of the tool to transform Py2 to Py3. Having said that, the *only* fear I have, is how safe it will be. And here comes the explanation. I'm now in an enviroment where we rely on Python, and I advocates on it everyday. We use 2.3, and 2.4, some servers we're about to deploy have 2.5, and we'll use the lastest Py2.x everytime we deploy a new machine. But, as we have always running behind our ToDo, we don't have time to say Ok, this server runs 2.3, how can I start using 2.5?. Too many servers, too many applications, too many undocumented-and-nobody-knows-about-it applications. And they all are applications running 7x24. And Py3k is around the corner, and I even heard some guys saying If I'd spent time taking care that this app runs ok after changing a bit of it, I'll wait to Python 3000. So, the enviroment is explained, now I go with how safe it will be. I'd love to know that there'll be a tool that tells me, after running it over my application, Your app is ready for migration'. I do *not* care if it takes a lot of work to make the proper changes, but I need to feel confident that after running the last changed version during a week in, say, Py2.7, and no warnings appear, and the verification tool say green light, I can start running it in Py3k. And look at it a week more. And say life is great, :) Anyway, I know how hard is it, and I regret not having the time I'd love to have to help you. All I can do is thank you. Thank you very much! One thing in particular I wonder about is the warning about mixing tabs and spaces. Should it be in category 2) (on by default) or 3) (still off by default, but part of -Wpy3k)? For me, I'd love to 2.6 start warning you're mixing tab and spaces, shame yourself!. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
[Python-Dev] Adding socket timeout to urllib2
I studied which modifications I need to make into urllib2 to support a socket timeout. - I'll modify urlopen for it to accept a socket_timeout parameter, default to None - Request will also accept a socket_timeout parameter, default to None. It will keep it in a socket_timeout attribute, so it could be added/modified from outside. - OpenerDirector's 'open' method will accept socket_timeout, and build the Request object with it So, when it gets into the Handlers, how it'll be used? I checked the Handlers, and here is a resume of their 'open' or 'open'-like methods: - AbstractHTTPHandler: receives a class, and uses its .request and .getresponse methods - HTTPHandler: just calls AbstractHTTPHandler.do_open with httplib.HTTPConnection - HTTPSHandler: just calls AbstractHTTPHandler.do_open with httplib.HTTPSConnection - UnknownHandler: raises an Error - FileHandler: opens a file in a local host - FTPHandler: uses sockets in ftplib.FTP().connect, .login, .cwd, and .ntransfercmd, all through urllib's ftwrapper object - CacheFTPHandler: instantiates ftpwrapper object; does not uses it directly, though. - GopherHandler: is deprecated... So, these are the necessary further modifications in urllib2 beyond those detailed at the beggining of the mail: - Modify AbstractHTTPHandler to pass the socket_timeout parameter to the received class' methods. - Modify FTPHandler to pass the socket_timeout to ftpwrapper class. - Modify CacheFTPHandler the same way that FTPHandler Beyond that, I'll also need to: - Modify urllib.ftpwrapper to accept a socket_timeout parameter and pass it to ftplib.FTP object. - Add support to socket_timeout to ftplib's FTP object - Add support to socket_timeout to httplib's HTTPConnection and HTTPSConnection objects So, I think that in the name of clarity, I shall first modify ftplib and httplib, add socket_timeout where is necessary, and then add support to that in the more general urllib2. What do you think? Comments are very appreciated. Thank you very much! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
[Python-Dev] About code comments policy (and Handler order in urllib2)
One question and one answer (this is a balanced post, :p). The question is what to do when we found a question in a code. Reading urllib2 I found: # XXX why does self.handlers need to be sorted? I found the answer, so I deleted that line, and added a comment in that place just to clarify. Shall I do something else? Like posting here the answer? BTW, the answer to that question is that the handlers must work in an specific order. The order is specified in each Handler (handler_order class attribute), and BaseHandler has __lt__ defined using that attribute. So, OpenerDirector, keeps self.handler ordered with bisect.insort. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Adding socket timeout to urllib2
Facundo So, I think that in the name of clarity, I shall first modify Facundo ftplib and httplib, add socket_timeout where is necessary, and Facundo then add support to that in the more general urllib2. I own a patch on SF to do that much: http://python.org/sf/723312 Feel free to take it from me and use as a starting point. Skip ___ 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
[Python-Dev] PCBuild8
Hi, I tried building with MS Visual Studio 2005 from PCBuild8/pcbuild.sln, and for me it fails miserably. The first major complaint comes when linking pythoncore, where the _init_types symbol can't be found. On the other hand, allowing MSVS to convert PCBuild/pcbuild.sln works okay. Am I missing something? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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] About code comments policy (and Handler order in urllib2)
Facundo Batista schrieb: The question is what to do when we found a question in a code. Reading urllib2 I found: # XXX why does self.handlers need to be sorted? I found the answer, so I deleted that line, and added a comment in that place just to clarify. Shall I do something else? You should check whether documentation needs to be clarified. In this case, I see a single mention of handler_order in the documentation, and that only mentions that the attribute exists and can be set. Not having looked at all at the functionality: Do you consider this documentation sufficient? Would you think users may need to know about this feature? If so, do you think they have what they need to use it just by reading the documentation? If you really feel zestful (is that proper usage of the word?), you could try to study who added the remark, and when, and who added the documentation, and when. I often do that to verify that I really understood the purpose of the question. Regards, Martin ___ 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] Encouraging developers
On Mon, Mar 05, 2007 at 12:58:13PM -0600, [EMAIL PROTECTED] wrote: I'm not much of a version control wonk. How would these help? Can't the folks who need such stuff do some sort of anonymous svn checkout? The external developers can commit changes, revert them, etc. to their local repository, and still keep pulling changes from the python.org master as we commit them. With an anonymous SVN checkout, you can never commit changes back, so you can't commit your work in stages or roll back changes as those of us w/ commit privileges can. (svk adds distributed features on top of SVN; that would be another option.) --amk ___ 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] Encouraging developers
A few meta-points: On 07:30 pm, [EMAIL PROTECTED] wrote: 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I'd like to stress that this is an important point; although we all know that Guido's the eventual decision makers, there are people whose opinions need to be influenced around particular areas of the code and whose opinions carry particular weight. *I* have trouble figuring out who these people are, and I think I have more than a casual outsider's understanding of the Python development process. 3. Provide a forum (a python-patch mailing list) where patches can be proposed, reviewed and revised informally but quickly. This reminds me of a post I really wanted to make after PyCon but rapidly became too sick to. The patches list really ought to be _this_ list. The fact that it isn't is indicative of a failure of the community. A good deal of the discussion here in recent months has either been highly speculative, or only tangentially related to Python's development, which is ostensibly its topic. We shouldn't really be talking about PR or deployment or any issues which aren't bug reports or patches here. I've certainly contributed somewhat to this problem myself, and I've made a resolution to stick to development issues here. This post itself is obviously in a grey area near the edge of that, but I do feel that, given the rather diverse population of readers here, we should collectively make the purpose of this forum explicit so that the python developers can use it to develop Python. One worrying trend I noticed at PyCon is that it seems that quite a lot of communication between core developers these days happens over private email. Core developers use private email to deal with pressing issues because python-dev has become crowded. This makes it difficult to see high-priority issues, as well as fostering an environment where every minor detail might get responded to with a cascade of me too posts or bike-shed discussions. The core guys have a lot of stuff to get done, and if there isn't an environment where they can do that in public, they're going to get it done in private. Taken together, all this has the overall effect of making the development process a lot harder to follow, which worsens, for example, issue #2 which I responded to above. It also creates a number of false impressions about what sort of development is really going on, since many posters here are not, in fact, working on core Python at all, just speculating about it. A few others have already pointed out the python-ideas list: http://mail.python.org/mailman/listinfo/python-ideas where the more speculative ideas should be discussed before being brought here as a patch or PEP. Of course, for more general discussion there's always good old python-list. As far as bike-shed discussions, we can all do our part by just considering what threads we all really have something useful to contribute to. Let's all try to put the python dev back in python-dev! ___ 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] PCBuild8
on Mon Mar 05 2007, Martin v. Löwis martin-AT-v.loewis.de writes: David Abrahams schrieb: I tried building with MS Visual Studio 2005 from PCBuild8/pcbuild.sln, and for me it fails miserably. The first major complaint comes when linking pythoncore, where the _init_types symbol can't be found. On the other hand, allowing MSVS to convert PCBuild/pcbuild.sln works okay. Am I missing something? Yes, it doesn't work in Python 2.5 as released. This specific problem has been fixed in the trunk and the 2.5 branch several months ago, so I recommend to use either of these Okay, thanks. (or use VS 2003 to build the released version). VS2005 seems to work just fine for the released version as long as I stay away from the PCBuild8/ stuff. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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] PCBuild8
Andrew MacKeith schrieb: Is there a scheduled date for the release of Python-2.5.1 ? There was a scheduled date, but it then interfered with the schedule of the people executing it, so there is none at the moment. I think we will release 2.5.1 in April. I presume that the PCBuild8 directory should be used when building in 64 bit on Win64. No. The official binaries both for Itanium and AMD64 (which are both in 64 bit on Win64) are created with the PCbuild directory. See PCbuild/readme.txt. Regards, Martin ___ 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] Encouraging developers
On Monday 05 March 2007 8:09 pm, Oleg Broytmann wrote: On Mon, Mar 05, 2007 at 07:30:20PM +, Phil Thompson wrote: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. I am afraid this could lead to proliferation of low-quality patches. A patch must touch at least code, documentation and tests, be tested itself and must not break other tests. These requirements demand higher expertise. I'm not sure what your point is. My point is that, if you want to encourage people to become core developers, they have to have a method of graduating through the ranks - learning (and being taught) as they go. To place a very high obstacle in their way right at the start is completely counter-productive. Phil ___ 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
[Python-Dev] locals(), closures, and IronPython...
def a():
x = 4
y = 2
def b():
print y, locals()
print locals()
b()
a()
in CPython prints:
{'y': 2, 'x': 4, 'b': function b at 0x020726F0}
2 {'y': 2}
I'm wondering if it's intentional that these don't print dictionaries w/ the
same contents or if it's more an accident of the implementation. In other
words would it be reasonable for IronPython to promote all of the locals of a
into b's dictionary when both a and b call locals?
We currently match CPython's behavior here - at least in what we display
although possibly not in the lifetimes of objects. We're considering an
internal change which might alter the behavior here though and end up
displaying all the members.
___
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] Adding socket timeout to urllib2
On 3/5/07, Facundo Batista [EMAIL PROTECTED] wrote: I studied which modifications I need to make into urllib2 to support a socket timeout. - I'll modify urlopen for it to accept a socket_timeout parameter, default to None I'd call it timeout. There can't really be much ambiguity can there? - Request will also accept a socket_timeout parameter, default to None. It will keep it in a socket_timeout attribute, so it could be added/modified from outside. Ditto for the name. - OpenerDirector's 'open' method will accept socket_timeout, and build the Request object with it So, when it gets into the Handlers, how it'll be used? I checked the Handlers, and here is a resume of their 'open' or 'open'-like methods: - AbstractHTTPHandler: receives a class, and uses its .request and .getresponse methods - HTTPHandler: just calls AbstractHTTPHandler.do_open with httplib.HTTPConnection - HTTPSHandler: just calls AbstractHTTPHandler.do_open with httplib.HTTPSConnection - UnknownHandler: raises an Error - FileHandler: opens a file in a local host - FTPHandler: uses sockets in ftplib.FTP().connect, .login, .cwd, and .ntransfercmd, all through urllib's ftwrapper object - CacheFTPHandler: instantiates ftpwrapper object; does not uses it directly, though. - GopherHandler: is deprecated... So, these are the necessary further modifications in urllib2 beyond those detailed at the beggining of the mail: - Modify AbstractHTTPHandler to pass the socket_timeout parameter to the received class' methods. - Modify FTPHandler to pass the socket_timeout to ftpwrapper class. - Modify CacheFTPHandler the same way that FTPHandler Beyond that, I'll also need to: - Modify urllib.ftpwrapper to accept a socket_timeout parameter and pass it to ftplib.FTP object. - Add support to socket_timeout to ftplib's FTP object - Add support to socket_timeout to httplib's HTTPConnection and HTTPSConnection objects So, I think that in the name of clarity, I shall first modify ftplib and httplib, add socket_timeout where is necessary, and then add support to that in the more general urllib2. What do you think? Comments are very appreciated. I say your next step should be to submit a patch, perhaps incorporating the work that Skip has already done. You could also reduce the amount of work to be done initially by only handling http. At this point I expect that'll cover 99% of all uses. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] locals(), closures, and IronPython...
Jeremy Hylton has been asking questions about this too at the sprint
after PyCon. I'm tempted to accept that the exact behavior of locals()
is implementation-defined (IOW undefined :-) as long as it includes
the locals defined in the current scope; whether it also includes free
variables could be debatable. I don't know too many good use cases for
locals() apart from learning about the implementation I think this
might be okay. Though a PEP might be in order to get agreement between
users, developers and other implementation efforts (e.g. PyPy,
Jython).
On 3/5/07, Dino Viehland [EMAIL PROTECTED] wrote:
def a():
x = 4
y = 2
def b():
print y, locals()
print locals()
b()
a()
in CPython prints:
{'y': 2, 'x': 4, 'b': function b at 0x020726F0}
2 {'y': 2}
I'm wondering if it's intentional that these don't print dictionaries w/ the
same contents or if it's more an accident of the implementation. In other
words would it be reasonable for IronPython to promote all of the locals of
a into b's dictionary when both a and b call locals?
We currently match CPython's behavior here – at least in what we display
although possibly not in the lifetimes of objects. We're considering an
internal change which might alter the behavior here though and end up
displaying all the members.
___
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/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Encouraging developers
A.M. Kuchling [EMAIL PROTECTED] wrote: At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. Thomas Wouters apparently has private scripts that perform the conversion. What needs to be done to move ahead with this idea? Using git-svn to track a SVN repository seems to work well. It would be trivial to setup a cron job on one of the python.org machines that would create a publicly accessible repository. To get changes back into SVN is pretty easy too. Someone with SVN access would pull the changes into their own git repository and then use git-svn to commit them. In my experience, committed changes look just like they would if they were done without git. There are other tools out there for Bzr and Mercurial but I have no experience with them. I've used Bzr but git seems a better fit for python-dev, even though it's harder to learn. If some decides to do this, I suggest reading http://git.or.cz/gitwiki/GitCommonMistakes . Neil ___ 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] Encouraging developers
On Monday 05 March 2007 9:38 pm, Thomas Wouters wrote: On 3/5/07, A.M. Kuchling [EMAIL PROTECTED] wrote: From http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python 4. The patch mafia. I like everyone on python-dev that I meet, but somehow it is annoyingly difficult to get a patch into Python. Like threading, and the stdlib, this is a mixed blessing: you certainly don't want every Joe Schmoe checking in whatever crud he wants. However, the barrier is high enough that I no longer have much interest in spending the time to shepherd a patch through. Yes, this is probably all my fault -- but I still hate it! FWIW, I have a related perception that we aren't getting new core developers. These two problems are probably related: people don't get patches processed and don't become core developers, and we don't have enough core developers to process patches in a timely way. And so we're stuck. Any ideas for fixing this problem? A better patch-tracker, better procedures for reviewing patches surounding this new tracker, one or more proper dvcs's for people to work off of. I'm not sure about 'identifying core developers' as we're all volunteers, with dayjobs for the most part, and only a few people seem to care enough about python as a whole. I don't think that that is true. I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Putting the burden of patch review on the developers that say they can cover it might easily burn them out. (I see Martin handle a lot of patches, for instance, and I would love to help him, but I just can't find the time to review the patches on subjects I know much about, let alone the rest of the patches.) While submitting patches is good, there's a lot more to it than just submitting the 5-line code change to submit a bug/feature, and reviewing takes a lot of time and effort. So there is something wrong there as well. I don't think it's unreasonable to ask for help from the submitters like we do, or ask them to write tests and docs and such. Of course it's not unreasonable. I would expect to be told that a patch must have tests and docs before it will be finally accepted. However, before I add those things to the patch I would like some timely feedback from those with more experience that my patch is going in the right direction. I want somebody to give it a quick look, not a full blown review. The process needs to keep people involved in it - at the moment submitting a patch is fire-and-forget. Phil ___ 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] Encouraging developers
Neil Schemenauer [EMAIL PROTECTED] wrote: Using git-svn to track a SVN repository seems to work well. It would be trivial to setup a cron job on one of the python.org machines that would create a publicly accessible repository. I guess Andrew was looking for specific instructions. Install git and git-svn. For Debian stable, you can get them from http://backports.org/debian/pool/main/g/git-core/. Initialize the repository: git-svn init http://svn.foo.org/project/trunk Fetch versions from SVN: git-svn fetch I think the fetch can be run periodically from a cron job. The repository can be cloned via HTTP but it's much faster to use the git server which runs on it's own TCP port. Neil ___ 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] Encouraging developers
Phil Thompson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | On Monday 05 March 2007 6:46 pm, A.M. Kuchling wrote: | FWIW, I have a related perception that we aren't getting new core | developers. These two problems are probably related: people don't get | patches processed and don't become core developers, and we don't have | enough core developers to process patches in a timely way. And so | we're stuck. | | Any ideas for fixing this problem? | | 1. Don't suggest to people that, in order to get their patch reviewed, they | should review other patches. The level of knowledge required to put together | a patch is much less than that required to know if a patch is the right one. | | 2. Publically identify the core developers and their areas of expertise and | responsibility (ie. which parts of the source tree they own). | | 3. Provide a forum (a python-patch mailing list) where patches can be | proposed, reviewed and revised informally but quickly. | | 4. Acceptance by core developers that only half the job is developing the | core - the other half is mentoring potential future core developers. Tracker item review is an obvious bottleneck in Python development. In particular, reviewing patches appears not to be nearly as self-motivating as writing them, and other activities. So I think the PSF should pay one or more people to do so. Possibly set up a patch review fund and solicit donations. And, donators should get priority attention to their submissions. For commercial developers, this would probably be cheaper, given the value of their time, than reviewing five other submissions. 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/archive%40mail-archive.com
Re: [Python-Dev] locals(), closures, and IronPython...
Thanks Guido. It might take some time (and someone may very well beat me to it
if they care a lot) but I'll see if we can get the PEP started.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van Rossum
Sent: Monday, March 05, 2007 2:14 PM
To: Dino Viehland
Cc: python-dev@python.org
Subject: Re: [Python-Dev] locals(), closures, and IronPython...
Jeremy Hylton has been asking questions about this too at the sprint
after PyCon. I'm tempted to accept that the exact behavior of locals()
is implementation-defined (IOW undefined :-) as long as it includes
the locals defined in the current scope; whether it also includes free
variables could be debatable. I don't know too many good use cases for
locals() apart from learning about the implementation I think this
might be okay. Though a PEP might be in order to get agreement between
users, developers and other implementation efforts (e.g. PyPy,
Jython).
On 3/5/07, Dino Viehland [EMAIL PROTECTED] wrote:
def a():
x = 4
y = 2
def b():
print y, locals()
print locals()
b()
a()
in CPython prints:
{'y': 2, 'x': 4, 'b': function b at 0x020726F0}
2 {'y': 2}
I'm wondering if it's intentional that these don't print dictionaries w/ the
same contents or if it's more an accident of the implementation. In other
words would it be reasonable for IronPython to promote all of the locals of
a into b's dictionary when both a and b call locals?
We currently match CPython's behavior here - at least in what we display
although possibly not in the lifetimes of objects. We're considering an
internal change which might alter the behavior here though and end up
displaying all the members.
___
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/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Encouraging developers
On Mon, Mar 05, 2007, Terry Reedy wrote: Tracker item review is an obvious bottleneck in Python development. In particular, reviewing patches appears not to be nearly as self-motivating as writing them, and other activities. So I think the PSF should pay one or more people to do so. Possibly set up a patch review fund and solicit donations. And, donators should get priority attention to their submissions. For commercial developers, this would probably be cheaper, given the value of their time, than reviewing five other submissions. There also seems to be a sense that we're waiting to get off SourceForge and using our own tracker. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I disrespectfully agree. --SJM ___ 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] locals(), closures, and IronPython...
Dino Viehland [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
def a():
x = 4
y = 2
def b():
print y, locals()
print locals()
b()
a()
in CPython prints:
{'y': 2, 'x': 4, 'b': function b at 0x020726F0}
2 {'y': 2}
I'm wondering if it's intentional that these don't print dictionaries w/
the same contents or if it's more an accident of the implementation. In
other words would it be reasonable for IronPython to promote all of the
locals of a into b's dictionary when both a and b call locals?
==
This version
def a():
x = 4
y = 2
def b():
print y, locals()
print locals()
return b
a()()
has essentially the same output, as it should. Do you really want the
binding of 'x' and 'b' to survive the a's return? I see no reason why a's
call of locals() should affect this either way. Which is to say, why the
compilation of b should be affected by the code that follows it.
This version also has the same output
def a():
x = 4
def b():
print y, locals()
y = 2
print locals()
return b
a()()
whereas this omits y from a's output, but not b's:
def a():
x = 4
def b():
print y, locals()
print locals()
y = 2
return b
a()()
and would also if b were called instead of returned, as in your version.
So it would not make too much sense for the two printouts to match.
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/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 05/03/2007 20.30, Phil Thompson wrote: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. +1000. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). - if there's no maintainer for a module, the *first* volunteer can become so. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. Acceptance that any patch is better than no patch. There are many valid Python programmers out there, and there are many many patches to stdlib which really don't even require a good programmer to be written. -- Giovanni Bajo ___ 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] Encouraging developers
On 05/03/2007 19.46, A.M. Kuchling wrote: At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Do we have any evidence that new developers are getting frustrated because they can't handle their patches well enough with the current tools? -- Giovanni Bajo ___ 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] Encouraging developers
On 3/5/07, Giovanni Bajo [EMAIL PROTECTED] wrote: On 05/03/2007 19.46, A.M. Kuchling wrote: At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Do we have any evidence that new developers are getting frustrated because they can't handle their patches well enough with the current tools? We asked people attending the Python-Dev panel at PyCon whether the use of a distributed VCS would encourage them to work on the core so that they could do their own commits in their own branch and some people did raise their hands. Plus it's just handy sometimes to be able to do commits when you lack network access. -Brett ___ 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] Encouraging developers
On 3/5/07, Brett Cannon [EMAIL PROTECTED] wrote: On 3/5/07, Giovanni Bajo [EMAIL PROTECTED] wrote: On 05/03/2007 19.46, A.M. Kuchling wrote: At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Do we have any evidence that new developers are getting frustrated because they can't handle their patches well enough with the current tools? [snip] Plus it's just handy sometimes to be able to do commits when you lack network access. Seconded. I don't know how much it impacts new developers, but I know I get frustrated because of this. Collin Winter ___ 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] Encouraging developers
On Mon, Mar 05, 2007 at 11:30:06PM +, Neil Schemenauer wrote: I guess Andrew was looking for specific instructions. ... I'm happy to let the ball sit in Thomas's court until the Bazaar developers come out with 0.15 and run their conversion on the SVN repository. There's no burning hurry about getting this set up, so a few weeks of waiting is fine. --amk ___ 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] Encouraging developers
On Mon, Mar 05, 2007 at 08:50:46PM -, [EMAIL PROTECTED] wrote: is indicative of a failure of the community. A good deal of the discussion here in recent months has either been highly speculative, or only tangentially related to Python's development, which is ostensibly its topic. We shouldn't really be talking about PR or deployment or any issues which aren't bug reports or patches here. I don't recall any PR threads in python-dev, but do agree that language speculations usually lead to long threads that are very boring. It would be nice to focus more on concrete development questions, and usually we do manage to focus when there's an impending release. One problem may be that there *aren't* maintainers for various subsystems; various people have contributed bugfixes and patches for, say, urllib, but I have no idea what single person I would go to for a problem. Is it worth creating a wiki page listing people and the modules they're responsible for? Or does something like this already exist? --amk ___ 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] Encouraging developers
Giovanni Bajo [EMAIL PROTECTED] wrote: On 05/03/2007 20.30, Phil Thompson wrote: 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. Sometimes code is correct. Sometimes code is complete. Just because a module hasn't been significantly altered or updated recently doesn't mean that it is outdated or broken. Asyncore, for example, is more or less feature complete for a minimal asynchronous socket framework. Could it gain more features (like good SSL support) or have better error handling? Of course. But it passes the test suite (via test_asynchat), so I would consider it *not* broken. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). - if there's no maintainer for a module, the *first* volunteer can become so. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). Just because a patch doesn't break a module, doesn't mean the patch should be applied. Take, for example, any one of the patches currently offered against asyncore. One of them more or less changes the internal structure of the module for no other reason than to (in my opinion) be gratuitous. Certainly it has some good ideas, but it would be better to adapt portions rather than take it completely - which is what you are suggesting, and which is what would have happened due to the absence of an asyncore maintainer (until I took it up). 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. Acceptance that any patch is better than no patch. There are many valid Python programmers out there, and there are many many patches to stdlib which really don't even require a good programmer to be written. Maybe, but there are also many patches I've seen that cause the resulting code to not run, revert changes made to fix bugs, etc. Vetting patches is a pain in the butt, and accepting all patches that aren't objected to is a braindead approach to patching the standard library. Indeed, every module and package should have a known and documented maintainer, but that's really the only part of your suggestions in the message I'm replying to that I would agree with. The rest gets a -1. - Josiah ___ 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] Encouraging developers
On 3/5/07, A.M. Kuchling [EMAIL PROTECTED] wrote: [snip] One problem may be that there *aren't* maintainers for various subsystems; various people have contributed bugfixes and patches for, say, urllib, but I have no idea what single person I would go to for a problem. Is it worth creating a wiki page listing people and the modules they're responsible for? Or does something like this already exist? I'd rather have this kind of ownership information attached to the individual module documentation, so interested parties don't have to go hunting around in the wiki for it. It would also be helpful to have some loose guidelines/requirements for how to become a module maintainer (e.g., we're looking for the following traits...). Collin Winter ___ 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
[Python-Dev] Access to bits for a PyLongObject
I'm working on PEP 3101, Advanced String Formatting. About the only
built-in numeric formatting I have left to do is for converting a
PyLongOjbect to binary.
I need to know how to access the bits in a PyLong. After reading
longobject.c, I can figure it out. But I'm looking for something that
might be preferable to me poking around directly in ob_size and ob_digit[].
I'm looking for something along the lines of:
for (i = 0; i _PyLong_NumBits(v); i++) {
// get i-th bit of v
}
I don't care if it's increasing or decreasing bits, I can handle either.
I realize the actual code will likely involve the 2 nested loops, but
logically this is what I need.
I can certainly do this myself, by looping over ob_digit and then over
each bit. But there's a comment in longintrepr.h that says the
internals are published only for marshal.c. Should I go ahead and
include longintrepr.h and loop over ob_digit myself, or is there some
other method? I really don't want to use _PyLong_AsByteArray, since I
don't want to do the copy.
If I'm missing some PyLongObject API, please let me know.
By the way, while doing this I noticed a bug in stringobject.c and
unicodeobject.c, relating to a missing check for 'G' precision. I'm not
sure if it could be a buffer overflow or not, without spending some more
time analyzing at it. But it seems like the potential is certainly
there. The bug is at http://python.org/sf/1673757 and a patch at
http://python.org/sf/1673759.
(I'll save my comments on how approachable python-dev is after I have
this question answered!)
Thanks for your time.
Eric.
___
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] Access to bits for a PyLongObject
Eric V. Smith schrieb: I'm working on PEP 3101, Advanced String Formatting. About the only built-in numeric formatting I have left to do is for converting a PyLongOjbect to binary. I need to know how to access the bits in a PyLong. I think it would be a major flaw in PEP 3101 if you really needed it. The long int representation should be absolutely opaque - even the fact that it is a sign+magnitude representation should be hidden. Looking at the PEP, I see that a class can implement __format__. Wouldn't it be appropriate if the long type implemented that? Implementation-wise, I would expect that long_format already does the bulk of what you need to do. OTOH, also look at _PyString_FormatLong. Regards, Martin ___ 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] Encouraging developers
A.M. Kuchling schrieb: FWIW, I have a related perception that we aren't getting new core developers. These two problems are probably related: people don't get patches processed and don't become core developers, and we don't have enough core developers to process patches in a timely way. And so we're stuck. I think this perception is partially wrong. The number of unreviewed patches has been sitting around 400 for quite some time now - so it has not been getting worse. This is mostly thanks to the (very) few reviewers that deal with patches in areas out of their primary interest. I'd like to mention Georg Brandl here. I also doubt that accepting patches more quickly would give many more patch reviewers. Most submitters are happy if their patch is accepted, and couldn't care less about other people's patches. This is fine, of course - it just means that becoming more responsive (by whatever means) would not necessarily sustain. Any ideas for fixing this problem? I had this long-term offer of a 5:1 deal. I wish more current committers would offer a similar deal, then we would be able to promise this policy prominently. This, of course, requires that committers are willing to deal with patches even if they are no experts in the subject (i.e. they will need to become experts in the process of reviewing). It might be possible to reverse this policy also: we could decide that committers maintain their write privilege only if they process patches (say, one patch per month). That would be quite intrusive, so I doubt that committers will agree to it. Tangentially related: At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. Thomas Wouters apparently has private scripts that perform the conversion. What needs to be done to move ahead with this idea? If it is this distributed repository aspect that people are after, I suggest they use svk (http://svk.elixus.org/view/HomePage). People can use it now if they want to, no need to provide additional infrastructure. For other systems, there is a choice of either hosting them at svn.python.org as well (i.e. dinsdale), or having the community host them. For dinsdale hosting, it requires a volunteer to set it up and maintain it. Given the low number of volunteers available for such tasks, I doubt this can work. For community hosting, again there is little administration necessary: hosters can already mirror svn.python.org, and run whatever conversion scripts are necessary. In this case, the task would be merely to communicate that people can already do that if they want to. Regards Martin P.S. I'm really pissed as being described as member of a mafia. ___ 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] Encouraging developers
Phil Thompson schrieb: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. People don't *have* to review patches. They just can do that if they want expedite review of their code. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I doubt this will help. Much of the code isn't owned by anybody specifically. Those parts that are owned typically find their patches reviewed and committed quickly (e.g. the tar file module, maintained by Lars Gustäbel). 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. So what do you do with core developers that don't do their job? Fire them? Regards, Martin ___ 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] Encouraging developers
[EMAIL PROTECTED] schrieb: The patches list really ought to be _this_ list. The fact that it isn't is indicative of a failure of the community. I disagree that python-dev isn't the patches list. People often discuss patches here (although much discussion is also in the tracker). One worrying trend I noticed at PyCon is that it seems that quite a lot of communication between core developers these days happens over private email. Do you know this for a fact? I'm a core developer, and I don't use private email much to discuss patches or other changes. About the only private mail that I exchange is about the mechanics of the release process (e.g. agreeing on specific days for a release). Regards, Martin ___ 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] Encouraging developers
Phil Thompson schrieb: I'm not sure what your point is. My point is that, if you want to encourage people to become core developers, they have to have a method of graduating through the ranks - learning (and being taught) as they go. To place a very high obstacle in their way right at the start is completely counter-productive. And please be assured that no such obstacle is in the submitters way. Most patches are accepted without the submitter actually reviewing any other patches. Regards, Martin ___ 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] Encouraging developers
Phil Thompson schrieb: Any ideas for fixing this problem? A better patch-tracker, better procedures for reviewing patches surounding this new tracker, one or more proper dvcs's for people to work off of. I'm not sure about 'identifying core developers' as we're all volunteers, with dayjobs for the most part, and only a few people seem to care enough about python as a whole. I don't think that that is true. I think a lot of people care, but many can't do anything about because the barrier to entry is too great. He was talking about the committers specifically who don't care about Python as-a-whole, and I think this is true. But I also believe that many contributors don't care about Python as-a-whole, in the sense that they are uninterested in learning about implementation details of libraries they will never use. What they do care about is the problems they have, and they do contribute patches for them. While submitting patches is good, there's a lot more to it than just submitting the 5-line code change to submit a bug/feature, and reviewing takes a lot of time and effort. So there is something wrong there as well. I don't think it's unreasonable to ask for help from the submitters like we do, or ask them to write tests and docs and such. Of course it's not unreasonable. I would expect to be told that a patch must have tests and docs before it will be finally accepted. However, before I add those things to the patch I would like some timely feedback from those with more experience that my patch is going in the right direction. This cannot work. It is very difficult to review a patch to fix a presumed bug if there is no test case. You might not be able to reproduce the patch without a test case at all - how could you then know whether the patch actually fixes the bug? So I really think patches should be formally complete before being submitted. This is an area were anybody can review: you don't need to be an expert to see that no test cases are contributed to a certain patch. If you really want to learn and help, review a few patches, to see what kinds of problems you detect, and then post your findings to python-dev. People then will comment on whether they agree with your review, and what additional changes they like to see. Regards, Martin ___ 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] Encouraging developers
Neil Schemenauer schrieb: I guess Andrew was looking for specific instructions. Install git and git-svn. For Debian stable, you can get them from http://backports.org/debian/pool/main/g/git-core/. Initialize the repository: git-svn init http://svn.foo.org/project/trunk Fetch versions from SVN: git-svn fetch I think the fetch can be run periodically from a cron job. The repository can be cloned via HTTP but it's much faster to use the git server which runs on it's own TCP port. And that's it? Won't you need to publish the repository somehow? Apache configuration? init.d scripts? Regards, Martin ___ 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] Encouraging developers
Collin Winter schrieb: It would also be helpful to have some loose guidelines/requirements for how to become a module maintainer (e.g., we're looking for the following traits...). That is easy to answer: Review the patches of the module, and post a message to python-dev about your findings (proposals of acceptance or rejection). Regards, Martin ___ 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] Encouraging developers
[Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. If you meant something else like knowing how to make a meaningful patch, then you've got a point. It takes a while to learn your way around the source tree and to learn the inter-relationships between the moving parts. That is just the nature of the beast. [MvL] While submitting patches is good, there's a lot more to it than just submitting the 5-line code change to submit a bug/feature, and reviewing takes a lot of time and effort. [Phil] So there is something wrong there as well. I have not idea what you're getting at.Martin's comment seems accurate to me. Unless it is a simple typo/doc fix, it takes some time to assess whether the bug is real (some things are bugs only in the eye of the submitter) and whether the given fix is the right thing to do. Of course, automatic acceptance of patches would be a crummy idea. There have been no shortage of patches complete with docs and tests that were simply not the right thing to do. [Phil] The process needs to keep people involved in it - at the moment submitting a patch is fire-and-forget. Such is the nature of a system of volunteers. If we had full-time people, it could be a different story. IMO, given an 18 month release cycle, it is perfectly acceptable for a patch to sit for a while until someone with the relavant expertise can address it. Even with a tests and docs, patch acceptance is far from automatic. That being said, I think history has shown that important bugs get addressed and put into bug fix releases without much loss of time. When Py2.5.1 goes out, I expect that all known, important bugs will have been addressed and that's not bad. Raymond ___ 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] Encouraging developers
Scott Dial schrieb: While I understand that this tit-for-tat mechanism is meant to ensure participation, I believe in reality it doesn't, as the 400-some outstanding patches you referenced elswhere indicate. I can personally attest to having a patch that is over a year old with no core developer having any interest at all with the subject matter. And to be frank, nor did I really, but I saw a problem and was capable of solving it. My lack of caring about the patch means I am not going to beat people over the head to pay attention. This system is broken for someone like me (coder) that just wants to help out (non-coders). If you don't care that much about the patch, it's not broken. As I said before, the number of unreviewed patches has been roughly stable for some time now. If the patch is not really important, it may take two years now to get it in, but eventually, it will (if you then still are interested to work on it to complete it). If nothing else, as an outsider there is no way to know why your patch gets ignored while others get swiftly dealt with. Any sort of information like this would at least provide more transparency in what may appear to be elitest processes. This is what we would need volunteer reviewers for. We can send machine confirmations, but I doubt it would help. If you need a human response, somebody must send you one, demonstrating that they actually did look at the patch. If none of the committers have the time to do so, somebody else must send the manual confirmation. Regards, Martin ___ 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] Encouraging developers
Raymond Hettinger schrieb: [Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. Indeed. IIRC, he first posted a message (under pseudonym at the time): I reviewed these patches because I didn't have anything better to do. Shortly afterwards, he was a committer. Regards, Martin ___ 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] Encouraging developers
Giovanni Bajo writes: On 05/03/2007 20.30, Phil Thompson wrote: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. +1000. Been there, done that. If the submitter doesn't have a pretty good idea that a patch is the right one, he's making substantial demands on core developer time. +1000 suggests you think that core developers are using their time with ruinously low efficiency. I think the review some patches test is exactly the right one. The requirement is not that you channel the BFDL, it's that you read the patch and bring your own knowledge of the problem to bear. This has three benefits: (1) the reviewed patches get some comments; (2) the reviewed patches come to the attention of a committer; (3) the reviewer comes to the attention of a core developer, and can be considered for commit privileges, etc. An informal version of this process is how XEmacs identifies its Reviewers (the title we give to those privileged to authorize commits to all parts of XEmacs). People who care enough to make technical comments on *others'* patches are rare, and we grab the competent ones pretty quickly. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). The XEmacs experience has been that the core developers are ministers without portfolio. You can't wait around for the owner, who may be on Mars, and you rarely need to. I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. The mess is not total, as Josiah Carlson points out. To the extent that it is a mess, it is the consequence of a process similar to the one you propose to institutionalize. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). This is what XEmacs does; it works, but it's not as effective as you might hope. What happens for us is that many modules are maintained by an interest group disjoint from the core. By giving a representative of the interest group commit privileges, things get addressed pretty quickly and competently. However, this is a convenience for users of the module more than a way of kickstarting a development process (note that the interest group already exists). This requires a separate distribution of the standard library. Two points: recall the ElementTree thread. There were other plausible candidates. The XEmacs policy in such case is that they are all considered equally, and all are allowed to be distributed with the package distribution. In Python, this would conflict with TOOWTDI. Second, where the stdlib module is closely bound to the core, the maintainer ends up being the group of core developers. It can't be any other way, it seems to me. - if there's no maintainer for a module, the *first* volunteer can become so. I doubt this will work. It is usually the case that the first volunteer is acceptable, but it shouldn't be policy. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). This is an obviously bad idea. The stdlib needs to be deliberately pruned, not arbitrarily patched. ___ 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] Encouraging developers
Giovanni Bajo writes: On 05/03/2007 19.46, A.M. Kuchling wrote: At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Of course it does. How important is a matter for individual judgment, of course. The *frustration level* with the acceptance process is certainly related to the annoyance of locally maintaining a patch in the face of a flow of upstream changes. The distributed SCMs make this *much* easier, and therefore can reduce the frustration level, at *zero* expense to the core developers (anybody with read access can maintain such a read-only repo). This is a good thing. It *is* important that the core sanction and support official mirror repos. This may or may not help the acceptance process to improve; I believe you are correct, that it will have little direct impact on the acceptance process. Nevertheless, life for third-party developers will become somewhat more pleasant, especially as they have a much easier way to exchange and refine patches. This last can feed back into the review for review bargain. ___ 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] Encouraging developers
On 5 Mar, 2007, at 19:58, [EMAIL PROTECTED] wrote: amk Any ideas for fixing this problem? Not a one. amk Tangentially related: amk At PyCon, there was general agreement that exposing a read- only amk Bazaar/Mercurial/git/whatever version of the repository wouldn't be amk too much effort, and might make things easier for external people amk developing patches. I'm not much of a version control wonk. How would these help? Can't the folks who need such stuff do some sort of anonymous svn checkout? The version management systemens mentioned are distributed systems and would allow users to have local branches, which could mak development easier for them. They can already do this using SVK, which is a distributed version control system as well but uses SVN repositories to store its data. Ronald ___ 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
