[Python-Dev] bug triage
Hi All, Is there a high volume of incoming bugs to the Python tracker? If so, I'd like to help with triaging. I think I have all the necessary access, what I'm missing is the knowledge of how to set myself up to get notifications of new bugs... How do I do that? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] bug triage
Hi Chris, > Is there a high volume of incoming bugs to the Python tracker? > If so, I'd like to help with triaging. I think I have all the necessary > access, what I'm missing is the knowledge of how to set myself up to get > notifications of new bugs... Do you really want to get such notifications? There may be a lot of them. If you want however, you can join #python-dev on IRC (irc.freenode.net) where there's a bot which posts updates of all bugs on the tracker. There's usually not a lot of discussion going on so you probably won't feel flooded. In addition to bug triage, what is needed is reviewing of existing patches, as well as writing patches for issues which haven't been addressed yet :-) Regards Antoine. ___ 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] bug triage
On 06/01/2010 11:19, Chris Withers wrote: Hi All, Is there a high volume of incoming bugs to the Python tracker? If so, I'd like to help with triaging. I think I have all the necessary access, what I'm missing is the knowledge of how to set myself up to get notifications of new bugs... How do I do that? Bug triaging is one of Python's "big needs" and anything you do to help on this score would be much appreciated. Particularly reviewing new and outstanding issues. I assumed there would be RSS feeds for bug tracker activity but can't easily find these on the tracker. There is a bot that posts activity to #python-dev, so there must be some way of getting this information. All the best, Michael cheers, Chris -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] bug triage
Michael Foord wrote: I assumed there would be RSS feeds for bug tracker activity but can't easily find these on the tracker. There is a bot that posts activity to #python-dev, so there must be some way of getting this information. Yeah, email-out is what I'm really after... I have it for my own Roundup instance so it can't be that hard to do ;-) Roché, you guys host the bug tracker, right? Is there email-out set up for it? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] bug triage
Michael Foord wrote: > I assumed there would be RSS feeds for bug tracker activity but can't > easily find these on the tracker. There is a bot that posts activity to > #python-dev, so there must be some way of getting this information. I'm pretty sure the bugs list is still the primary spooled notification mechanism: http://mail.python.org/mailman/listinfo/python-bugs-list There are also the weekly tracker activity summaries that are posted here to python-dev. 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
Re: [Python-Dev] bug triage
Nick Coghlan wrote: I'm pretty sure the bugs list is still the primary spooled notification mechanism: http://mail.python.org/mailman/listinfo/python-bugs-list That's what I was after, thanks! Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] bug triage
On Wed, Jan 6, 2010 at 8:19 AM, Chris Withers wrote: > Is there a high volume of incoming bugs to the Python tracker? > If so, I'd like to help with triaging. I think I have all the necessary > access, what I'm missing is the knowledge of how to set myself up to get > notifications of new bugs... Not notifications, but maybe a way to have a higher look of them for easy selection: http://www.taniquetil.com.ar/cgi-bin/pytickets.py Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] bug triage
On Wed, Jan 6, 2010 at 12:24 PM, Michael Foord wrote: > On 06/01/2010 11:19, Chris Withers wrote: >> >> Hi All, >> >> Is there a high volume of incoming bugs to the Python tracker? >> If so, I'd like to help with triaging. I think I have all the necessary >> access, what I'm missing is the knowledge of how to set myself up to get >> notifications of new bugs... >> >> How do I do that? >> > > Bug triaging is one of Python's "big needs" and anything you do to help on > this score would be much appreciated. Particularly reviewing new and > outstanding issues. Another useful triage I think, is to review the oldest bugs (some of them are > 5 years) and remove the ones that are not relevant anymore, or duplicate with newer entries. Tarek -- Tarek Ziadé | http://ziade.org ___ 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] bug triage
Tarek Ziadé wrote: Another useful triage I think, is to review the oldest bugs (some of them are > 5 years) and remove the ones that are not relevant anymore, or duplicate with newer entries. I'm sprinting for 2 days at PyCon, I'd verymuch be up for doing this with someone as a paired task for those 2 days... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] bug triage
On Wed, Jan 6, 2010 at 1:31 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Another useful triage I think, is to review the oldest bugs (some of >> them are > 5 years) >> and remove the ones that are not relevant anymore, or duplicate with >> newer entries. > > I'm sprinting for 2 days at PyCon, I'd verymuch be up for doing this with > someone as a paired task for those 2 days... I'll be doing Distutils stuff but I can probably help around a bit in that task: Distutils have quite a few old issues so I can tackle those ___ 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] bug triage
On Wed, 2010-01-06 at 11:30 +, Chris Withers wrote: > Michael Foord wrote: > > I assumed there would be RSS feeds for bug tracker activity but can't > > easily find these on the tracker. There is a bot that posts activity to > > #python-dev, so there must be some way of getting this information. > > Yeah, email-out is what I'm really after... I have it for my own Roundup > instance so it can't be that hard to do ;-) > > Roché, you guys host the bug tracker, right? Is there email-out set up > for it? We do, but we don't administer it. There are a few administrators taking care of it and you should be able to reach them by logging your request here: http://psf.upfronthosting.co.za/roundup/meta/ or post it to the Infrastructure mailing list: [email protected] -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za ___ 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] bug triage
Tarek Ziadé wrote: > Another useful triage I think, is to review the oldest bugs (some of > them are > 5 years) > and remove the ones that are not relevant anymore, or duplicate with > newer entries. I believe someone (Daniel Diniz, maybe?) did do a pass over those some time in the last 12 months, so most of the obviously irrelevant ones that are that old should already be gone. Not to say it isn't worth doing another pass, just saying not to get disheartened if there aren't many that can be readily closed. There are at least a few still kicking around just because they're difficult to deal with (there's an ancient one to do with one of the ways circular imports can fail that I occasionally go back and reread before moving on to something more tractable). 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
Re: [Python-Dev] bug triage
On Wed, 06 Jan 2010 11:41:28 +, Chris Withers wrote: > Nick Coghlan wrote: > > I'm pretty sure the bugs list is still the primary spooled notification > > mechanism: > > http://mail.python.org/mailman/listinfo/python-bugs-list > > That's what I was after, thanks! Just for completeness, there's also new-bugs-announce if you want just *new* bug notification. That's more for people who want to watch for bugs they want to become nosy on, though; if you are doing triage python-bugs-list is what you want. Please also read http://www.python.org/dev/workflow/ if you haven't already. Thanks for being willing to chip in! --David ___ 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] bug triage
On Wed, Jan 6, 2010 at 06:57, Nick Coghlan wrote: > I believe someone (Daniel Diniz, maybe?) did do a pass over those some > time in the last 12 months, so most of the obviously irrelevant ones > that are that old should already be gone. Not to say it isn't worth > doing another pass, just saying not to get disheartened if there aren't > many that can be readily closed. > > There are at least a few still kicking around just because they're > difficult to deal with (there's an ancient one to do with one of the > ways circular imports can fail that I occasionally go back and reread > before moving on to something more tractable). > > Cheers, > Nick. > On the topic of bugs that can be readily closed (literally), I've recently come across a number of issues which appear to be sitting in a patch or review stage, but their patches have been committed and the issue remains open. What is the best course of action there? I'd just go ahead and close the issue myself but I don't have tracker privileges. I'm willing to help out with another Daniel Diniz-esque triage sweep if that would help. Brian ___ 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] bug triage
On Jan 6, 2010, at 7:29 AM, Tarek Ziadé wrote: > On Wed, Jan 6, 2010 at 12:24 PM, Michael Foord > wrote: >> On 06/01/2010 11:19, Chris Withers wrote: >>> >>> Hi All, >>> >>> Is there a high volume of incoming bugs to the Python tracker? >>> If so, I'd like to help with triaging. I think I have all the necessary >>> access, what I'm missing is the knowledge of how to set myself up to get >>> notifications of new bugs... >>> >>> How do I do that? >>> >> >> Bug triaging is one of Python's "big needs" and anything you do to help on >> this score would be much appreciated. Particularly reviewing new and >> outstanding issues. > > Another useful triage I think, is to review the oldest bugs (some of > them are > 5 years) > and remove the ones that are not relevant anymore, or duplicate with > newer entries. I was actually thinking about that the other day when I saw that the average age of bugs on the Python tracker was at some hideously large 3 digit number. The 'success' statistic would be to bring that down below, say, 100. S ___ 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] bug triage
> "Nick" == Nick Coghlan writes: Nick> I'm pretty sure the bugs list is still the primary spooled Nick> notification mechanism: Nick> http://mail.python.org/mailman/listinfo/python-bugs-list Actually, there is a new-bugs-announce list: http://mail.python.org/mailman/listinfo/new-bugs-announce Skip ___ 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] bug triage
Le Wed, 06 Jan 2010 08:57:42 -0600, Brian Curtin a écrit : > On the topic of bugs that can be readily closed (literally), I've > recently come across a number of issues which appear to be sitting in a > patch or review stage, but their patches have been committed and the > issue remains open. What is the best course of action there? Post a message on the issue asking for info. ___ 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] bug triage
Antoine Pitrou pitrou.net> writes: > > Le Wed, 06 Jan 2010 08:57:42 -0600, Brian Curtin a écrit : > > On the topic of bugs that can be readily closed (literally), I've > > recently come across a number of issues which appear to be sitting in a > > patch or review stage, but their patches have been committed and the > > issue remains open. What is the best course of action there? > > Post a message on the issue asking for info. Ok, I realize my answer might have been a bit terse :-) The patch might be waiting to be merged in all development branches, or it may not totally resolve the issue, or perhaps documentation needs to be updated, or perhaps it is pending a verdict from the buildbots, etc. You can't deduce that the issue is completely fixed from the simple fact that something has been committed. Regards Antoine Pitrou. ___ 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] bug triage
On Wed, Jan 6, 2010 at 06:57, Brian Curtin wrote: > On Wed, Jan 6, 2010 at 06:57, Nick Coghlan wrote: > >> I believe someone (Daniel Diniz, maybe?) did do a pass over those some >> time in the last 12 months, so most of the obviously irrelevant ones >> that are that old should already be gone. Not to say it isn't worth >> doing another pass, just saying not to get disheartened if there aren't >> many that can be readily closed. >> >> There are at least a few still kicking around just because they're >> difficult to deal with (there's an ancient one to do with one of the >> ways circular imports can fail that I occasionally go back and reread >> before moving on to something more tractable). >> >> Cheers, >> Nick. >> > > On the topic of bugs that can be readily closed (literally), I've recently > come across a number of issues which appear to be sitting in a patch or > review stage, but their patches have been committed and the issue remains > open. What is the best course of action there? I'd just go ahead and close > the issue myself but I don't have tracker privileges. > > If a core developer is willing to step forward and vouch for you to get tracker privileges then I will give them to you. We are trying to give out tracker privs w/ less time than required to get commit privileges. So as long as you have helped out on a few issues in a positive and correct way that should be enough to get one of the regulars who perform triage to notice. -Brett I'm willing to help out with another Daniel Diniz-esque triage sweep if that > would help. > > Brian > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > > ___ 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] bug triage
In article <[email protected]>, Nick Coghlan wrote: > Michael Foord wrote: > > I assumed there would be RSS feeds for bug tracker activity but can't > > easily find these on the tracker. There is a bot that posts activity to > > #python-dev, so there must be some way of getting this information. > > I'm pretty sure the bugs list is still the primary spooled notification > mechanism: > http://mail.python.org/mailman/listinfo/python-bugs-list Also, that mailing list (along with most python development related mailing lists) is mirrored at gmane.org which means it can also be obtained via a newsreader (NNTP) or various RSS feeds. http://dir.gmane.org/gmane.comp.python.bugs -- Ned Deily, [email protected] ___ 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
[Python-Dev] --enabled-shared broken on freebsd5?
(This may occur on more platforms - I can test on more unix platforms if the consensus is this is an actual problem and I'm not just a nut) On freebsd5, if you do a simple ./configure --enable-shared in current (2.7) trunk, your python shared library will build properly, but all modules will fail to find the shared library and thus fail to build: gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_struct.o -L/u1/tmp/python2.7a1/lib -L/usr/local/lib -lpython2.7 -o build/lib.freebsd-5.3-RELEASE-i386-2.7/_struct.so /usr/bin/ld: cannot find -lpython2.7 building '_ctypes_test' extension ... This of course is because libpython2.7.so is in the current directory and not (yet) installed in /usr/local/lib. I've made a very simple fix for this problem that works, but at least to me smells a bit funny, which is to modify setup.py to add the following to detect_modules(): # If we did --enable-shared, we need to be able to find the library # we just built in order to build the modules. if platform == 'freebsd5': add_dir_to_list(self.compiler_obj.library_dirs, '.') Which brings me to a few questions: a) Does this seem like a real problem, or am I missing something obvious? b) Does this fix seem like the sensible thing to do? (it seems at least that we ought to check that the user configured --enable-shared and only set -L. in that case, if that's possible) Setting --enable-shared when you actually have a libpython2.7.so in /usr/local/lib (or whatever --prefix you've selected) is possibly even more dangerous, because it may succeed in linking against a differently-built library than what you intended. -- Nick ___ 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] --enabled-shared broken on freebsd5?
On Wed, Jan 6, 2010 at 16:14, Nicholas Bastin wrote: > This of course is because libpython2.7.so is in the current directory > and not (yet) installed in /usr/local/lib. One minor correction - as you could see from the compile line, the actual --prefix in this case is /u1/tmp/python2.7a1, but the libraries obviously aren't installed there yet either. Perhaps a better fix than setting -L. would be to put the shared library in build/lib.freebsd-5.3-RELEASE-i386-2.7 and add that to the library path for the linker (the build creates this directory, but installs nothing in it). -- Nick ___ 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] --enabled-shared broken on freebsd5?
> b) Does this fix seem like the sensible thing to do? No. Linking in setup.py should use the same options as if the module was built as *shared* through Modules/Setup, which, IIUC, should use BLDLIBRARY. Regards, Martin ___ 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] --enabled-shared broken on freebsd5?
On Wed, Jan 6, 2010 at 17:21, "Martin v. Löwis" wrote: >> b) Does this fix seem like the sensible thing to do? > > No. Linking in setup.py should use the same options as if the module > was built as *shared* through Modules/Setup, which, IIUC, should use > BLDLIBRARY. Thanks for that pointer, that makes much more sense. Indeed, BLDLIBRARY on FreeBSD* is set to '-L. -lpython$(VERSION)' if you set --enable-shared, but somehow that piece of information doesn't propagate into the module build. More investigation to be done... -- Nick ___ 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] bug triage
On Wed, 06 Jan 2010 11:03:32 -0800, Brett Cannon wrote: > On Wed, Jan 6, 2010 at 06:57, Brian Curtin wrote: > > On the topic of bugs that can be readily closed (literally), I've recently > > come across a number of issues which appear to be sitting in a patch or > > review stage, but their patches have been committed and the issue remains > > open. What is the best course of action there? I'd just go ahead and close > > the issue myself but I don't have tracker privileges. > > > > > If a core developer is willing to step forward and vouch for you to get > tracker privileges then I will give them to you. We are trying to give out > tracker privs w/ less time than required to get commit privileges. So as > long as you have helped out on a few issues in a positive and correct way > that should be enough to get one of the regulars who perform triage to > notice. > > -Brett I've done a quick scan of issues Brian is nosy on to refresh my memory, and I'd say he's definitely been making positive contributions. I'm willing to volunteer to keep an eye on his triage work for a while if you grant him tracker privs. Brian, I assume you'll be cognizant of Antoine's advice about making sure a bug really should be closed before closing it :) Hanging out in #python-dev on freenode while working on issues can be helpful, as well, since you can quickly ask whoever is there for second opinions on particular bugs. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] bug triage
On Wed, Jan 6, 2010 at 17:22, R. David Murray wrote: > > On Wed, 06 Jan 2010 11:03:32 -0800, Brett Cannon wrote: > > On Wed, Jan 6, 2010 at 06:57, Brian Curtin > wrote: > > > On the topic of bugs that can be readily closed (literally), I've > recently > > > come across a number of issues which appear to be sitting in a patch or > > > review stage, but their patches have been committed and the issue > remains > > > open. What is the best course of action there? I'd just go ahead and > close > > > the issue myself but I don't have tracker privileges. > > > > > > > > If a core developer is willing to step forward and vouch for you to get > > tracker privileges then I will give them to you. We are trying to give > out > > tracker privs w/ less time than required to get commit privileges. So as > > long as you have helped out on a few issues in a positive and correct way > > that should be enough to get one of the regulars who perform triage to > > notice. > > > > -Brett > > I've done a quick scan of issues Brian is nosy on to refresh my > memory, and I'd say he's definitely been making positive contributions. > I'm willing to volunteer to keep an eye on his triage work for a while > if you grant him tracker privs. > > Done for the username brian.curtin (email doesn't match the one Brian emailed from so do let me know, Brian if this is the right username). Welcome aboard! -Brett > Brian, I assume you'll be cognizant of Antoine's advice about making > sure a bug really should be closed before closing it :) Hanging out in > #python-dev on freenode while working on issues can be helpful, as well, > since you can quickly ask whoever is there for second opinions on > particular bugs. > > -- > R. David Murray www.bitdance.com > Business Process Automation - Network/Server Management - Routers/Firewalls > ___ 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] bug triage
On Wed, Jan 6, 2010 at 19:28, Brett Cannon wrote: > > > On Wed, Jan 6, 2010 at 17:22, R. David Murray wrote: > >> >> On Wed, 06 Jan 2010 11:03:32 -0800, Brett Cannon wrote: >> > On Wed, Jan 6, 2010 at 06:57, Brian Curtin >> wrote: >> > > On the topic of bugs that can be readily closed (literally), I've >> recently >> > > come across a number of issues which appear to be sitting in a patch >> or >> > > review stage, but their patches have been committed and the issue >> remains >> > > open. What is the best course of action there? I'd just go ahead and >> close >> > > the issue myself but I don't have tracker privileges. >> > > >> > > >> > If a core developer is willing to step forward and vouch for you to get >> > tracker privileges then I will give them to you. We are trying to give >> out >> > tracker privs w/ less time than required to get commit privileges. So as >> > long as you have helped out on a few issues in a positive and correct >> way >> > that should be enough to get one of the regulars who perform triage to >> > notice. >> > >> > -Brett >> >> I've done a quick scan of issues Brian is nosy on to refresh my >> memory, and I'd say he's definitely been making positive contributions. >> I'm willing to volunteer to keep an eye on his triage work for a while >> if you grant him tracker privs. >> >> > Done for the username brian.curtin (email doesn't match the one Brian > emailed from so do let me know, Brian if this is the right username). > Welcome aboard! > > Yep, that's the one. Thanks! ___ 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
[Python-Dev] GIL required for _all_ Python calls?
Hi, I've been wondering whether it's possible to release the GIL in the regex engine during matching. I know that it needs to have the GIL during memory-management calls, but does it for calls like Py_UNICODE_TOLOWER or PyErr_SetString? Is there an easy way to find out? Or is it just a case of checking the source files for mentions of the GIL? The header file for PyList_New, for example, doesn't mention it! Thanks ___ 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] GIL required for _all_ Python calls?
MRAB wrote: > Hi, > > I've been wondering whether it's possible to release the GIL in the > regex engine during matching. > > I know that it needs to have the GIL during memory-management calls, but > does it for calls like Py_UNICODE_TOLOWER or PyErr_SetString? Is there > an easy way to find out? Or is it just a case of checking the source > files for mentions of the GIL? The header file for PyList_New, for > example, doesn't mention it! > > Thanks Anything that Py_INCREF or Py_DECREF's should have the GIL, or you may get concurrent updating of the value, and then the final value is wrong. (two threads do 5+1 getting 6, rather than 7, and when the decref, you end up at 4 rather than back at 5). AFAIK, the only things that don't require the GIL are macro functions, like PyString_AS_STRING or PyTuple_SET_ITEM. PyErr_SetString, for example, will be increfing and setting the exception state, so certainly needs the GIL to be held. John =:-> ___ 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] GIL required for _all_ Python calls?
2010/1/6 John Arbash Meinel : > Anything that Py_INCREF or Py_DECREF's should have the GIL, or you may > get concurrent updating of the value, and then the final value is wrong. > (two threads do 5+1 getting 6, rather than 7, and when the decref, you > end up at 4 rather than back at 5). Correct. > > AFAIK, the only things that don't require the GIL are macro functions, > like PyString_AS_STRING or PyTuple_SET_ITEM. PyErr_SetString, for > example, will be increfing and setting the exception state, so certainly > needs the GIL to be held. As a general rule, I would say, no Py* macros are safe without the gil either (the exception being Py_END_ALLOW_THREADS), since they mutate Python objects which must be protected. -- Regards, Benjamin ___ 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] GIL required for _all_ Python calls?
On Wed, Jan 6, 2010 at 7:32 PM, Benjamin Peterson wrote: > 2010/1/6 John Arbash Meinel : > > AFAIK, the only things that don't require the GIL are macro functions, > > like PyString_AS_STRING or PyTuple_SET_ITEM. PyErr_SetString, for > > example, will be increfing and setting the exception state, so certainly > > needs the GIL to be held. > > As a general rule, I would say, no Py* macros are safe without the gil > either (the exception being Py_END_ALLOW_THREADS), since they mutate > Python objects which must be protected. That's keeping it on the safe side, since there are some macros like PyString_AS_STRING() that are also safe, *if* you are owning at least one reference to the string object. At the same time, "no Py* macros" is not quite strong enough, since if you called PyString_AS_STRING() before releasing the GIL but you don't own a reference to the string object, the string might be deallocated behind your back by another thread. A better rule would be "you may access the memory buffer in a PyString or PyUnicode object with the GIL released as long as you own a reference to the string object." Everything else is out of bounds (or not worth the bother). -- --Guido van Rossum (python.org/~guido) ___ 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
