Re: [Python-Dev] Save file by using file() function and fileDialog()
Hello,
On Thu, Oct 30, 2008 at 07:35, Sonia [EMAIL PROTECTED] wrote:
I m using fileDialog(self, message, path, filename, filter,
aStyle(opotional)) to save the file.
In my code, i used fileDialog to show save dialog box and when we click on
save button, it should save that file which is of txt type (filter =
'*.txt'). But when we click on save button it returns error: coercing to
unicode: need string or buffer, list found rather than saving / creating a
file. I also tried f = file(myfile, 'w', 1000) instead of f = file(myfile,
'w'), where 1000 is buffer size, but both have the same error. where as if
we use
file( filename[, mode[, bufsize]])
, then it creates a file of specified type. But it is not working in
fileDialog(). Why?Where i m wrong?
What should i do?
Following is my code:
def on_btn2_mouseClick(self, event):
aStyle = wx.SAVE|wx.HIDE_READONLY|wx.OVERWRITE_PROMPT
filter = '*.txt'
result = dialog.fileDialog(self, 'ist def', '', 'n', wildcard,
aStyle)
myfile= result.paths
if result.accepted == True :
f = file(myfile, 'w')
f.write('my file')
f.close()
The python-dev mailing list is about the development of Python, not
the development with Python.
Please send this kind of questions to the comp.lang.python newsgroup,
or the wxPython-users mailing list.
There are many python users there willing to help.
Furthermore wxPython is not developed here (or is it PythonCard?), so
you'll get little expertise from us.
(a hint however: result.paths likely returns a list of paths; try
result.paths[0] to get a file name)
--
Amaury Forgeot d'Arc
___
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] My patches
Hi, Since some months, I'm trying to improve Python but it's difficult because I'm not allowed to push patches and I have to wait for some reviews and then for someone interrested by my patches. Sometimes I just get a good reaction like nice patch and then nothing. Should I stop sending new patches and work on another project, improve old patches and send an email everydays to the mailing list to get some reaction? Barry doesn't want to release Python 3.0rc2 because of release blocker issues. Guido asked if the mailing list has collapsed. I don't understand: you want help, but some of my patches are waiting since many weeks ago... The problem is not just about me, but about anyone trying to contribute to Python: if it's to hard to contribute, people would just move to another more reactive project. --- Well, here is a short list of my patches waiting to be commited: http://bugs.python.org/issue3727 (fix poplib for python3) + patch posted 13 days ago http://bugs.python.org/issue1210 (fix imaplib for python3) + patch posted 16 days ago http://bugs.python.org/issue4036 (support bytes for subprocess.Popen) + patch posted 22 days ago http://bugs.python.org/issue4021 (improve tokenize.detect_encoding) + patch posted 28 days ago + reviewed by amaury http://bugs.python.org/issue4008 (IDLE: unicode fix checksyntax()) + patch posted 28 days ago http://bugs.python.org/issue3954 (fix _hotshot.logreader) + patch posted 39 days ago + reviewed by amaury and georg.brandl http://bugs.python.org/issue3880 (fix _tkinter._flatten) + patch posted 44 days ago + reviewed by gpolo http://bugs.python.org/issue3632 (ensure GIL in _PyObject_Dump) + patch posted 70 days ago + reviewed by amaury -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ 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] My patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 30, 2008, at 11:08 AM, Victor Stinner wrote: Since some months, I'm trying to improve Python but it's difficult because I'm not allowed to push patches and I have to wait for some reviews and then for someone interrested by my patches. Sometimes I just get a good reaction like nice patch and then nothing. Should I stop sending new patches and work on another project, improve old patches and send an email everydays to the mailing list to get some reaction? Barry doesn't want to release Python 3.0rc2 because of release blocker issues. Guido asked if the mailing list has collapsed. I don't understand: you want help, but some of my patches are waiting since many weeks ago... The problem is not just about me, but about anyone trying to contribute to Python: if it's to hard to contribute, people would just move to another more reactive project. Victor, don't despair! Your contributions are appreciated. Let me remind you though that I've been mostly unavailable for the past two weeks at a work conference. I won't have time to look at anything until Monday at the earliest. That's why I set the 3.0 schedule the way I did. One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. It will be much easier for others to merge your changes, test them, review them, etc. and it will be much easier for you to track changes in the official trunk as other code lands. In any case, I know it's frustrating not to get good timely feedback, but such is the nature of open source projects. Please be patient and don't worry. I'll look at your patches when I'm back in the real world. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkJlMoACgkQ2YZpQepbvXG0DgCePlFiKrAH/UQkQhLb8Mr7dwtd mmUAoJN2pOJN40fOQ0otMSgeVCt5sqLL =Mnta -END PGP SIGNATURE- ___ 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] My patches
Let me remind you though that I've been mostly unavailable for the past two weeks at a work conference. Cool, you're back :-) But my email was not against you. That's why I set the 3.0 schedule the way I did. Personnaly, I don't want to get python 3.0 final with some broken modules or some criticial problems. So it's a good thing to delay the release until bugs are fixed. One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial, GIT, anything else? I tried Mercurial which is nice (at least some small project). But I think that GIT is the fatest and most robust system. you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. Right and it's very difficult to manage patches using the tracker. After writing the patch, I have to revert all patches to be able to write a new patch because it's easier to generate a patch in this way. But some patches depend on other patches :-/ In any case, I know it's frustrating not to get good timely feedback A friend told me that his patch took 6 months to be applied :-/ (don't know which one) If Python would be more reactive, more developer will be attracted. The communication is very important in an open source project. I contributed to many many projects, and I can say that Python is already one of the most reactive project! But it can be better ;-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ 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] My patches
On Thursday 30 October 2008, Victor Stinner wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial, GIT, anything else? Bazaar. Take a look at the developers' pages on python.org, they mention that a BZR checkout is available. I know that it works (though the initial checkout is glacially slow) but I don't know what official support it has or what is planned with it. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.satorlaser.de/ ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. ** ___ 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] My patches
Ulrich Eckhardt wrote: On Thursday 30 October 2008, Victor Stinner wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial, GIT, anything else? Bazaar. Take a look at the developers' pages on python.org, they mention that a BZR checkout is available. I know that it works (though the initial checkout is glacially slow) but I don't know what official support it has or what is planned with it. It's kept up to date, and will eventually move to a more complete DVCS experiment (there are also mercurial and git mirrors being maintained, but they haven't been linked from python.org yet - a trawl through the python-dev archives should turn up the links to the URLs). The PSF's infrastructure committee isn't that big though (and all volunteers), and switching version control systems isn't exactly easy (even the migration from Sourceforge CVS to python.org SVN took quite a bit of effort from key people). The migration of all our regular workflows from the familiar centralised VCS style to a DVCS style of development promises to be pretty disruptive in the short term, no matter how beneficial it will be in the long run. That said, with the tracker migration from Sourceforge to Roundup behind us, and a hopefully successful 3.0 release not too far away, it's probably time to start giving the idea more serious thought. Ultimately, any complete plan for migration from SVN to a DVCS will likely need to come in the form of a meta-PEP like the one MvL wrote to justify and document the migration from CVS to SVN: http://www.python.org/dev/peps/pep-0347/ Unlike PEP 347 (where SVN was purpose built as a better CVS, thus making the overall migration path and workflow updates reasonably straightforward), a PEP for migrating to a DVCS would need to provide justification not only for moving to a DVCS in general, but also for the choice of a particular DVCS. Similar to the exercise in selecting Roundup, part of that would not only be the features of the tool itself, but also the available volunteer expertise to maintain an instance of it on python.org. One thing that such a PEP could probably also use is additional feedback from folks outside the core dev team on how a DVCS would benefit them (since the core devs are the ones least affected by the limitations of a centralised VCS - although having something better than svnmerge to handle maintenance of multiple branches would be a very good thing for us too!). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
Barry Warsaw wrote: or even decided that we're moving to one. Brett as the head of the infrastructure committee will have more to say about that. While it is indeed the infrastructure committee's call (since they'll shoulder the bulk of the effort in organising further investigation into the idea), I personally believe that moving to some kind of DVCS makes too much sense for it not to happen eventually. Anything we can do to make it easier to maintain 4 active branches (2.x-1 and 3.y-1 maintenance, 2.x and 3.y development) over the next few years is going to be worth a fair amount of up front effort. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proper initialization of structs
I like to raise attention for a problem revealed by http://bugs.python.org/issue4237 --- The bug was caused by a design flaw -- which was partly my fault. Some elements of the PyFileIOObject struct were initialized in __new__ while other parts were initialized in __init__. I've moved the initialization to __new__. We should add a rule that all struct members must be properly initialized in __new__. In the past Victor's fuzzying tool has revealed several crashers related to similar design flaws. I'm raising the severity of the bug to release blocker because I can't predict if the problem can be abused to crash the interpreter. We should also review all __new__ and __init__ methods of objects and extension modules for similar issues. --- The same design flaw was responsible for bugs like the pickle crasher http://bugs.python.org/issue3664. I like to establish a rule that *all* struct members must be initialized properly in the type's tp_new function. Comments? Christian ___ 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] My patches
Ulrich Eckhardt wrote: On Thursday 30 October 2008, Victor Stinner wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial, GIT, anything else? Bazaar. Take a look at the developers' pages on python.org, they mention that a BZR checkout is available. I know that it works (though the initial checkout is glacially slow) but I don't know what official support it has or what is planned with it. I'd like to try it out, but the instructions on http://www.python.org/dev/bazaar/ say to get wget http://code.python.org/snapshots/python-bzr-snapshot.tar.bz2, which is a 404. Anyone know the actual URL? ___ 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] My patches
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. (What a DVCS might enable is making it easier to do larger experiments, like the recent Vmgen work, and publish them in a form that people can download. We could create SVN branches now, but that means people would then have commit access to all of the Python source.) --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] My patches
2008-10-30 16:04 A.M. Kuchling [EMAIL PROTECTED] napisał(a): On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. (What a DVCS might enable is making it easier to do larger experiments, like the recent Vmgen work, and publish them in a form that people can download. We could create SVN branches now, but that means people would then have commit access to all of the Python source.) SVN supports path-based authorization. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html ___ 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] My patches
On Oct 30, 2008, at 11:11 AM, Arfrever Frehtes Taifersar Arahesis wrote: SVN supports path-based authorization. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html This has worked well for us with contractors and partners, and isn't problematic or tedious to maintain. -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
Arfrever Frehtes Taifersar Arahesis wrote: 2008-10-30 16:04 A.M. Kuchling [EMAIL PROTECTED] napisał(a): On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. (What a DVCS might enable is making it easier to do larger experiments, like the recent Vmgen work, and publish them in a form that people can download. We could create SVN branches now, but that means people would then have commit access to all of the Python source.) SVN supports path-based authorization. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html good point, but then we'd have an authentication management task ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] My patches
On Thu, Oct 30, 2008 at 8:50 AM, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote: If Python would be more reactive, more developer will be attracted. The communication is very important in an open source project. I contributed to many many projects, and I can say that Python is already one of the most reactive project! But it can be better ;-) I agree! How can we improve our development process, given that we're an all volunteer organization? On that note, are more volunteers needed? Are there any capacities in which extra sets of hands could make help these improvements or would it just be more overhead and managing people and figuring out what to do? Moderately related note, I'm going to start the python-dev list summaries again (I have been the worst summary maintainer *ever*) and I'd like to set up the process as a community effort. That is, I've got some code I'm going to launch (probably at appengine) where edits can be made to the summaries by anyone, to be reviewed and taken in, before submitting the final summaries every two weeks. This should make keeping them going more likely, because no one person will need to find the time. It will also make the summaries more accurate if people actually involved in the discussions can fix any mistakes or repair omissions. I think the summaries are important, and one of many puzzle pieces to keeping people informed, which is all part of moving the development process along. Of course, this is all assuming no one objects to that plan. ___ 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] My patches
2008/10/30 A.M. Kuchling [EMAIL PROTECTED]: On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. Agreed. There are lots of patches around, but not enough core dev man-hours to review and apply them. As just adding extra people as core devs isn't going to work (I don't believe it's *hard* to become a core dev at the moment, it just needs a level of commitment that many people can't offer), and as adding hours to the day isn't possible (hmm, Guido - about that time machine?) I think the best way of helping is with patch triage. More people trawling the trackers and reviewing existing patches might free up core dev time for looking at the more subtle stuff, as long as (1) core devs could be happy to accept this is OK, commit it comments from non-core devs, and/or (2) it's easy to locate stuff to review, and just as importantly stuff which has been reviewed and is ready to go. Question - is there anything Roundup can do to help triage? Extra status or keyword values (has patch, ready to go, ...)? More canned searches (Show Open and Show Unassigned aren't a lot of help)? Custom reports (summaries by type)? Or are such things there and simply not publicised enough? I just did a quick experiment, checking for trivial documentation patches I could review, and some things became obvious: 1. There is no way of telling which issues have a patch. 2. Some patches marked as documentation are doc fixes, others seem to be issues where it has been decided that the behaviour is correct as is, but needs to be documented. Fair enough, but it's much harder to assess the latter, and there's no way of just grabbing the former (for example, to spend a spare 30 minutes reviewing simple stuff). 3. There's nothing obvious I can do to move an issue forward. Sure, I can make a comment, but that's about it. I'd like something that stood a bit more chance of getting noticed (like a status change, or maybe a list of people who think this is good to apply, which I can add myself to). All of which boil down to (1) quickly finding stuff I can deal with, and (2) feeling like what I do has an effect. Hmm, I've spent more time on this than I should have, and it's gone way off topic. Is there anywhere better to discuss it? Paul. ___ 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] My patches
On Thu, Oct 30, 2008 at 11:55 AM, Paul Moore [EMAIL PROTECTED] wrote: I just did a quick experiment, checking for trivial documentation patches I could review, and some things became obvious: 1. There is no way of telling which issues have a patch. There is a patch keyword that is usually set for issues with patches and search can be done for given keywords. Thanks, Raghu ___ 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] My patches
On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore [EMAIL PROTECTED] wrote: I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. Agreed. There are lots of patches around, but not enough core dev man-hours to review and apply them. As just adding extra people as core devs isn't going to work (I don't believe it's *hard* to become a core dev at the moment, it just needs a level of commitment that many people can't offer), and as adding hours to the day isn't possible (hmm, Guido - about that time machine?) I think the best way of helping is with patch triage. Since it is a hard and long process to know it all in Python, and to become a core developer What about having two level of devs ? + core developers + standard library developers I mean, the standard library could be open ihmo to a wider range of people, or maybe even having people specialized in some packages, modules, even if they don't know anything about the C apis of the core. Those standard library developers could be blessed to work on specific areas of the standard library and followed by a core developer that can just make sure everything goes in the right direction without having too much extra work for that. Regards, Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.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] My patches
On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore [EMAIL PROTECTED] wrote: I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. Agreed. There are lots of patches around, but not enough core dev man-hours to review and apply them. As just adding extra people as core devs isn't going to work (I don't believe it's *hard* to become a core dev at the moment, it just needs a level of commitment that many people can't offer), and as adding hours to the day isn't possible (hmm, Guido - about that time machine?) I think the best way of helping is with patch triage. Since it is a hard and long process to know it all in Python, and to become a core developer What about having two level of devs ? + core developers + standard library developers I mean, the standard library could be open ihmo to a wider range of people, or maybe even having people specialized in some packages, modules, even if they don't know anything about the C apis of the core. Those standard library developers could be blessed to work on specific areas of the standard library and followed by a core developer that can just make sure everything goes in the right direction without having too much extra work for that. Regards, Tarek Interestingly enough, I consider myself in the standard library developers RE: the multiprocessing package. I just thought that's how things broke down unofficially. I personally don't feel comfortable doing much of anything outside of my sandbox, but am more than willing to commit patches that have been reviewed by people my senior (in skill!). -jesse ___ 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] Fwd: Removal of GIL through refcounting removal.
Hi to all Python developers For a student project in a course on virtual machines, we are evaluating the possibility to experiment with removing the GIL from CPython We have read the arguments against doing this at http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock. But we think it might be possible to do this with a different approach than what has been tried till now. The main reason for the necessity of the GIL is reference counting. We believe that most of the slowdown in the free threading implementation of Greg Stein was due to the need of atomic refcounting, as this mail seems to confirm: http://mail.python.org/pipermail/python-ideas/2007-April/000414.html So we want to change CPython into having a real garbage collector - removing all reference counting, and then the need for locks (or atomic inc/dec ops) should be highly alleviated. Preferably the GC should be a high-performance one for instance a generational one. We believe that it can run quite a lot faster than ref-counting. Shared datastructures would get their lock obviously. Immutable objects (especially shared global objects, like True, False, Null) would not. Most of the interpreter structure would be per-thread, at that point. We do not know how Greg Stein did his locking in the free threads patch, but as a part of the course we learned there exists much faster ways of locking than using OS-locks (faster for the uncontented case) that are used in e.g. the HOT-SPOT java-compiler. This might make free threading in python more attractive than some pessimists think. (http://blogs.sun.com/dave/entry/biased_locking_in_hotspot) In particular, we are talking about making the uncontended case go fast, not about the independent part of stack-allocating the mutex structure, which can only be done and is only needed in Java. These ideas are similar to the ones used by Linux fast mutexes (futexes), the implementation of mutexes in NPTL. We have read this mail thread - so it seems that our idea surfaced, but Greg didn't completely love it (he wanted to optimize refcounting instead): http://mail.python.org/pipermail/python-ideas/2007-April/000436.html He was not totally negative however. His main objections are about: - cache locality (He is in our opinion partially right, as seen in some other paper time ago - any GC, copying GC in particular, doubles the amount of used memory, so it's less cache-friendly). But still GCs are overall competitive or faster than explicit management, and surely much faster of refcounting. We know it is the plan for PyPy to work in this way, and also that Jython and Ironpython works like that (using the host vm's GC), so it seems to be somehow agreeable with the python semantics (perhaps not really with __del__ but they are not really nice anyway). Was this ever tried for CPython? Any other comments, encouragements or warnings on the project-idea? Best regards: Paolo, Sigurd ___ 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] Proper initialization of structs
Yes, that's what __new__ / tp_new is for! Thanks for finding this. On Thu, Oct 30, 2008 at 7:20 AM, Christian Heimes [EMAIL PROTECTED] wrote: I like to raise attention for a problem revealed by http://bugs.python.org/issue4237 --- The bug was caused by a design flaw -- which was partly my fault. Some elements of the PyFileIOObject struct were initialized in __new__ while other parts were initialized in __init__. I've moved the initialization to __new__. We should add a rule that all struct members must be properly initialized in __new__. In the past Victor's fuzzying tool has revealed several crashers related to similar design flaws. I'm raising the severity of the bug to release blocker because I can't predict if the problem can be abused to crash the interpreter. We should also review all __new__ and __init__ methods of objects and extension modules for similar issues. --- The same design flaw was responsible for bugs like the pickle crasher http://bugs.python.org/issue3664. I like to establish a rule that *all* struct members must be initialized properly in the type's tp_new function. Comments? Christian ___ 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] Fwd: Removal of GIL through refcounting removal.
On Thu, Oct 30, 2008 at 12:13 PM, Sigurd Torkel Meldgaard [EMAIL PROTECTED] wrote: Hi to all Python developers For a student project in a course on virtual machines, we are evaluating the possibility to experiment with removing the GIL from CPython We have read the arguments against doing this at http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock. But we think it might be possible to do this with a different approach than what has been tried till now. The main reason for the necessity of the GIL is reference counting. We believe that most of the slowdown in the free threading implementation of Greg Stein was due to the need of atomic refcounting, as this mail seems to confirm: http://mail.python.org/pipermail/python-ideas/2007-April/000414.html So we want to change CPython into having a real garbage collector - removing all reference counting, and then the need for locks (or atomic inc/dec ops) should be highly alleviated. Preferably the GC should be a high-performance one for instance a generational one. We believe that it can run quite a lot faster than ref-counting. Shared datastructures would get their lock obviously. Immutable objects (especially shared global objects, like True, False, Null) would not. Most of the interpreter structure would be per-thread, at that point. We do not know how Greg Stein did his locking in the free threads patch, but as a part of the course we learned there exists much faster ways of locking than using OS-locks (faster for the uncontented case) that are used in e.g. the HOT-SPOT java-compiler. This might make free threading in python more attractive than some pessimists think. (http://blogs.sun.com/dave/entry/biased_locking_in_hotspot) In particular, we are talking about making the uncontended case go fast, not about the independent part of stack-allocating the mutex structure, which can only be done and is only needed in Java. These ideas are similar to the ones used by Linux fast mutexes (futexes), the implementation of mutexes in NPTL. We have read this mail thread - so it seems that our idea surfaced, but Greg didn't completely love it (he wanted to optimize refcounting instead): http://mail.python.org/pipermail/python-ideas/2007-April/000436.html He was not totally negative however. His main objections are about: - cache locality (He is in our opinion partially right, as seen in some other paper time ago - any GC, copying GC in particular, doubles the amount of used memory, so it's less cache-friendly). But still GCs are overall competitive or faster than explicit management, and surely much faster of refcounting. We know it is the plan for PyPy to work in this way, and also that Jython and Ironpython works like that (using the host vm's GC), so it seems to be somehow agreeable with the python semantics (perhaps not really with __del__ but they are not really nice anyway). Was this ever tried for CPython? Any other comments, encouragements or warnings on the project-idea? Best regards: Paolo, Sigurd See also: http://code.google.com/p/python-safethread/ https://launchpad.net/python-safethread ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
It's not that I have any love for the GIL, it just is the best compromise I could find. I expect that you won't be able to do better, but I wish you luck anyway. On Thu, Oct 30, 2008 at 9:13 AM, Sigurd Torkel Meldgaard [EMAIL PROTECTED] wrote: Hi to all Python developers For a student project in a course on virtual machines, we are evaluating the possibility to experiment with removing the GIL from CPython We have read the arguments against doing this at http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock. But we think it might be possible to do this with a different approach than what has been tried till now. The main reason for the necessity of the GIL is reference counting. We believe that most of the slowdown in the free threading implementation of Greg Stein was due to the need of atomic refcounting, as this mail seems to confirm: http://mail.python.org/pipermail/python-ideas/2007-April/000414.html So we want to change CPython into having a real garbage collector - removing all reference counting, and then the need for locks (or atomic inc/dec ops) should be highly alleviated. Preferably the GC should be a high-performance one for instance a generational one. We believe that it can run quite a lot faster than ref-counting. Shared datastructures would get their lock obviously. Immutable objects (especially shared global objects, like True, False, Null) would not. Most of the interpreter structure would be per-thread, at that point. We do not know how Greg Stein did his locking in the free threads patch, but as a part of the course we learned there exists much faster ways of locking than using OS-locks (faster for the uncontented case) that are used in e.g. the HOT-SPOT java-compiler. This might make free threading in python more attractive than some pessimists think. (http://blogs.sun.com/dave/entry/biased_locking_in_hotspot) In particular, we are talking about making the uncontended case go fast, not about the independent part of stack-allocating the mutex structure, which can only be done and is only needed in Java. These ideas are similar to the ones used by Linux fast mutexes (futexes), the implementation of mutexes in NPTL. We have read this mail thread - so it seems that our idea surfaced, but Greg didn't completely love it (he wanted to optimize refcounting instead): http://mail.python.org/pipermail/python-ideas/2007-April/000436.html He was not totally negative however. His main objections are about: - cache locality (He is in our opinion partially right, as seen in some other paper time ago - any GC, copying GC in particular, doubles the amount of used memory, so it's less cache-friendly). But still GCs are overall competitive or faster than explicit management, and surely much faster of refcounting. We know it is the plan for PyPy to work in this way, and also that Jython and Ironpython works like that (using the host vm's GC), so it seems to be somehow agreeable with the python semantics (perhaps not really with __del__ but they are not really nice anyway). Was this ever tried for CPython? Any other comments, encouragements or warnings on the project-idea? Best regards: Paolo, Sigurd ___ 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] Fwd: Removal of GIL through refcounting removal.
Sigurd Torkel Meldgaard wrote: Hi to all Python developers For a student project in a course on virtual machines, we are evaluating the possibility to experiment with removing the GIL from CPython... Just an FYI, these two particular students already introduced themselves on the PyPy list. Paolo is a masters student with experience in the Linux kernel; Sigurd is a PhD candidate. Their professor is Lars Bak, the lead architect of the Google V8 Javascript engine. They spent some time working on V8 in the last couple months. ___ 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] Proper initialization of structs
On Oct 30, 2008, at 10:20 AM, Christian Heimes wrote: I like to establish a rule that *all* struct members must be initialized properly in the type's tp_new function. I think this has always been a requirement. The result of the new operation must conform to all the requirements that the type's C code demands. It's good to move work into __init__ where reasonable, so that it can be avoided if a subclass wants it done in a completely different way, but new can't work that way. -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
VanL wrote: Just an FYI, ...and the FYI was to no one in particular, just interesting information from the PyPy list. It is just unfortunate timing that made it look like a cheeky reply to 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] Fwd: Removal of GIL through refcounting removal.
On Thu, Oct 30, 2008 at 1:07 PM, VanL [EMAIL PROTECTED] wrote: Just an FYI, these two particular students already introduced themselves on the PyPy list. Paolo is a masters student with experience in the Linux kernel; Sigurd is a PhD candidate. Their professor is Lars Bak, the lead architect of the Google V8 Javascript engine. They spent some time working on V8 in the last couple months. This just gives me really high expectations. Go get 'em! -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Thu, Oct 30, 2008 at 10:20 AM, VanL [EMAIL PROTECTED] wrote: VanL wrote: Just an FYI, ...and the FYI was to no one in particular, just interesting information from the PyPy list. It is just unfortunate timing that made it look like a cheeky reply to Guido. No offense taken. The V8 experience makes me feel much more optimistic that they might actually pull this off. (I'm still skeptical about support for extension modules, withougt which CPython is pretty lame.) -- --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] Fwd: Removal of GIL through refcounting removal.
Guido van Rossum wrote: No offense taken. The V8 experience makes me feel much more optimistic that they might actually pull this off. (I'm still skeptical about support for extension modules, withougt which CPython is pretty lame.) The need to modify all extension modules is the usual non-starter I see mentioned when this topic comes up. The OP really needs to think about that issue. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Thu, Oct 30, 2008 at 10:31 AM, Eric Smith [EMAIL PROTECTED] wrote: Guido van Rossum wrote: No offense taken. The V8 experience makes me feel much more optimistic that they might actually pull this off. (I'm still skeptical about support for extension modules, withougt which CPython is pretty lame.) The need to modify all extension modules is the usual non-starter I see mentioned when this topic comes up. The OP really needs to think about that issue. It's a non-starter for immediate world-domination. But if they get the core to be significantly faster I expect there will be motivation to port extensions. There's also the PyPy effort to replace extension modules with ctypes-based wrappers. I could also imagine that extensions could be run in a sandbox that *does* use the equivalent of the GIL. -- --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
[Python-Dev] Classifying language vs. impl-detail tests
Hi all, Here is a first step towards classifying the Python test suite into real language tests and implementation details: http://bugs.python.org/issue4242 If the general approach seems acceptable to people, I would be willing to port more of PyPy's test suite patches. The net result would be to move the test suite towards being more directly useful for alternate Python implementations. (Right now, all of them have some custom tests plus their own similarly patched copy of the stdlib test suite.) Note that the patch above is against 2.7 trunk; the 2.x line is what all non-CPython implementations currently target. The general idea (and to a large extend the patches) can easily be forward-ported to 3.x when it makes sense. Also, the actual decision of what is a real or a detail test is of course up to discussion. The patch above does the classification for test_descr. It was obtained by running it with PyPy, and for each failure either fixing PyPy, or argumenting (by adding a comment) the reason for which it is a detail -- usually referring to well-known agreement expressed on python-dev about the matter. (Of course, detail tests still run normally on top of CPython.) A bientot, Armin. ___ 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] My patches
On Thu, Oct 30, 2008 at 06:14, Nick Coghlan [EMAIL PROTECTED] wrote: Ulrich Eckhardt wrote: On Thursday 30 October 2008, Victor Stinner wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial, GIT, anything else? Bazaar. Take a look at the developers' pages on python.org, they mention that a BZR checkout is available. I know that it works (though the initial checkout is glacially slow) but I don't know what official support it has or what is planned with it. It's kept up to date, and will eventually move to a more complete DVCS experiment (there are also mercurial and git mirrors being maintained, but they haven't been linked from python.org yet - a trawl through the python-dev archives should turn up the links to the URLs). The PSF's infrastructure committee isn't that big though (and all volunteers), and switching version control systems isn't exactly easy (even the migration from Sourceforge CVS to python.org SVN took quite a bit of effort from key people). The migration of all our regular workflows from the familiar centralised VCS style to a DVCS style of development promises to be pretty disruptive in the short term, no matter how beneficial it will be in the long run. That said, with the tracker migration from Sourceforge to Roundup behind us, and a hopefully successful 3.0 release not too far away, it's probably time to start giving the idea more serious thought. Ultimately, any complete plan for migration from SVN to a DVCS will likely need to come in the form of a meta-PEP like the one MvL wrote to justify and document the migration from CVS to SVN: http://www.python.org/dev/peps/pep-0347/ I have actually started such a PEP, so this is being worked on. -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] Fwd: Removal of GIL through refcounting removal.
Guido van Rossum wrote: On Thu, Oct 30, 2008 at 10:31 AM, Eric Smith [EMAIL PROTECTED] wrote: Guido van Rossum wrote: No offense taken. The V8 experience makes me feel much more optimistic that they might actually pull this off. (I'm still skeptical about support for extension modules, withougt which CPython is pretty lame.) The need to modify all extension modules is the usual non-starter I see mentioned when this topic comes up. The OP really needs to think about that issue. It's a non-starter for immediate world-domination. But if they get the core to be significantly faster I expect there will be motivation to port extensions. There's also the PyPy effort to replace extension modules with ctypes-based wrappers. I could also imagine that extensions could be run in a sandbox that *does* use the equivalent of the GIL. For IronClad [1], an implementation of the Python C API in C# to allow you to use Python C extensions from IronPython, we take a hybrid approach to garbage collection. We hold a strong reference to objects created by extensions (preventing .NET from garbage collecting them) and allow the extension to manipulate the reference count in the usual way. Periodically we scan our managed objects [2] to see if there are objects whose reference count has dropped to zero and we then delete our strong reference - allowing garbage collection to happen normally. We have also implemented a GIL for the C extensions even though IronPython has no GIL. Simple extension modules can already be used with IronPython through Ironclad, and for Numpy (our goal) arrays can be created and used and we are working on 'everything else'. Moving more C extensions to an implementation based on ctypes would be enormously useful for PyPy, IronPython and Jython, but ctypes is not yet as portable as Python itself which could be an issue (although one worth resolving). Michael Foord [1] http://code.google.com/p/ironclad [2] Strictly speaking they are managed objects of unmanaged types, but we really need a better way of talking about them. -- http://www.ironpythoninaction.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] My patches
On Thu, Oct 30, 2008 at 05:50, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote: [SNIP] If Python would be more reactive, more developer will be attracted. The communication is very important in an open source project. I contributed to many many projects, and I can say that Python is already one of the most reactive project! But it can be better ;-) I agree! How can we improve our development process, given that we're an all volunteer organization? And this is a key point that people seem to forget. Guido is the ONLY developer who gets paid to work on Python, and that is only 50% of his time (when he doesn't have a Google-related workload), and honestly I would rather he not deal with patches that do not affect what he is working on. The rest of us spend our evenings and weekends on this on top of trying to balance a normal life. In my case I had to stop my Python work recently because I have been working on my Ph.D. thesis proposal. Everyone has their lives that take priority. And no, I do not think that giving out more commit privileges will necessarily solve everything. Python is known for its quality and part of that reason is we are careful about handing out privileges. This is not to say we can't try to help move people along towards getting privileges faster, but I am not interested in doing what Pugs does and give everyone who has submitted a patch commit privs. -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] My patches
Question - is there anything Roundup can do to help triage? Extra status or keyword values (has patch, There is patch keyword already, and a public query Patches (as well as My Patches) ready to go, ...)? We could give more people the right to set the resolution to Accepted. This is a matter of trust, though - if the committer then still needs to review it, anyway, nothing is gained. More canned searches (Show Open and Show Unassigned aren't a lot of help)? Please go to the edit label next to Search. You can store your own searches, but you can also share searches with others. Custom reports (summaries by type)? This I don't understand - how is it different from a search? Or are such things there and simply not publicised enough? Perhaps. I really don't know what percentage of interested users is aware of roundup capabilities. I just did a quick experiment, checking for trivial documentation patches I could review, and some things became obvious: 1. There is no way of telling which issues have a patch. There is the patch keyword, and you can query for it. There is a canned query published already. 2. Some patches marked as documentation are doc fixes, others seem to be issues where it has been decided that the behaviour is correct as is, but needs to be documented. Fair enough, but it's much harder to assess the latter, and there's no way of just grabbing the former (for example, to spend a spare 30 minutes reviewing simple stuff). There is the easy keyword. Of course, it might also be useful to triage more issues as easy. 3. There's nothing obvious I can do to move an issue forward. Sure, I can make a comment, but that's about it. I'd like something that stood a bit more chance of getting noticed (like a status change, or maybe a list of people who think this is good to apply, which I can add myself to). The developer role has more user interface. I've just given it to you. Hmm, I've spent more time on this than I should have, and it's gone way off topic. Is there anywhere better to discuss it? There is the tracker-discuss list for discussion, and the meta tracker for actual problems/wishes for the tracker. 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] My patches
What about having two level of devs ? + core developers + standard library developers We effectively have that already. Many of the committers will only ever commit to a single module (+docs and tests), as they volunteered to maintain that very module (e.g. Lars Gustäbel for the tarfile module). If a committer agrees to restrict himself to a certain area, he will usually keep that promise, so there isn't really any need for a finer-grained access control, IMO. 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] My patches
Interestingly enough, I consider myself in the standard library developers RE: the multiprocessing package. I just thought that's how things broke down unofficially. It's actually fairly official (see my other message) - you know who you are. It has been working that way fine for the last few years. The public record if it is in Misc/developers.txt (although that file might be slightly incomplete/incorrect). 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
[Python-Dev] svnmerge init in the release26-maint branch?
I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. I assume that we will use svnmerge to merge from trunk to release26-maint? So, is it ok to do 'svnmerge init' in it? -- Thanks, Thomas ___ 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] svnmerge init in the release26-maint branch?
Thomas Heller wrote: I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. Are you sure? I did a svnmerge init a couple of days after the release26-maint branch was created. I can see the properties on the branch, too. .../python/release26-maint$ svn proplist -v . | grep svnmerge svnmerge-blocked : /python/trunk:66721-66722,66744-66745,66752,66756,66763-66765,66768,66791-66792,66857 svnmerge-integrated : /python/trunk:1-66720,66723-66743,66746-66751,66753-66755,66757-66762,66766-66767,66769-66790,66793-66800,66802,66805-66812,66814-66821,66824-66831,66833-66835,66837-66851,66853,66858-66860,66862-66863,66881,66891,66906,66922,66928-66931,66933-66937,66939-66940,66958,66984,66995-66996,67000,67030-67031 Christian ___ 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] svnmerge init in the release26-maint branch?
Christian Heimes schrieb: Thomas Heller wrote: I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. Are you sure? I did a svnmerge init a couple of days after the release26-maint branch was created. I can see the properties on the branch, too. .../python/release26-maint$ svn proplist -v . | grep svnmerge svnmerge-blocked : /python/trunk:66721-66722,66744-66745,66752,66756,66763-66765,66768,66791-66792,66857 svnmerge-integrated : /python/trunk:1-66720,66723-66743,66746-66751,66753-66755,66757-66762,66766-66767,66769-66790,66793-66800,66802,66805-66812,66814-66821,66824-66831,66833-66835,66837-66851,66853,66858-66860,66862-66863,66881,66891,66906,66922,66928-66931,66933-66937,66939-66940,66958,66984,66995-66996,67000,67030-67031 Oh, sorry - I forgot to 'svn up' first. -- Thanks, Thomas ___ 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] buildbots
AFAICS there are no buildbots for the release26-maint branch. Thomas ___ 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] buildbots
AFAICS there are no buildbots for the release26-maint branch. That's correct. I'm waiting to create them until after we retire the 2.5 ones. 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] Classifying language vs. impl-detail tests
On Thu, Oct 30, 2008 at 12:16 PM, Armin Rigo [EMAIL PROTECTED] wrote: Hi all, Here is a first step towards classifying the Python test suite into real language tests and implementation details: http://bugs.python.org/issue4242 I've actually implemented something like this along with more general test skipping capabilities in my Bazaar testing branch. [1] It adds a decorator @cpython_only that can be applied to tests. If the general approach seems acceptable to people, I would be willing to port more of PyPy's test suite patches. The net result would be to move the test suite towards being more directly useful for alternate Python implementations. (Right now, all of them have some custom tests plus their own similarly patched copy of the stdlib test suite.) That would be great to see! Note that the patch above is against 2.7 trunk; the 2.x line is what all non-CPython implementations currently target. The general idea (and to a large extend the patches) can easily be forward-ported to 3.x when it makes sense. Also, the actual decision of what is a real or a detail test is of course up to discussion. The patch above does the classification for test_descr. It was obtained by running it with PyPy, and for each failure either fixing PyPy, or argumenting (by adding a comment) the reason for which it is a detail -- usually referring to well-known agreement expressed on python-dev about the matter. (Of course, detail tests still run normally on top of CPython.) [1] http://code.python.org/python/users/benjamin.peterson/new_testing/main -- Cheers, Benjamin Peterson There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner. ___ 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] buildbots
On Thu, Oct 30, 2008 at 3:38 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: AFAICS there are no buildbots for the release26-maint branch. That's correct. I'm waiting to create them until after we retire the 2.5 ones. That reminds me: Do we have a final release date for 2.5.3 set? -- Cheers, Benjamin Peterson There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner. ___ 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] buildbots
Benjamin Peterson wrote: On Thu, Oct 30, 2008 at 3:38 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: AFAICS there are no buildbots for the release26-maint branch. That's correct. I'm waiting to create them until after we retire the 2.5 ones. That reminds me: Do we have a final release date for 2.5.3 set? Not precisely. However, I want to make the release candidate for 2.5.3 a week after the 3.0 release, and the final release one week afterwards. If the 3.0 release plan stands, that would give December 10 for the release candidate, and December 17 for the final 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] My patches
On Thu, Oct 30, 2008 at 03:55:38PM +, Paul Moore wrote: 2. Some patches marked as documentation are doc fixes, others seem to be issues where it has been decided that the behaviour is correct as is, but needs to be documented. Fair enough, but it's much harder to assess the latter, and there's no way of just grabbing the former (for example, to spend a spare 30 minutes reviewing simple stuff). Perhaps the documentation category could be split into 'Documentation' and 'Documentation Needed'; the latter means the issue entails writing new text as opposed to rewriting. But I think on average documentation issues get processed pretty quickly: Georg is responsive to them, and patches are easy to apply because you don't need to worry about breaking anything. In general Python development is much less freewheeling and fun than it used to be. You could come up with new features and modules, add lots of new capabilities to a module. Today we're making much smaller changes, discuss them at far great length, and have to worry about breaking all the existing Python code out there, It's a sign of Python's maturity, of course, and I'm not saying that the design effort and the compatibility requirements should be dropped, but they certainly act as a damper. On some of my issues (esp. ones relating to curses and mailbox.py), I feel paralyzed because problems are occurring on platforms I don't have access to (e.g. FreeBSD). The buildbots will report problems, but then you have to debug them by committing changes, triggering a build, and observing the results. And all of these actions will send e-mail to python-checkins. (Imagine if every 'print reached here!' you added while debugging was e-mailed to everyone...) --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] My patches
Arfrever Frehtes Taifersar Arahesis schrieb: 2008-10-30 16:04 A.M. Kuchling [EMAIL PROTECTED] napisał(a): On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. (What a DVCS might enable is making it easier to do larger experiments, like the recent Vmgen work, and publish them in a form that people can download. We could create SVN branches now, but that means people would then have commit access to all of the Python source.) SVN supports path-based authorization. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html I don't see a problem with giving access to people wanting to work on a branch, and telling them not to commit on the trunk. We had and still have some such branches going on, e.g. for SoC students. I also gave out access to several developers to work on the docs only, or Sphinx which still is in Python's SVN repo. After all, it's a VCS, and if someone plays against the rules, the commit is reverted and the privs dropped in perhaps a minute. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
On Thu, 30 Oct 2008 17:17:02 -0400, A.M. Kuchling [EMAIL PROTECTED] wrote: [snip] On some of my issues (esp. ones relating to curses and mailbox.py), I feel paralyzed because problems are occurring on platforms I don't have access to (e.g. FreeBSD). The buildbots will report problems, but then you have to debug them by committing changes, triggering a build, and observing the results. And all of these actions will send e-mail to python-checkins. (Imagine if every 'print reached here!' you added while debugging was e-mailed to everyone...) I do that when I need to. People whose lives would be ruined by the receipt of such an email always have the option of leaving the checkin list. However, there is a buildbot feature named try which lets you submit a patch (subject to authentication) and performs a build with the patch applied. This lets you try lots of little changes without getting your VCS involved. It needs to be enabled in the buildmaster configuration and credentials created for any user who will be given access. Jean-Paul ___ 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] My patches
On Thu, Oct 30, 2008 at 22:17, A.M. Kuchling [EMAIL PROTECTED] wrote: On some of my issues (esp. ones relating to curses and mailbox.py), I feel paralyzed because problems are occurring on platforms I don't have access to (e.g. FreeBSD). The buildbots will report problems, but then you have to debug them by committing changes, triggering a build, and observing the results. And all of these actions will send e-mail to python-checkins. (Imagine if every 'print reached here!' you added while debugging was e-mailed to everyone...) By the way, it seems that this python-checkins mailing list did not archive the recent commits: http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end I miss them... Can someone fix it? -- Amaury Forgeot d'Arc ___ 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] Proper initialization of structs
On Thu, Oct 30, 2008 at 1:00 PM, Fred Drake [EMAIL PROTECTED] wrote: It's good to move work into __init__ where reasonable, so that it can be avoided if a subclass wants it done in a completely different way, but new can't work that way. And that is exactly the reason why, the _pickle module doesn't use __new__ for initialization. Doing any kind of argument parsing in __new__ prevents subclasses from customizing the arguments for their __init__. Although, I agree that __new__ should be used, whenever it is possible, to initialize struct members. -- Alexandre ___ 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] Proper initialization of structs
Alexandre Vassalotti wrote: On Thu, Oct 30, 2008 at 1:00 PM, Fred Drake [EMAIL PROTECTED] wrote: It's good to move work into __init__ where reasonable, so that it can be avoided if a subclass wants it done in a completely different way, but new can't work that way. And that is exactly the reason why, the _pickle module doesn't use __new__ for initialization. Doing any kind of argument parsing in __new__ prevents subclasses from customizing the arguments for their __init__. No it doesn't - it just means the subclasses have to override __new__ as well and then give the parent class the arguments it needs. I've used this convention (*must* call parent class __new__ or the instance will be broken, may call parent class __init__ if it is helpful) many times, and it is far more robust than relying on subclasses to remember to call the parent class __init__ when setting up the class. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Oct 30, 2008, at 1:31 PM, Eric Smith wrote: Guido van Rossum wrote: No offense taken. The V8 experience makes me feel much more optimistic that they might actually pull this off. (I'm still skeptical about support for extension modules, withougt which CPython is pretty lame.) The need to modify all extension modules is the usual non-starter I see mentioned when this topic comes up. The OP really needs to think about that issue. It's not a non-starter, it's just a non-finisher. :) One could take an approach like Apple did for ObjC 2.0: libraries should be ported over time to be able to work with both refcounting and automatic-GC runtimes. When you link a program, you can choose to link it with the automatic GC objc runtime, as long as all the other frameworks you want to use are compatible with that. What this would mean in python terms: - Python would be able to be compiled in either refcounting or auto-gc mode. - Extensions can be modified to be compatible with the auto-gc mode over the timespan of a few years. - Then when most extensions have been adjusted, auto-gc would become the default mode for python to be compiled in. It's seems theoretically entirely doable, but will surely be a lot of work...someone'd have to be ready to really do the hard work to push it through to completion. James ___ 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] My patches
On some of my issues (esp. ones relating to curses and mailbox.py), I feel paralyzed because problems are occurring on platforms I don't have access to (e.g. FreeBSD). The buildbots will report problems, but then you have to debug them by committing changes, triggering a build, and observing the results. And all of these actions will send e-mail to python-checkins. I wouldn't worry about that. If the checkin message indicates that this is testing out a certain buildbot issue, most python-checkin readers probably will skip over it quickly. If you are still worried: buildbot has a try feature, where developers can try out changes on the slaves before committing them. This isn't currently activated in the Python buildbot - but if you need it, we could look into it (if you are curious, just experiment with it yourself). 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] My patches
By the way, it seems that this python-checkins mailing list did not archive the recent commits: http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end I miss them... Can someone fix it? Which ones are you missing specifically? 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] My patches
On Thu, Oct 30, 2008 at 6:25 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: By the way, it seems that this python-checkins mailing list did not archive the recent commits: http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end I miss them... Can someone fix it? Which ones are you missing specifically? I haven't seen any of the ones today. -- Cheers, Benjamin Peterson There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner. ___ 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] My patches
2008/10/30 Martin v. Löwis [EMAIL PROTECTED]: Question - is there anything Roundup can do to help triage? Extra status or keyword values (has patch, There is patch keyword already, and a public query Patches (as well as My Patches) Sorry, I checked the keywords but missed it. ready to go, ...)? We could give more people the right to set the resolution to Accepted. This is a matter of trust, though - if the committer then still needs to review it, anyway, nothing is gained. Agreed. I was thinking vaguely in terms of a type of voting - rather than a status or resolution, it might be more like the nosy list - a list of people who have said they think the patch is OK. The more people on the list, the stronger the assurance that it's acceptable. It is still a matter of trust, of course - nothing can avoid that. More canned searches (Show Open and Show Unassigned aren't a lot of help)? Please go to the edit label next to Search. You can store your own searches, but you can also share searches with others. I see it now. Thanks. It's not very obvious, but once you know it's there, it looks fine. Custom reports (summaries by type)? This I don't understand - how is it different from a search? I was thinking in terms of summary reports - counts of numbers of issues in various groups. The output layout is different from a search. My idea was to make it easier to find areas which are worth tackling (for example, if there are lots of documentation patches, it might be worth a look through to see if any are trivial). It's graphs and counts to help people to find areas they can help with that I was thinking of. It's not a very clear concept, even in my own mind though. Or are such things there and simply not publicised enough? Perhaps. I really don't know what percentage of interested users is aware of roundup capabilities. Fair point. My gut feeling is that more people would be interested if we had ways of presenting the list of issues in better ways than the current monolithic list. If people could see hey, there's a lot of documentation (or library, or C code, or whatever) patches which haven't been looked at yet, they might be inclined to take a look. Maybe even a simple graph of current issues on the python.org front page, with a Lend a hand! type of heading, to suggest that people could help. There's still the trust issue you mentioned above, but my instinct is that the average Python coder simply doesn't realise that they could help - or they believe that taking a spare 15 minutes wouldn't be worth it. 2. Some patches marked as documentation are doc fixes, others seem to be issues where it has been decided that the behaviour is correct as is, but needs to be documented. Fair enough, but it's much harder to assess the latter, and there's no way of just grabbing the former (for example, to spend a spare 30 minutes reviewing simple stuff). There is the easy keyword. Of course, it might also be useful to triage more issues as easy. That might help. But you can't search on combinations of keyword (e.g. easy, with a patch). Maybe an extra property Difficulty, with values Easy, Moderate, Complex (and blank, for not checked yet) would be good. Interested parties could check for issues with blank difficulty, and assign a difficulty level. That's useful triage, and not that hard for anyone to do. 3. There's nothing obvious I can do to move an issue forward. Sure, I can make a comment, but that's about it. I'd like something that stood a bit more chance of getting noticed (like a status change, or maybe a list of people who think this is good to apply, which I can add myself to). The developer role has more user interface. I've just given it to you. Thanks. I'll try to justify it by doing a bit more on the tracker :-) Hmm, I've spent more time on this than I should have, and it's gone way off topic. Is there anywhere better to discuss it? There is the tracker-discuss list for discussion, and the meta tracker for actual problems/wishes for the tracker. Thanks. Paul. ___ 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] Proper initialization of structs
Alexandre Vassalotti wrote: And that is exactly the reason why, the _pickle module doesn't use __new__ for initialization. Doing any kind of argument parsing in __new__ prevents subclasses from customizing the arguments for their __init__. Although, I agree that __new__ should be used, whenever it is possible, to initialize struct members. You are missunderstanding me. I want everybody to set the struct members to *A* sensible default value, not *THE* value. Argument parsing can still happen in tp_init. tp_new should (or must?) set all struct members to sensible defaults like NULL for pointers, -1 or 0 for numbers etc. Python uses malloc to allocate memory. Unless you are using debug builds the memory block is not initialized. In both cases the block of memory isn't zeroed. You all know the problems caused by uninitialized memory. Christian ___ 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] My patches
I haven't seen any of the ones today. OK, I've respooled them. 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] Proper initialization of structs
[oops, I forgot to cc the list] On Thu, Oct 30, 2008 at 7:43 PM, Christian Heimes [EMAIL PROTECTED] wrote: Alexandre Vassalotti wrote: And that is exactly the reason why, the _pickle module doesn't use __new__ for initialization. Doing any kind of argument parsing in __new__ prevents subclasses from customizing the arguments for their __init__. Although, I agree that __new__ should be used, whenever it is possible, to initialize struct members. You are missunderstanding me. I want everybody to set the struct members to *A* sensible default value, not *THE* value. Argument parsing can still happen in tp_init. tp_new should (or must?) set all struct members to sensible defaults like NULL for pointers, -1 or 0 for numbers etc. Python uses malloc to allocate memory. Unless you are using debug builds the memory block is not initialized. In both cases the block of memory isn't zeroed. You all know the problems caused by uninitialized memory. But what if PyType_GenericAlloc is used for tp_alloc? As far as I know, the memory block allocated with PyType_GenericAlloc is zeroed. -- Alexandre ___ 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] My patches
On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé [EMAIL PROTECTED] wrote: What about having two level of devs ? + core developers + standard library developers I was also thinking about two levels of developers, but structured a little differently. We have the same core developers with permission to commit anywhere in the repo. Then we have a set of sub-core (or whatever) that only have permission to commit to experimental branches. These experimental branches would be the testing place for some patches. Once a patch has had enough exposure in the experimental branch and has been verified by several people the core team could merge it into the main development branch. A set of buildbot slaves can also check that branch on a variety of systems and architectures. The structure could then look like: * trunk - the mainline of development * branches/release##maint - for each version * branches/experimental## - for the sub-core devs This may start to be a bit messy if the experimental branch diverges too much from trunk. trunk would also have to be periodically merged into the experimental branches. Even so I think it could still be manageable. And if not the no harm/no foul the experimental branches could be abandoned and little core developer time would be wasted. -- David http://www.traceback.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit : Agreed. I was thinking vaguely in terms of a type of voting - rather than a status or resolution, it might be more like the nosy list - a list of people who have said they think the patch is OK. The more people on the list, the stronger the assurance that it's acceptable. It is still a matter of trust, of course - nothing can avoid that. I like this idea. But there are different things to review. Examples: - the bug report: is the bug reproductible? is the bug isolated? - a patch: the patch works? the patch looks correct? or invalid coding style, introduce a regression, or anything else I was thinking in terms of summary reports (...) I think that you need an new information: the issue progress, eg. - initial state: 0% = need more information - bug isolated: 25% = need a patch - patch present: 50% = patch needs reviewers - patch reviewed: 75% = patch just have to be applied - issue closed: 100% (done) Beginners can search for progress 25%. They can try to reproduce a problem to check the Python version, the OS, etc. Or just help to give more informations about the issue. Core developers just have to check for progress = 75%. Fair point. My gut feeling is that more people would be interested if we had ways of presenting the list of issues in better ways than the current monolithic list. (...) Why not using icons (at least on the HTML view)? It helps to see quickly many informations and generates smaller reports. We can have an icon for each keyword. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
Sigurd Torkel Meldgaard [EMAIL PROTECTED] wrote: For a student project in a course on virtual machines, we are evaluating the possibility to experiment with removing the GIL from CPython Hi, It's great to hear of this kind of project. I think what you want to do is difficult but possible. The major compilcation would be that extension modules would have to re-written since they all assume a reference counting GC. A foreign function interface like CMU Lisp's alien or GHC's FFI is not necessarily any worse but it does place different demands on extension module authors. As a student project, I think it would make sense to forget about extensions and try to create a barebones interpreter based on CPython's runtime, compiler, etc with the reference counting ripped out and some other GC installed. I once had the Boehm GC working with Python. That's not too interesting. I'm not really up-to-date on current GC research but I think your GC has to do some copying in order to get really good performance. Producing a barebones version of the Python interpreter that utilizes a modern, copying GC would be a nice achievement and could be a platform for future work. Regards, 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] My patches
On Thu, Oct 30, 2008 at 17:27, Victor Stinner [EMAIL PROTECTED] wrote: Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit : Agreed. I was thinking vaguely in terms of a type of voting - rather than a status or resolution, it might be more like the nosy list - a list of people who have said they think the patch is OK. The more people on the list, the stronger the assurance that it's acceptable. It is still a matter of trust, of course - nothing can avoid that. I like this idea. But there are different things to review. Examples: - the bug report: is the bug reproductible? is the bug isolated? - a patch: the patch works? the patch looks correct? or invalid coding style, introduce a regression, or anything else I was thinking in terms of summary reports (...) I think that you need an new information: the issue progress, eg. - initial state: 0% = need more information - bug isolated: 25% = need a patch - patch present: 50% = patch needs reviewers - patch reviewed: 75% = patch just have to be applied - issue closed: 100% (done) Beginners can search for progress 25%. They can try to reproduce a problem to check the Python version, the OS, etc. Or just help to give more informations about the issue. Core developers just have to check for progress = 75%. I have a similar list that I have been thinking about proposing. I did a blog post about it at http://sayspy.blogspot.com/2008/08/what-are-typical-steps-issue-goes.html and received positive feedback: * triage * verify bug * test needed * needs patch * patch review * commit review * committed/rejected That way all the steps needed are obvious. I was going to start working on proposing this after doing the first draft of the DVCS PEP. -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
[Python-Dev] hg branch gone?
I just tried to update my 3.0 branch in hg from http://code.python.org/hg/branches/py3k/ and hg is telling me it's a 404. Anyone else having trouble? -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
