Re: [Python-Dev] Tracker BD Was:Goodbye
Am 23.09.2010 07:32, schrieb Jack Diederich: On Wed, Sep 22, 2010 at 11:46 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Sep 22, 2010, at 6:24 PM, R. David Murray wrote: On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy tjre...@udel.edu wrote: deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. IMO, Benjamin and Antoine are the closest. They devote a substantial portion of their lives to Python and have been our most active contributors in the last year. They read almost every tracker post, read every check-in, and continuously monitor the IRC channel. Off topic-er. Does anyone have scripts that pull data on how many committers commit or how many trac admins admin? I'm not asking for punitive reasons - I'd be the first against the wall - but I wouldn't mind graphing it. Power law, methinks. With big, confounding, and jumbley spikes in the Spring for PyCon. This should be easy to do with a hg repo such as the test conversion one on hg.python.org -- the activity extension already does the graphing, and I'm sure it can easily be tweaked to your liking. http://www.freehackers.org/thomas/2008/10/31/activity-extension-for-mercurial/ cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the developer docs?
That's right. It is true that it isn't branch-specific information, and that does cause a little bit of irritation for me too, but neither is Misc/developers.txt or Misc/maintainers.rst. Of course, we might consider a separate HG repository (I'm all in favor of many small repos, instead of a gigantic sandbox one). The downside is that I really like the developer docs at docs.python.org, and it would complicate the build process a bit. Georg Am 23.09.2010 06:45, schrieb Brett Cannon: A discussion occurred (w/o me) on #python-dev where moving it to Doc/ would allow it to show up at docs.python.org to perhaps get more people involved. It also allows developers to contribute to the docs w/o having to get pydotorg commit rights. On Wed, Sep 22, 2010 at 21:29, Fred Drake fdr...@acm.org wrote: On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannon br...@python.org wrote: the first thing on the agenda is a complete rewrite of the developer docs and moving them into the Doc/ directory I'd like to know why you think moving the developer docs into the CPython tree makes sense. My own thought here is that they're not specific to the version of Python, though some of the documentation deals with the group of specific branches being maintained. For me, keeping them in a separate space (like www.python.org/dev/) makes sense. -Fred -- Fred L. Drake, Jr.fdrake at acm.org A storm broke loose in my mind. --Albert Einstein ___ 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/python-python-dev%40m.gmane.org -- 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] Goodbye
Am 23.09.2010 04:35, schrieb Steven D'Aprano: On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote: Yikes - Mark has done terrific work in some very demanding areas, I'd hate to see him feel unwelcome. So that's my advice: find a way to smooth this over. You're welcome ;-) I'd like to second that. Mark has been pushy, annoying and demanding, although he has his bad points too *grins*. Seriously, Mark has brought a remarkable amount of energy to the tracker, for good and bad. The good shouldn't give him a Get Out Of Jail Free card forever, but in the absence of any knowledge of what lead to Mark's tracker privileges being revoked, I have no objections in principle to giving him a second chance if the devs decide that is acceptable and Mark is willing. (Not that my objections carry much weight.) I'd like to point out that only the Developer tracker privileges had been revoked at first, which meant that Mark could continue commenting and stirring up old issues, which is what made his work so valuable. He could not continue prematurely closing issues, which is what many devs objected to, and Raymond explained that to him in a private email (which I can only believe was polite and not at all offending). However, as a response to that, messages like this one started to be posted to several issues: http://bugs.python.org/msg117108 and since they were reposted even after being removed (unlinked) from the tracker item, the devs active on IRC at that moment could only suspect that this would continue for every issue that had Mark in its nosy list. That is a disruption that is not acceptable, and led to the removal of his User privilege as well, which I would say is wholly justified. Of course, this is *not* a ban! The privileges can be restored any time that Mark asks for it, but I would at least like to see an apology. Either way, I would like to publicly thank Mark for his efforts and wish him the best for the future. Same here. 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] Tracker BD Was:Goodbye
In article aanlkti=blcbdze7or7ynpnqcbmlxaeidhejerkxso...@mail.gmail.com, Jack Diederich jackd...@gmail.com wrote: Likewise for mailing list subscriptions. Personally I've gone back and forth between subscribing to everything (-list -dev -commits -bugs -ideas, et al) and subscribing to almost nothing. Mailing list subscription data could be very misleading as people follow this list (and other Python-related lists) through other interfaces, such as those provided by gmane.org (NNTP, RSS, web). Helps to keep the mailbox clutter down. -- Ned Deily, n...@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] Moving the developer docs?
On Thu, Sep 23, 2010 at 08:40, Georg Brandl g.bra...@gmx.net wrote: Of course, we might consider a separate HG repository (I'm all in favor of many small repos, instead of a gigantic sandbox one). +1. Cheers, Dirkjan ___ 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] Goodbye
deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer. I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. 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] Goodbye
Am 23.09.2010 09:18, schrieb Martin v. Löwis: deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer. I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. It does however attract attention from developers who either weren't around when the original issue was submitted, or didn't feel competent enough to fix it then. It is also helpful to try reproducing the bug with a current version, in case the issue has been fixed already -- whether because of a duplicate bug report or by chance. 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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)
Stephen J. Turnbull a écrit : What really saves the day here is not that common encodings just don't do that. It's that even in the case where only syntactically significant bytes in the representation are URL-encoded, they *are* URL-encoded. As long as the parsing library restricts itself to treating only wire-format input, you're OK.[1] But once you start doing things that involve decoding URL-encoding, you can run into trouble. If I understand you well, any processing of unquoted bytes is dangerous per se. If this is true, then perhaps 'unquote' doesn't disserve the criticism it received in this thread for always returning str. This would be in fact quite fortunate, as it forces url processing to either happen on quoted bytes (before calling 'unqote'), or on unquoted str (on the result of 'unquote'), both of which are safe. ___ 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] Goodbye
On 23/09/2010 09:46, Georg Brandl wrote: Am 23.09.2010 09:18, schrieb Martin v. Löwis: I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. It does however attract attention from developers who either weren't around when the original issue was submitted, or didn't feel competent enough to fix it then. It is also helpful to try reproducing the bug with a current version, in case the issue has been fixed already -- whether because of a duplicate bug report or by chance. I think my experience is that of several others. The work done by Mark and other tracker-trawlers has been useful: to dust off issues, attempt to assess their current validity, add suitable people to nosy lists, and where possible to try to reproduce or to encourage an OP to provide patches or other useful input. I've addressed, closed, or at least taken note of several issues in this way which I might not otherwise have done. The two less useful overspills of this generally useful activity have been: simple noise of the Is anyone interested in this? variety -- although even that might be useful, as Georg says, in highlighting older issues to newer developers; and the over-eager closure of calls on the basis of lack of response, and it seems to be an excess of this last which has brought the matter to a head. Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) TJG ___ 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] Problems with hex-conversion functions
Sorry for the late reply. I would really like to see this fixed. Or we [...] deprecate binascii.(un)hexlify(). ... binascii is the legacy approach here, so if anything was to go, those functions would be it ... I'm not entirely convinced binascii is the legacy approach. What makes this module legacy? On the contrary, I'm pretty sure modularity is better than sticking all the functionality in the core. As was written in this issue: http://psf.upfronthosting.co.za/roundup/tracker/issue3532 If you wanted to produce base-85 (say), then you can extend the functionality of bytes by providing a function that does that, whereas you can't extend the existing bytes type. This example shows that hex is actually getting a special treatment by having builtin methods associated with the bytes type. Why don't we add .base64 methods? Or even .zlib? After all, these options were present in Python 2.x using the encode method of string. In my opinion, having modules to deal with these types of conversions is better, and this is why I suggested sticking to binascii. In any case, seeing as both this discussion and the one linked above were abandoned, I would like to hear about what needs to be done to actually fix these issues. If no one else is willing to do it (that would be a little disappoiting), I think I have the skills to learn and fix the code itself, but I don't have the time and I am unfamiliar with the process of submitting patches and getting them approved. For example, who gets to decide about the correct approach? Is there a better place to discuss this? Thanks for the responses. -- Arnon On Sun, Sep 6, 2009 at 5:51 AM, Nick Coghlan ncogh...@gmail.com wrote: Brett Cannon wrote: To fix these issues, three changes should be applied: 1. Deprecate bytes.fromhex. This fixes the following problems: #4 (go with option B and remove the function that does not allow bytes input) #2 (the binascii functions will be the only way to do it) #1 (bytes.hex should not be implemented) 2. In order to keep the functionality that bytes.fromhex has over unhexlify, the latter function should be able to handle spaces in its input (fix #3) 3. binascii.hexlify should return string as its return type (fix #5) Or we fix bytes.fromhex(), add bytes.hex() and deprecate binascii.(un)hexlify(). binascii is the legacy approach here, so if anything was to go, those functions would be it. I'm not sure getting rid of them is worth the hassle though (especially in 2.x). Regarding bytes.hex(), it may be better to modify the builtin hex() function to accept bytes as an input type. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] Goodbye
Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) Can you please rephrase the question? What's a tracker-trawler? 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] Goodbye
On 23/09/2010 10:38, Martin v. Löwis wrote: Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) Can you please rephrase the question? What's a tracker-trawler? My invented terminology for someone -- like Mark -- who invests time in going through issues in the tracker with a view to assessing them, prioritising them, de-duplicating, etc. As opposed to someone who's looking through issues with a view to finding things to fix within a particular area of competence. TJG ___ 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] Goodbye
On Thu, 23 Sep 2010 13:32:07 +0900 Stephen J. Turnbull step...@xemacs.org wrote: Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. +1. What we really need is people analyzing issues, posting patches or reviewing existing ones. Pushing for resolution of issues by threatening to close them isn't effective; it doesn't magically create more free time for us to deal with them. Regards Antoine. ___ 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] Goodbye
On Wed, 22 Sep 2010 21:24:49 -0400 R. David Murray rdmur...@bitdance.com wrote: deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. If BD means Benevolent Dictator, then I certainly hope we don't need a tracker BD. I think the best until some written guideline exists is to watch how developers use the tracker today. There isn't much of a workflow apart from the initial version and priority setting. Everything is pretty much informal although we usually tend to follow the same steps. Regards Antoine. ___ 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 2:40 AM, Georg Brandl g.bra...@gmx.net wrote: That's right. It is true that it isn't branch-specific information, and that does cause a little bit of irritation for me too, but neither is Misc/developers.txt or Misc/maintainers.rst. Agreed. I'd rather those were elsewhere as well, but I was paying less attention at the time. Of course, we might consider a separate HG repository (I'm all in favor of many small repos, instead of a gigantic sandbox one). The downside is that I really like the developer docs at docs.python.org, and it would complicate the build process a bit. Perhaps someone here knows enough about our documentation toolchain to figure out a way to generate a link from the docs to developer docs on the website. :-) I expect only a very small part of the audience for the general Python documentation CPython docs are particularly interested in the development process we use, and sending them to the website from a convenient link is not a bad thing. We won't even need a new repository to do that. -Fred -- Fred L. Drake, Jr. fdrake at acm.org A storm broke loose in my mind. --Albert Einstein ___ 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] Moving the developer docs?
On Thu, 23 Sep 2010 00:29:51 -0400 Fred Drake fdr...@acm.org wrote: On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannon br...@python.org wrote: the first thing on the agenda is a complete rewrite of the developer docs and moving them into the Doc/ directory I'd like to know why you think moving the developer docs into the CPython tree makes sense. My own thought here is that they're not specific to the version of Python, though some of the documentation deals with the group of specific branches being maintained. Many parts of the library docs aren't version-specific either :) The dev docs may differ slightly from one version to another, for example if a version introduces some new possibilities for tooling, or far-reaching implementation changes (think Unladen Swallow). The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. Regards Antoine. ___ 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] Goodbye
Am 23.09.2010 11:43, schrieb Tim Golden: On 23/09/2010 10:38, Martin v. Löwis wrote: Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) Can you please rephrase the question? What's a tracker-trawler? My invented terminology for someone -- like Mark -- who invests time in going through issues in the tracker with a view to assessing them, prioritising them, de-duplicating, etc. As opposed to someone who's looking through issues with a view to finding things to fix within a particular area of competence. Ah. I think this goes to the core of the dispute: My recommendation is not to trawl at all. Instead, if you *really* want to contribute to Python, pick some area that you think needs most attention, and go through the tracker, and acquire competence in that area. The question is how much time you want to spend per issue. If it's only a few minutes per issue, I question whether this is a useful activity. If the issue has been long-standing, most likely, a few minutes will not be enough. There may, occasionally, be an issue that has been forgotten about, but overall, I'd expect that that the amount of wasted time becomes considerable - you can spend hours and hours looking through issues just to find out that they are all really tricky and would require a lot of expertise to resolve, which you then are not willing to acquire. Also, for me, as somebody on the nosy list, this activity doesn't help: *I* would have to spend much more time than I have at hands. So any is this still valid? message gets deleted immediately, especially if there are ten of them in my inbox. 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] Goodbye
On 23/09/2010 10:59, Antoine Pitrou wrote: On Thu, 23 Sep 2010 13:32:07 +0900 Stephen J. Turnbullstep...@xemacs.org wrote: Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. +1. What we really need is people analyzing issues, posting patches or reviewing existing ones. Pushing for resolution of issues by threatening to close them isn't effective; it doesn't magically create more free time for us to deal with them. Well, useful things that can still be done in triaging on old issues: checking that a bug still exists checking that a patch still applies and that tests still pass pointing out if a patch lacks tests seeing if the issue is duplicated elsewhere If it is a *feature request* (as opposed to a bug report - and I appreciate that the difference is often unclear) and the original poster has 'lost interest' then closing the issue may be a reasonable response. As others have mentioned, bumping old issues can bring it to the attention of developers monitoring on IRC or the bug mailing list who may not have seen the original report. On all issues, new or old, additional potentially useful things to do: make sure the issue is assigned to the right person if appropriate add relevant keywords to make it easier to find in searches ensure other fields in the tracker are filled in correctly closing the issue if it is invalid or expired (for example it only applies to an out of maintenance version of Python) Some developers (Martin and Antoine at least) have complained about the 'noise' of receiving extra emails on issues they are nosy on. Several developers have stated that they have found it useful (myself, Guido and Tim Golden at least) - so there is certainly no consensus that this work is pointless. All the best, Michael Foord Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Moving the developer docs?
On 23/09/2010 11:11, Antoine Pitrou wrote: On Thu, 23 Sep 2010 00:29:51 -0400 Fred Drakefdr...@acm.org wrote: On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannonbr...@python.org wrote: the first thing on the agenda is a complete rewrite of the developer docs and moving them into the Doc/ directory I'd like to know why you think moving the developer docs into the CPython tree makes sense. My own thought here is that they're not specific to the version of Python, though some of the documentation deals with the group of specific branches being maintained. Many parts of the library docs aren't version-specific either :) The dev docs may differ slightly from one version to another, for example if a version introduces some new possibilities for tooling, or far-reaching implementation changes (think Unladen Swallow). The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. +1 Michael Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] (no subject)
Hi. I have an issue which has been annoying me from quite sometime and any help would be greatly appreciated: I just installed Python 2.6 on my centOS 5 system and then I installed nltk. Now I am running a certain python script and it gives me this error- ImportError: No module named _sqlite3 Searching the internet tells me that sqlite should be installed on my system which is confirmed when I try to install it using yum. Yum tells me that all of the following are installed on my system- sqlite-devel.i386 sqlite.i386 python-sqlite.i386 Can anyone tell me where I am going wrong. -- Regards, Ketan Vijayvargiya ___ 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] (no subject)
Hi! This mailing list is about developing Python itself, not about developing *in* Python or debugging Python installations. Try seeing help elsewhere, such as on the comp.lang.python newsgroup, #python IRC channel on freenode, or other sources (check the wiki if you need any others). Thanks, lvh ___ 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] Goodbye
make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. ensure other fields in the tracker are filled in correctly Likewise. 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] Goodbye
On 23/09/2010 13:11, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. Some people have requested to be assigned to issues. (Myself for unittest, Ronald for Mac OS X issues etc.) add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. All the best, Michael ensure other fields in the tracker are filled in correctly Likewise. Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 6:11 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 23 Sep 2010 00:29:51 -0400 Fred Drake fdr...@acm.org wrote: On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannon br...@python.org wrote: the first thing on the agenda is a complete rewrite of the developer docs and moving them into the Doc/ directory I'd like to know why you think moving the developer docs into the CPython tree makes sense. My own thought here is that they're not specific to the version of Python, though some of the documentation deals with the group of specific branches being maintained. Many parts of the library docs aren't version-specific either :) The dev docs may differ slightly from one version to another, for example if a version introduces some new possibilities for tooling, or far-reaching implementation changes (think Unladen Swallow). The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. Agreed with Antoine here the additional workflow/repo/build process/etc sucks Besides - who cares if only a subset of users would be interested in our workflow? If it's more than 0, and it helps bring on new contributors, who cares? If we can make it easier to maintain information, and find that information, why not do it? 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
Re: [Python-Dev] (no subject)
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Thu, Sep 23, 2010 at 05:26:21PM +0530, Ketan Vijayvargiya wrote: Hi. I have an issue which has been annoying me from quite sometime and any help would be greatly appreciated: I just installed Python 2.6 on my centOS 5 system and then I installed nltk. Now I am running a certain python script and it gives me this error- ImportError: No module named _sqlite3 Searching the internet tells me that sqlite should be installed on my system which is confirmed when I try to install it using yum. Yum tells me that all of the following are installed on my system- sqlite-devel.i386 sqlite.i386 python-sqlite.i386 Can anyone tell me where I am going wrong. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] Goodbye
add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. Sure. However, on any specific search, many issues come up already. So people searching for stuff to do will easily find tasks already. 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] Goodbye
On 23/09/2010 13:28, Martin v. Löwis wrote: add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. Sure. However, on any specific search, many issues come up already. So people searching for stuff to do will easily find tasks already. Seems to me that the distinction to be made here is between activity which might, to some, appear a waste of time (eg setting flags and versions on existing calls) but which at worst provides no benefit and in fact might help someone narrow down a search more easily; and activity which is simply flatus vocis and which actually distracts or irritates. Individuals' thresholds clearly vary. TJG ___ 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote: The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. This is the key point for me. For developer controlled stuff, the easiest place to have it if we want it kept up to date is in the source tree. Second best is the wiki. Having it off in a separately managed repository (that exists for perfectly valid reasons, since a lot of the content *isn't* developer controlled) is annoying. That said, in this case, what's the advantage of the source tree over the wiki? To include it in the main docs, so people reading them offline can still see the contribution workflow? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] Tracker BD Was:Goodbye
On Thursday 23 September 2010 08:36:47 Georg Brandl wrote: This should be easy to do with a hg repo such as the test conversion one on hg.python.org -- the activity extension already does the graphing, and I'm sure it can easily be tweaked to your liking. http://www.freehackers.org/thomas/2008/10/31/activity-extension-for-mercurial/ Hi all, This blog entry is old, and I have improved 'hg activity' since then, for example the extension can now display several graphs, splitting the activity by authors, branches, files, ... And, of course, I would be very happy to help 'tweaking' the script for the python community. best wishes, Thomas ps: i'm not subscribed to python-dev. -- Thomas Capricelli or...@freehackers.org http://www.freehackers.org/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] Moving the developer docs?
On Sep 23, 2010, at 08:40 AM, Georg Brandl wrote: That's right. It is true that it isn't branch-specific information, and that does cause a little bit of irritation for me too, but neither is Misc/developers.txt or Misc/maintainers.rst. Of course, we might consider a separate HG repository (I'm all in favor of many small repos, instead of a gigantic sandbox one). The downside is that I really like the developer docs at docs.python.org, and it would complicate the build process a bit. Ideally, I would really like to see the developer docs live outside the CPython source repository. There's no reason to tie the dev docs to CPython's svn merge policies, write acls, or release schedules. Given the way docs.python.org is stitched together, and the fact that we (still ;) haven't moved to a dvcs, this may not be feasible. These docs are better off in the wiki than in the source tree. -Barry signature.asc Description: 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] Moving the developer docs?
2010/9/23 Barry Warsaw ba...@python.org: On Sep 23, 2010, at 08:40 AM, Georg Brandl wrote: That's right. It is true that it isn't branch-specific information, and that does cause a little bit of irritation for me too, but neither is Misc/developers.txt or Misc/maintainers.rst. Of course, we might consider a separate HG repository (I'm all in favor of many small repos, instead of a gigantic sandbox one). The downside is that I really like the developer docs at docs.python.org, and it would complicate the build process a bit. Ideally, I would really like to see the developer docs live outside the CPython source repository. There's no reason to tie the dev docs to CPython's svn merge policies, write acls, or release schedules. Given the way docs.python.org is stitched together, and the fact that we (still ;) haven't moved to a dvcs, this may not be feasible. Are any of our docs subject to release schedules? These docs are better off in the wiki than in the source tree. -- Regards, Benjamin ___ 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 10:01 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 08:40 AM, Georg Brandl wrote: That's right. It is true that it isn't branch-specific information, and that does cause a little bit of irritation for me too, but neither is Misc/developers.txt or Misc/maintainers.rst. Of course, we might consider a separate HG repository (I'm all in favor of many small repos, instead of a gigantic sandbox one). The downside is that I really like the developer docs at docs.python.org, and it would complicate the build process a bit. Ideally, I would really like to see the developer docs live outside the CPython source repository. There's no reason to tie the dev docs to CPython's svn merge policies, write acls, or release schedules. Given the way docs.python.org is stitched together, and the fact that we (still ;) haven't moved to a dvcs, this may not be feasible. These docs are better off in the wiki than in the source tree. -Barry -1 on wiki; wikis are where good information goes off to die. ___ 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] Moving the developer docs?
On Thu, 23 Sep 2010 23:35:02 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote: The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. This is the key point for me. For developer controlled stuff, the easiest place to have it if we want it kept up to date is in the source tree. Second best is the wiki. Having it off in a separately managed repository (that exists for perfectly valid reasons, since a lot of the content *isn't* developer controlled) is annoying. That said, in this case, what's the advantage of the source tree over the wiki? To include it in the main docs, so people reading them offline can still see the contribution workflow? I'd *much* rather edit rst files than futz with a web interface when editing docs. The wiki also somehow feels less official. I do think exposing our development process to the wider user community by including them in the main docs could foster additional community involvement, but I don't have a strong opinion on that aspect of it. For me the change is about making it easier for the dev community (who are using/creating the development infrastructure) to update the relevant documentation. -- R. David Murray www.bitdance.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] Moving the developer docs?
On 23/09/2010 15:16, R. David Murray wrote: On Thu, 23 Sep 2010 23:35:02 +1000, Nick Coghlanncogh...@gmail.com wrote: On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrousolip...@pitrou.net wrote: The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. This is the key point for me. For developer controlled stuff, the easiest place to have it if we want it kept up to date is in the source tree. Second best is the wiki. Having it off in a separately managed repository (that exists for perfectly valid reasons, since a lot of the content *isn't* developer controlled) is annoying. That said, in this case, what's the advantage of the source tree over the wiki? To include it in the main docs, so people reading them offline can still see the contribution workflow? I'd *much* rather edit rst files than futz with a web interface when editing docs. The wiki also somehow feels less official. I do think exposing our development process to the wider user community by including them in the main docs could foster additional community involvement, but I don't have a strong opinion on that aspect of it. For me the change is about making it easier for the dev community (who are using/creating the development infrastructure) to update the relevant documentation. +1 Keeping the dev docs in the development tree sounds good to me (however they are deployed to the web - but preferably automagically). Michael -- R. David Murray www.bitdance.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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Moving the developer docs?
On Thu, 23 Sep 2010 10:16:01 -0400 R. David Murray rdmur...@bitdance.com wrote: On Thu, 23 Sep 2010 23:35:02 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote: The practicality argument of being able to edit those docs without having to master a separate (pydotorg) workflow sounds quite strong to me. This is the key point for me. For developer controlled stuff, the easiest place to have it if we want it kept up to date is in the source tree. Second best is the wiki. Having it off in a separately managed repository (that exists for perfectly valid reasons, since a lot of the content *isn't* developer controlled) is annoying. That said, in this case, what's the advantage of the source tree over the wiki? To include it in the main docs, so people reading them offline can still see the contribution workflow? I'd *much* rather edit rst files than futz with a web interface when editing docs. The wiki also somehow feels less official. I agree with the less official point. If our developer docs feel authoritative, people will be more encouraged to contribute. Also, the wiki in its current state looks much less polished than the Sphinx-generated docs. Regards Antoine. ___ 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] Moving the developer docs?
On Sep 23, 2010, at 10:16 AM, R. David Murray wrote: I'd *much* rather edit rst files than futz with a web interface when editing docs. The wiki also somehow feels less official. There are dvcs-backed wikis, for example: https://launchpad.net/wikkid :) I don't agree that the wiki feels less official, or perhaps that it *should* feel any less official. It's an important source of Pythonic information, and to me it feels much more inclusive and open. -Barry signature.asc Description: 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] Moving the developer docs?
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) -Barry signature.asc Description: 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] Moving the developer docs?
On Sep 23, 2010, at 09:06 AM, Benjamin Peterson wrote: Are any of our docs subject to release schedules? I guess what I'm concerned about is this scenario: You're a developer who has the source code to Python 3.1. You read the in-tree docs to get a sense of how our development process works. Now, you're a diligent and eager new contributor so you follow those instructions to the letter. Unfortunately, Python 3.5 is the current version and we've changed key parts of the process. There's no possible way that your 3.1 in-tree docs can be updated to reflect the new process. Okay, we can tell you to get the Python 3.5 code, or probably better yet, the Python 3.6 in-development trunk, but now we've got another dilemma. If we change the process in 3.6, there will be pressure to update the docs in 3.5 and previous versions that are still officially maintained. And what about security-only versions of Python? Our development processes are *primarily* independent of Python version, so I don't think they should be tied to our source tree, and our CPython source tree at that. I suspect the version-dependent instructions will be minimal and can be handled by the rare footnotes or whatever. IMHO of course, -Barry signature.asc Description: 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) I do. I visit it as little as possible. :( ___ 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] Moving the developer docs?
Am 23.09.2010 16:33, schrieb Barry Warsaw: On Sep 23, 2010, at 10:16 AM, R. David Murray wrote: I'd *much* rather edit rst files than futz with a web interface when editing docs. The wiki also somehow feels less official. There are dvcs-backed wikis, for example: https://launchpad.net/wikkid :) I don't agree that the wiki feels less official, or perhaps that it *should* feel any less official. It's an important source of Pythonic information, and to me it feels much more inclusive and open. This impression comes along with the authority of potential authors. If only the release manager can write a document, it is very official. If any committer can write, but nobody else, it feels less officical. If anybody could modify the document, it's even less official. Since anybody can write to the Python wiki, it feels not very official. It's the same reason why people often trust Wikipedia less than a printed encyclopedia. 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 7:35 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) I have to agree with Jesse. We have too many wiki pages that are so out of date they're dangerous. They serve a purpose, and I think we should have a wiki in addition to the official documentation. This could be aggressively linked from it so people can comment on that documentation -- a commenting system like the PHP docs have would be even better, but that's been an unimplemented idea for so long that I'm not holding my hopes up. But when one person (or a small group) sits down to write the official guidelines for doing something, I think using proper revision control and so on can only help improve the docs and keep them up to date. -- --Guido van Rossum (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] Moving the developer docs?
On Sep 23, 2010, at 10:43 AM, Jesse Noller wrote: On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) I do. I visit it as little as possible. :( Bummer. There's no reason it *has* to be useless though. The Moin developer now has shell access, so if there are technical problems with wiki, like its theme, performance, or lack of features, we can get those fixed. If it's the content or organization that needs improvement, then we can recruit from the much larger Python community than those that have write access to the core svn. Let's honor and encourage folks who are really good at tending to wikis and give them the tools they need to make the wiki excellent. Of course, if the consensus is that wikis are just a waste of time and do more harm than good, then we should shut ours down. (I don't agree it is though.) -Barry signature.asc Description: 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 7:47 AM, Martin v. Löwis mar...@v.loewis.de wrote: Am 23.09.2010 16:33, schrieb Barry Warsaw: On Sep 23, 2010, at 10:16 AM, R. David Murray wrote: I'd *much* rather edit rst files than futz with a web interface when editing docs. The wiki also somehow feels less official. There are dvcs-backed wikis, for example: https://launchpad.net/wikkid :) I don't agree that the wiki feels less official, or perhaps that it *should* feel any less official. It's an important source of Pythonic information, and to me it feels much more inclusive and open. This impression comes along with the authority of potential authors. If only the release manager can write a document, it is very official. If any committer can write, but nobody else, it feels less officical. If anybody could modify the document, it's even less official. Since anybody can write to the Python wiki, it feels not very official. It's the same reason why people often trust Wikipedia less than a printed encyclopedia. I want to believe your theory (since I also have a feeling that some wiki pages feel less trustworthy than others) but my own use of Wikipedia makes me skeptical that this is all there is -- on many pages on important topics you can clearly tell that a lot of effort went into the article, and then I trust it more. On other places you can tell that almost nobody cared. But I never look at the names of the authors. -- --Guido van Rossum (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] Moving the developer docs?
On Thu, Sep 23, 2010 at 10:53 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 10:43 AM, Jesse Noller wrote: On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) I do. I visit it as little as possible. :( Bummer. There's no reason it *has* to be useless though. The Moin developer now has shell access, so if there are technical problems with wiki, like its theme, performance, or lack of features, we can get those fixed. If it's the content or organization that needs improvement, then we can recruit from the much larger Python community than those that have write access to the core svn. Let's honor and encourage folks who are really good at tending to wikis and give them the tools they need to make the wiki excellent. Of course, if the consensus is that wikis are just a waste of time and do more harm than good, then we should shut ours down. (I don't agree it is though.) -Barry To be honest; while I have a strong dislike for them - I think they work fine for unofficial sources of information, I don't think they work well for official we stand by this style information. So, no, I don't think it's totally useless, but I do think it's an information sinkhole, and I would never seriously publish anything I had to stand by to a completely public wiki personally. The larger community, however, probably finds it useful to have it as a resource, even as scattered and spottily curated as it can be - I just don't think it's a good location for official developer/development docs. I don't think we have the needed curation resources to keep on top of the willy-nilly editing wikis incur. 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
Re: [Python-Dev] Moving the developer docs?
On Thu, Sep 23, 2010 at 16:56, Guido van Rossum gu...@python.org wrote: I want to believe your theory (since I also have a feeling that some wiki pages feel less trustworthy than others) but my own use of Wikipedia makes me skeptical that this is all there is -- on many pages on important topics you can clearly tell that a lot of effort went into the article, and then I trust it more. On other places you can tell that almost nobody cared. But I never look at the names of the authors. Right -- I feel like wiki quality varies with the amount of attention spent on maintaining it. Wikis that get a lot of maintenance (or have someone devoted to wiki gardening) will be good (consistent and up to date), while wikis that are only occasionally updated, or updated without much consistency or added to without editing get to feel bad. Seems like a variation of the broken window theory. So what we really need is a way to make editing the developer docs more rewarding (or less hard) for potential authors (i.e. python committers). If putting it in a proper VCS so they can use their editor of choice would help that, that seems like a good solution. Cheers, Dirkjan ___ 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] Python wiki
On Thu, 23 Sep 2010 10:53:55 -0400 Barry Warsaw ba...@python.org wrote: Of course, if the consensus is that wikis are just a waste of time and do more harm than good, then we should shut ours down. (I don't agree it is though.) I don't think they are a waste of time. However, as you and Dirkjan pointed out, a wiki needs some gardening to take care of its structure and its presentation. The present Python wiki isn't very inviting graphically, and its structure doesn't look very thought out. Regards Antoine. ___ 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] Moving the developer docs?
There's no reason it *has* to be useless though. The Moin developer now has shell access, so if there are technical problems with wiki, like its theme, performance, or lack of features, we can get those fixed. If it's the content or organization that needs improvement, then we can recruit from the much larger Python community than those that have write access to the core svn. Let's honor and encourage folks who are really good at tending to wikis and give them the tools they need to make the wiki excellent. Of course, if the consensus is that wikis are just a waste of time and do more harm than good, then we should shut ours down. (I don't agree it is though.) I don't think there is (or can be) consensus about that. However, Jesse's objection is fairly widespread also, and it is not specific for wiki.python.org, or MoinMoin, but opposing Wikis as general. By nature (quick-quick), information is unorganized in a Wiki. This is what wiki advocates cite as its main feature, and wiki opponents as its main flaw. 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] Moving the developer docs?
Hello All, I am new to this list, but I have been lurking around getting a feel for the environment and processes. I had some discussion yesterday about the developer documentation as well, since it’s what I do professionally. I am a technical writer but also work in the web development arena (using Django). In fact one of my projects now is to develop a comprehensive platform for distributing online help, user documentation, etc. which I am just about to put up on BitBucket (winter ’10). Anyway, that said, with regard to Wikis. I have worked in several organizations where almost all of the development documentation was maintained on a wiki. This can be great for getting up and running with something quickly, but over time it becomes very unmanageable and confusing. What I have done in various organizations has been to create a system where an official repository is kept with all of the *official* documentation and a way for users (developers) to submit their proposals as to what they would like to add and change. These proposals are kept in a tracker where they are read and evaluated. Generally, some discussion ensues and the choices are made as to what stays published or changed. This is what the system I am writing is all about as well. It maintains the documentation, and allows for users to comment on various parts of that documentation and submit requests to change or add. The admins can then change or deny the documentation based on community response. Anyway, I am not pitching my idea or trying to hump my system but I will be releasing it before winter on BitBucket for anyone to try and distribute freely. I do however, discourage the use of wikis at all costs. It has been said that they feel loose and unofficial, and although that my not be the intent, over time this becomes reality. Anyway, thank you for your time. Warmest Regards, Steve On Thu, Sep 23, 2010 at 11:06 AM, Dirkjan Ochtman dirk...@ochtman.nlwrote: On Thu, Sep 23, 2010 at 16:56, Guido van Rossum gu...@python.org wrote: I want to believe your theory (since I also have a feeling that some wiki pages feel less trustworthy than others) but my own use of Wikipedia makes me skeptical that this is all there is -- on many pages on important topics you can clearly tell that a lot of effort went into the article, and then I trust it more. On other places you can tell that almost nobody cared. But I never look at the names of the authors. Right -- I feel like wiki quality varies with the amount of attention spent on maintaining it. Wikis that get a lot of maintenance (or have someone devoted to wiki gardening) will be good (consistent and up to date), while wikis that are only occasionally updated, or updated without much consistency or added to without editing get to feel bad. Seems like a variation of the broken window theory. So what we really need is a way to make editing the developer docs more rewarding (or less hard) for potential authors (i.e. python committers). If putting it in a proper VCS so they can use their editor of choice would help that, that seems like a good solution. Cheers, Dirkjan ___ 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/stevenrelliottjr1%40gmail.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] Moving the developer docs?
I have to agree with Jesse. We have too many wiki pages that are so out of date they're dangerous. They serve a purpose, and I think we should have a wiki in addition to the official documentation. This could be aggressively linked from it so people can comment on that documentation -- a commenting system like the PHP docs have would be even better, but that's been an unimplemented idea for so long that I'm not holding my hopes up. You must have forgotten that you lent the time machine keys to Georg, though :-) http://gsoc.jacobmason.us/blog/?p=35 http://bitbucket.org/jacobmason/sphinx-web-support http://gsoc.jacobmason.us/demo/contents 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] Moving the developer docs?
On Thu, 23 Sep 2010 10:41:35 -0400, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 09:06 AM, Benjamin Peterson wrote: Are any of our docs subject to release schedules? I guess what I'm concerned about is this scenario: You're a developer who has the source code to Python 3.1. You read the in-tree docs to get a sense of how our development process works. Now, you're a diligent and eager new contributor so you follow those instructions to the letter. Unfortunately, Python 3.5 is the current version and we've changed key parts of the process. There's no possible way that your 3.1 in-tree docs can be updated to reflect the new process. Except for major changes like the transition to hg, the dev process is no more likely to change than the code base (probably less!). That is, the eager developers with the 3.1 source code are just as likely to produce a patch that won't be useful because it doesn't apply to the current maintained versions as they are to encounter a piece of the dev process that has changed enough to break what they tried to do. (In this context, the switch to hg is analogous to the switch to Python3...) Also, the existence of the docs in the repository is (IMO) for *editing* convenience. The real place a new developer will be looking at the docs is on the web site, just as the place most people (even developers, unless I miss my guess; I know I do) look for Python documentation is on the web site. And that version will be up to date. Okay, we can tell you to get the Python 3.5 code, or probably better yet, the Python 3.6 in-development trunk, but now we've got another dilemma. If we change the process in 3.6, there will be pressure to update the docs in 3.5 and previous versions that are still officially maintained. And what about security-only versions of Python? Yes, and? We update the docs of the maintained Python versions all the time. Doc backports are standard (even if Georg does most of them in batches) unless the documentation is about a new feature. The fact that even 'new features' of the dev process would also get backported is merely a detail. We don't update docs for security releases as far as I know, so I would expect we wouldn't update the dev docs either. Our development processes are *primarily* independent of Python version, so I don't think they should be tied to our source tree, and our CPython source tree at that. I suspect the version-dependent instructions will be minimal and can be handled by the rare footnotes or whatever. I don't think our development process applies to anything other than the CPython source. (At least at the moment...if we break out the stdlib that will change, but at that point the stdlib should have its own distinct development process, even if that process shares most of its features with the CPython one.) Our documentation is *primarily* independent of Python version, too, if you go by the ratio of the word count of the substantive changes from version to version to the word count of the docs as a whole :) True, the dev docs are even more independent, but I don't see that as trumping the convenience to the developers of having them in the source tree. A separate repository would also be fine, IMO. If someone can find or write the code to publish that repository to the appropriate location automatically, we could presumably do this even before the rest of the hg transition. --David ___ 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] Python wiki
On Sep 23, 2010, at 05:32 PM, Antoine Pitrou wrote: I don't think they are a waste of time. However, as you and Dirkjan pointed out, a wiki needs some gardening to take care of its structure and its presentation. The present Python wiki isn't very inviting graphically, and its structure doesn't look very thought out. I certainly agree with that. So, how can we solve those problems? Radomir has shell access now so perhaps we can ask him to make the Python wiki theme more visually appealing. What roadblocks do people encounter when they want to help garden or reorganize the wiki? -Barry signature.asc Description: 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] Moving the developer docs?
On Thu, 23 Sep 2010 07:56:19 -0700, Guido van Rossum gu...@python.org wrote: On Thu, Sep 23, 2010 at 7:47 AM, mar...@v.loewis.de wrote: This impression comes along with the authority of potential authors. If only the release manager can write a document, it is very official. If any committer can write, but nobody else, it feels less officical. If anybody could modify the document, it's even less official. Since anybody can write to the Python wiki, it feels not very official. It's the same reason why people often trust Wikipedia less than a printed encyclopedia. I want to believe your theory (since I also have a feeling that some wiki pages feel less trustworthy than others) but my own use of Wikipedia makes me skeptical that this is all there is -- on many pages on important topics you can clearly tell that a lot of effort went into the article, and then I trust it more. On other places you can tell that almost nobody cared. But I never look at the names of the authors. I think you've hit the nail on the head. The Python wiki pages mostly feel like nobody cares. At least that's the case for the ones I've stumbled across. And I'd include my own contributions in that (the email-sig wiki), because I was using them as a work area and have not updated them in some time, since development is now in a code repository. If we can recruit a bunch of somebodies who *do* care, then the wiki would be much more useful. But I still don't want to edit the dev docs there, if I have a choice :) There's a reason I stopped updating the wiki as soon as I moved to a code repository. -- R. David Murray www.bitdance.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] Moving the developer docs?
On Sep 23, 2010, at 11:49 AM, R. David Murray wrote: A separate repository would also be fine, IMO. If someone can find or write the code to publish that repository to the appropriate location automatically, we could presumably do this even before the rest of the hg transition. I'm not necessarily opposed to that either. I do think the switch to hg will cause lots of churn in the dev process, ultimately for the better, but there will be experiment and change at least for the code contribution bits. I'm also not as worried about the authority of the wiki. If we get good contributors and the rest of the community starts linking to wiki urls, it will feel (more) official. Anyway, it's all kind of secondary to actually writing stuff down. wink If Brett's going to do the work, then he gets to decide. :) -Barry signature.asc Description: 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 8:52 AM, Martin v. Löwis mar...@v.loewis.de wrote: I have to agree with Jesse. We have too many wiki pages that are so out of date they're dangerous. They serve a purpose, and I think we should have a wiki in addition to the official documentation. This could be aggressively linked from it so people can comment on that documentation -- a commenting system like the PHP docs have would be even better, but that's been an unimplemented idea for so long that I'm not holding my hopes up. You must have forgotten that you lent the time machine keys to Georg, though :-) http://gsoc.jacobmason.us/blog/?p=35 http://bitbucket.org/jacobmason/sphinx-web-support http://gsoc.jacobmason.us/demo/contents But before Georg returns the keys, he should make sure to install this on docs.python.org. :-) (I like it, but it needs some work. The login page needs instructions for people who've forgotten how to use OpenID. There needs to be an introduction on how to use the comment system at the root of the site. It would be nice to allow anonymous comments (with a way for site managers to turn this off on a per-page basis). And it would be nice if there was a pop-up with snippets of comments when you mouse over a comment bubble.) -- --Guido van Rossum (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] Problems with hex-conversion functions
On 9/23/2010 5:31 AM, Ender Wiggin wrote: I think I have the skills to learn and fix the code itself, but I don't have the time and I am unfamiliar with the process of submitting patches and getting Anyone can submit a patch at bugs.python.org. The process of getting one approved includes responding to questions, suggestions, and criticisms. Beyond that, the process may be short if the patch is simple and non-controversial. Others may take extensive discussion on pydev or other forums. Some are ignored or rejected. One can also participate by commenting on issues started by others. See http://wiki.python.org/moin/TrackerDocs/ for more. them approved. For example, who gets to decide about the correct approach? This particular issue would probably require more discussion than less. However, submission of a patch using one approach would tend to push the discussion to happen. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the developer docs?
Am 23.09.2010 16:35, schrieb Barry Warsaw: On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) Don't worry, as soon as my thesis is gone for good, I will have time to finally make good use of the new features in Sphinx trunk, among them the often request commenting and patching feature. The result -- I dare say -- will be the best of both worlds: no unsupervised changes in content, but the possibility of instant feedback for readers. We'll require some more people wrangling the amount of information we get, but I've got quite a few requests from the community asking for things to help the docs; now I have to refer them to the tracker, which can be less than satisfying, then I can recruit them into the comment-handling team. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the developer docs?
Am 23.09.2010 16:47, schrieb Guido van Rossum: On Thu, Sep 23, 2010 at 7:35 AM, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote: -1 on wiki; wikis are where good information goes off to die. Well, *all* documentation requires vigilance to remain relevant and current. I'm sure you don't think the Python wiki is useless, right? ;) I have to agree with Jesse. We have too many wiki pages that are so out of date they're dangerous. They serve a purpose, and I think we should have a wiki in addition to the official documentation. This could be aggressively linked from it so people can comment on that documentation -- a commenting system like the PHP docs have would be even better, but that's been an unimplemented idea for so long that I'm not holding my hopes up. You should read my tweets more often :) Yes, I know I promised this for last year, but this time the code is already merged, and I just need to polish and set it up on docs.python.org. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the developer docs?
Am 23.09.2010 16:41, schrieb Barry Warsaw: On Sep 23, 2010, at 09:06 AM, Benjamin Peterson wrote: Are any of our docs subject to release schedules? I guess what I'm concerned about is this scenario: You're a developer who has the source code to Python 3.1. You read the in-tree docs to get a sense of how our development process works. Now, you're a diligent and eager new contributor so you follow those instructions to the letter. Unfortunately, Python 3.5 is the current version and we've changed key parts of the process. There's no possible way that your 3.1 in-tree docs can be updated to reflect the new process. That's a pity, of course; however the small amount of bug reports we get that reflects content in old (= unsupported) library documentation suggests that it would not be a problem in practice: Most people look at docs.python.org anyway. Okay, we can tell you to get the Python 3.5 code, or probably better yet, the Python 3.6 in-development trunk, but now we've got another dilemma. If we change the process in 3.6, there will be pressure to update the docs in 3.5 and previous versions that are still officially maintained. And what about security-only versions of Python? Well, with Mercurial we're supposed to check in all changes to the oldest branch they apply to. If everyone changing the dev docs keeps to that, all supported versions will have up-to-date docs. 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] Python wiki
On Thu, 23 Sep 2010 11:57:19 -0400 Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 05:32 PM, Antoine Pitrou wrote: I don't think they are a waste of time. However, as you and Dirkjan pointed out, a wiki needs some gardening to take care of its structure and its presentation. The present Python wiki isn't very inviting graphically, and its structure doesn't look very thought out. I certainly agree with that. So, how can we solve those problems? Radomir has shell access now so perhaps we can ask him to make the Python wiki theme more visually appealing. What roadblocks do people encounter when they want to help garden or reorganize the wiki? Given that few or none of us seem to (want to) actively contribute to the wiki, I'm afraid python-dev is not the place to ask. Perhaps a call should be issued on c.l.py asking interested people to subscribe to pydotorg (or any other list) and start there? By the way, I've just looked at the wiki: there are 2 or 3 edits per day. Compared to the size and vitality of the Python user community, this is a ridiculously low number. Regards Antoine. ___ 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] Moving the developer docs?
If we can recruit a bunch of somebodies who *do* care, then the wiki would be much more useful. But I still don't want to edit the dev docs there, if I have a choice :) There's a reason I stopped updating the wiki as soon as I moved to a code repository. I think that there are plenty that do care; I for one would be more than happy to work on whatever documentation needs might arise for this group. I am a bit of a documentation nut, since its what I do, also I come from the Django camp where people are obsessive over documentation. I still think that wikis are not the best solution but if that is something that needs to be tightened up then it would be something that I personally would have no problem working on. ___ 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] Goodbye
On 9/23/2010 3:18 AM, Martin v. Löwis wrote: I personally think that the tracker fields and how they should be set is of minor importance. As of just now, if you were to wonder What (security) bugs are open for 2.5 and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup. Trying to do searches in databases with inaccurate key data is a pain. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Agreed,at least abstractly, with applying a fix a close second. That does not mean that other activities are useless. However, there are currently 1034 issues with the patch keyword set and perhaps others with pacthes. So I think one can legitimately ask whether adding more *new* patches, to possibly sit unreviewed for years, is the most useful contribution at the moment. In any case, asking whether a patch submitted for 2.5 (and now 2.6) is relevant to future maintenance releases amounts to suggesting that is may not be a bug for current purposes. Certainly, anyone fixing a bug for 2.7 should also know whether or not it is also a 3.x bug. Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Numerous issues have been advanced by the questions I and Mark have asked. Some were legitimately closed as out of date (the bug reported for 2.4/5/6 had already been fixed). Others were closed as fixed when someone committed something. The fact that Mark got over-zealous in closing issues too soon does not negate this. Some of our questions were more specific, and asking questions was not the only things we did. I tested some old reports against 3.1 and I believe Mark also did some testing himself. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/23/2010 8:11 AM, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to d...@python. add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. ensure other fields in the tracker are filled in correctly Likewise. I am guessing that you have never done professional database management. And I suspect you would not be temperamentally suited to such. To repeat what I said in another post, if it does not matter how a field is set, it should not be there. You seem really antagonistic to, or at least dismissive of, people who contribute in ways other than how you do. That strikes me as unhelpful. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Speaking as a frequent contributor of bug reports and an occasional contributor of patches, I must say that I feel like status quo of the tracker before Mark's work was discouraging. If there is a vast collection of abandoned tickets, it gives me the strong impression that my attempted contributions are likely to end up in that pile. The messages I got from the tracker due to Mark's work saying things like This ticket is closed due to inactivity. or Would you be interested in refreshing this patch? started to get me interested in contributing again. Also, I would like to point out that, not having read the other traffic that this thread alludes to, either from earlier mailing list threads or from IRC, I don't really understand what exactly Mark did wrong. The complaints about his behavior on this thread seem to be a little... non-specific. Did he continue to close tickets after he was asked not to do so? I didn't see any quotes or timestamps showing what happened or when. Regards, Zooko ___ 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] Moving the developer docs?
On 9/23/2010 7:41 AM, Barry Warsaw wrote: Our development processes are*primarily* independent of Python version, so I don't think they should be tied to our source tree, and our CPython source tree at that. I suspect the version-dependent instructions will be minimal and can be handled by the rare footnotes or whatever. +1 ___ 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] Goodbye
On 9/23/2010 1:44 PM, Terry Reedy wrote: On 9/23/2010 8:11 AM, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to d...@python. add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful. ensure other fields in the tracker are filled in correctly Likewise. I am guessing that you have never done professional database management. And I suspect you would not be temperamentally suited to such. To repeat what I said in another post, if it does not matter how a field is set, it should not be there. You seem really antagonistic to, or at least dismissive of, people who contribute in ways other than how you do. That strikes me as unhelpful. And before this descends into a general discussion of various people's approach to collaboration, let me remind us all that it does indeed take all sorts to make a world. From what I have seen on this list, nobody has suggested that Mark's work was *all* unhelpful. The fact that he can be difficult to work with doesn't remove the value of much of the work he was doing, and I am happy to note that there doesn't seem to be any blanket verdict that Mark should never have tracker privileges again. Mark courageously admitted on this list to having personal problems to overcome. That made me, at least, more sympathetic to his case, and more tolerant of his foibles and style of communication. I appreciate that a disruptive team member might eventually have to be isolated for the good of the team, but I am sorry to note that it came to that in Mark's case, and I hope that eventually he can return to the fold somehow. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ 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] Goodbye
On Thu, 23 Sep 2010 11:50:26 -0600, Zooko O'Whielacronx zo...@zooko.com wrote: Also, I would like to point out that, not having read the other traffic that this thread alludes to, either from earlier mailing list threads or from IRC, I don't really understand what exactly Mark did wrong. The complaints about his behavior on this thread seem to be a little... non-specific. Did he continue to close tickets after he was asked not to do so? I didn't see any quotes or timestamps showing what happened or when. Yes. It was necessary for the devs to monitor his work and re-open tickets he closed inappropriately. We always explained why the closure was inappropriate. The number of tickets closed inappropriately was growing rather than shrinking. It was this latter fact that, I believe, led to what happened. I think this could have been handled better, but thankfully this is not a situation we often find ourselves in, so we don't have much practice at dealing with such. Good ideas for procedures have been aired here as a result, so if the next incident is not too far in the future hopefully we'll handle the next one more smoothly. (But you'll excuse me for hoping it is so far in the future that we forget :) Again, there was nothing preventing Mark from continuing to comment on issues, test things, ask questions, and even suggest that issues be closed. However, his inappropriate response to losing triage privileges was causing significant problems on the tracker, and so we were forced to disable his account. This disabling does not need to be permanent. -- R. David Murray www.bitdance.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] Python wiki
Antoine The present Python wiki isn't very inviting graphically, and Antoine its structure doesn't look very thought out. I imagine it can be made to look more like the rest of python.org without a lot of trouble. As to the structure, like most wikis it quickly resembles a bag-o-pages after awhile. Thank goodness for Google. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
Antoine Given that few or none of us seem to (want to) actively Antoine contribute to the wiki, I'm afraid python-dev is not the place Antoine to ask. Perhaps a call should be issued on c.l.py ... It would be nice if you could actually send messages to the people who do actually update wiki content. Unfortunately, without donning my cape and blue tights, then digging into the users files on the wiki there's no real way to do that. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Am 23.09.2010 19:22, schrieb Terry Reedy: Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Numerous issues have been advanced by the questions I and Mark have asked. Some were legitimately closed as out of date (the bug reported for 2.4/5/6 had already been fixed). Others were closed as fixed when someone committed something. The fact that Mark got over-zealous in closing issues too soon does not negate this. Some of our questions were more specific, and asking questions was not the only things we did. I tested some old reports against 3.1 and I believe Mark also did some testing himself. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. For example, feature requests almost always only belong to the current trunk. Yes, for features that fall under the moratorium, the versions field would be different; however, we already have an after moratorium keyword that signifies this. Other than this, we currently don't assign feature requests to specific milestones, and I don't ever see us doing that. Bug reports by nature almost always belong to all branches in maintenance; if the bug in question is a regression, the reporter will usually report that; if it is in a new feature, a) the reporter might not know that anyway, but b) the committer fixing it will without looking at versions. Security bugs are the last category, but they are also better served with a security keyword than with specific versions settings. The only use I see in the field is for the reporter to indicate which version he used when finding a bug; however this is next to useless since you have to reproduce it anyway, and ask for more detail when you can't. 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] Python wiki
On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw ba...@python.org wrote: I certainly agree with that. So, how can we solve those problems? Radomir has shell access now so perhaps we can ask him to make the Python wiki theme more visually appealing. What roadblocks do people encounter when they want to help garden or reorganize the wiki? First of all Wiki is outdated. Correct me, but python.org specific customizations are not modules, but patches that makes it hard to update the Wiki to latest version or add new customizations. Second - ugly Creole syntax. I am for inter-cooperation between wikis, and I understand that for non-developer communities [] symbols imposing problems, but as an open source developer I am addicted to Trac and Google Code syntax and never had problems with those. Third - there is not starting point to help with wiki. No instructions how to checkout wiki code, how to get python.org modification, how to get sample data and how to get started. This place should be easily editable by anyone (premoderated for disrespectful members), so anyone can share their experience. Take a look at Trac. Fourth. GPL license. I personally don't have interest to waste my time for the code I won't be able to use in some projects, unless the project is either exceptional (Mercurial) or interesting. To make python.org MoinMoin interesting - there should be an inviting entrypoint (see point three above) and the list of tasks to choose form. Something that is better than http://wiki.python.org/moin/SiteImprovements Fifth. Credits and motivation for all python.org works. I still convinced that there should be one primary dedicated list and it should be public. All sensitive issues can be discussed with webmasters@ privately, but the primary list should be run by community. Not the volunteers who are better than others. If there will be a feeling that site is run by community, then you can expect contributions. Otherwise expect the community to think they're doing the stuff here, so they will fix it. -- anatoly t. ___ 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] Goodbye
Le 23/09/2010 19:22, Terry Reedy a écrit : As of just now, if you were to wonder What (security) bugs are open for 2.5 and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup. Let’s fix this. Two days ago, I said this in http://bugs.python.org/issue2200#msg117003 : distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told me to set all available versions for those bugs (2.5-py3k), even if I think “3rd party” is more appropriate and useful (since a distutils2 bug would not for example block a CPython 3.2 release). I’ve been following these rules since before GSoC, when I had less confidence and no will to conflict with Tarek on such a small thing wink. Now I argue that the versions field is not really useful for d2, since it lacks 2.4 which we support and chiefly because it does not actually help our workflow: We don’t have separate branches for backporting fixes, we apply patches and run tests for all supported versions before committing on a single branch. There is no use case of setting a version to remind that a port needs to be done. For bug purposes, I actually see distutils2 as a value for the versions field of distutils bugs. In short, setting versions other than “3rd party” for distutils2 bugs does not help distutils2 and raises unhelpful results for people querying the status of CPython releases. +1 on changing that. respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours, Éric ___ 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] Moving the developer docs?
On Thu, Sep 23, 2010 at 09:05, Barry Warsaw ba...@python.org wrote: On Sep 23, 2010, at 11:49 AM, R. David Murray wrote: A separate repository would also be fine, IMO. If someone can find or write the code to publish that repository to the appropriate location automatically, we could presumably do this even before the rest of the hg transition. I'm not necessarily opposed to that either. I do think the switch to hg will cause lots of churn in the dev process, ultimately for the better, but there will be experiment and change at least for the code contribution bits. I'm also not as worried about the authority of the wiki. If we get good contributors and the rest of the community starts linking to wiki urls, it will feel (more) official. Anyway, it's all kind of secondary to actually writing stuff down. wink If Brett's going to do the work, then he gets to decide. :) Whether it is in Doc/ or a separate Hg repo, I don't care. But I am not doing it in the wiki. While I am totally fine with wikis as a general community thing where community input and editing is good, this is not one of those cases. Our development process belongs to python-dev and thus should be influenced by its members. I do not want to have to police the dev docs after I write them because someone either disagreed or misunderstood what was expected. For something this formal and official I want pro-active instead of reactive editorial oversight. ___ 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] Goodbye
Asking every now and then is this still an issue, or setting the version number, doesn't really advance the issue. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? I didn't say the field does not matter. I said adjusting it doesn't advance the issue. Anybody *really* working on the issue might choose to update it, or might choose to leave it incorrect when the issue is going to be closed, anyway. I do believe that much of the information on closed issues is irrelevant - yet I would oppose to deleting them entirely from the database. 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] Problems with hex-conversion functions
On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin wiggi...@gmail.com wrote: Sorry for the late reply. I would really like to see this fixed. Or we [...] deprecate binascii.(un)hexlify(). ... binascii is the legacy approach here, so if anything was to go, those functions would be it ... I'm not entirely convinced binascii is the legacy approach. What makes this module legacy? Because the binascii functions predate the bytes type, and we added the bytes methods knowing full well that the hexlify/unhexlify functions already existed. On the contrary, I'm pretty sure modularity is better than sticking all the functionality in the core. As was written in this issue: http://psf.upfronthosting.co.za/roundup/tracker/issue3532 If you wanted to produce base-85 (say), then you can extend the functionality of bytes by providing a function that does that, whereas you can't extend the existing bytes type. This example shows that hex is actually getting a special treatment by having builtin methods associated with the bytes type. Why don't we add .base64 methods? Or even .zlib? After all, these options were present in Python 2.x using the encode method of string. In my opinion, having modules to deal with these types of conversions is better, and this is why I suggested sticking to binascii. This *is* a matter of opinion, but python-dev's collective opinion was already expressed in the decision to include these methods in the bytes API. Base 16 *is* given special treatment by many parts of Python, precisely because it *is* special: it's the most convenient way to express binary numbers in a vaguely human readable format. No other coding even comes close to that level of importance in computer science. If no one else is willing to do it (that would be a little disappoiting) Why would it be disappointing? While it's untidy, nothing's actually broken and there are ways for programmers to do everything they want to do. I (and many others here) already have a pretty long list of things I'd like to improve/fix but haven't got around to yet, so it isn't uncommon for things to have to wait awhile before someone looks at them. As Terry said though, there *are* ways to expedite that process (In this case, providing a patch that adds a .hex method in accordance with PEP 358, or, as a more ambitious, extensible alternative, consider updating the hex builtin to support the PEP 3118 API, which would allow it to automatically provide a hex dump of any object that exposes a view of a contiguous sequence of data bytes). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] Goodbye
On 9/23/2010 3:50 PM, Georg Brandl wrote: ISTM that the versions field is not very useful if the other fields are filled accurately. For example, feature requests almost always only belong to the current trunk. Yes, for features that fall under the moratorium, the versions field would be different; however, we already have an after moratorium keyword that signifies this. Other than this, we currently don't assign feature requests to specific milestones, and I don't ever see us doing that. Bug reports by nature almost always belong to all branches in maintenance; For various reasons, there bugs that are 2.x or 3.x specific. Those that are not may require sufficiently different fixes that a fix is applied for one branch while the issue is left open for the other. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl g.bra...@gmx.net wrote: Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] Goodbye
On Fri, Sep 24, 2010 at 3:44 AM, Terry Reedy tjre...@udel.edu wrote: On 9/23/2010 8:11 AM, Martin v. Löwis wrote: make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others. What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to d...@python. The other thing is that the maintainers file is there specifically to help the triage team decide when a direct assignment is appropriate, or just adding people to the nosy list. Since I don't follow the bugs list myself, the latter is *very* helpful to me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] Python wiki
On Fri, Sep 24, 2010 at 4:52 AM, s...@pobox.com wrote: Antoine Given that few or none of us seem to (want to) actively Antoine contribute to the wiki, I'm afraid python-dev is not the place Antoine to ask. Perhaps a call should be issued on c.l.py ... It would be nice if you could actually send messages to the people who do actually update wiki content. Unfortunately, without donning my cape and blue tights, then digging into the users files on the wiki there's no real way to do that. That's a good point actually... why *isn't* there a pydotorg-wiki-sig? (Aside from the obvious point of nobody ever asking for one). I must admit, that the various things I've thrown on there myself have been pretty much fire-and-forget. Without anyone that feels like they collectively own the wiki, the much needed pruning never happens. With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people (e.g. only devs, only the triage team, only the wiki admins). But keeping those user lists up to date is itself something that requires a strong wiki admin team. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] [Python-checkins] r84988 - in python/branches/py3k: Lib/ntpath.py Misc/NEWS
On Fri, Sep 24, 2010 at 6:38 AM, brian.curtin python-check...@python.org wrote: Modified: python/branches/py3k/Lib/ntpath.py == --- python/branches/py3k/Lib/ntpath.py (original) +++ python/branches/py3k/Lib/ntpath.py Thu Sep 23 22:38:14 2010 @@ -641,24 +641,29 @@ # determine if two files are in fact the same file +try: + from nt import _getfinalpathname +except (NotImplementedError, ImportError): + # On Windows XP and earlier, two files are the same if their absolute + # pathnames are the same. + # Also, on other operating systems, fake this method with a + # Windows-XP approximation. + def _getfinalpathname(f): + return abspath(f) This only needs to catch ImportError now. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | 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] Python wiki
With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people (e.g. only devs, only the triage team, only the wiki admins). But keeping those user lists up to date is itself something that requires a strong wiki admin team. There actually is an admin team, and they actually do set ACLs. IIUC, this is primarily for spam protection, though. 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] Python wiki
On Thu, Sep 23, 2010 at 3:35 PM, Martin v. Löwis mar...@v.loewis.de wrote: With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people (e.g. only devs, only the triage team, only the wiki admins). But keeping those user lists up to date is itself something that requires a strong wiki admin team. There actually is an admin team, and they actually do set ACLs. Who are they? IIUC, this is primarily for spam protection, though. So would they object against additions to the team? -- --Guido van Rossum (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] Goodbye
On 9/23/2010 6:17 PM, Nick Coghlan wrote: On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandlg.bra...@gmx.net wrote: Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though. Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
So if there turns out to be a major security hole or sever bug in 2.7, then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of branch? In that case, would you just suggest everyone using 2.7 to jump to 3.x? As long as a 2.x version is supported, filing bugs, branching and even releasing critical updates is, although rare, a fact of life. On Thu, 23 Sep 2010 19:06:29 -0400, Terry Reedy tjre...@udel.edu wrote: On 9/23/2010 6:17 PM, Nick Coghlan wrote: On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandlg.bra...@gmx.net wrote: Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? ISTM that the versions field is not very useful if the other fields are filled accurately. It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though. Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. ___ 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] [Python-checkins] r84988 - in python/branches/py3k: Lib/ntpath.py Misc/NEWS
On Thu, Sep 23, 2010 at 17:30, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Sep 24, 2010 at 6:38 AM, brian.curtin python-check...@python.org wrote: Modified: python/branches/py3k/Lib/ntpath.py == --- python/branches/py3k/Lib/ntpath.py (original) +++ python/branches/py3k/Lib/ntpath.py Thu Sep 23 22:38:14 2010 @@ -641,24 +641,29 @@ # determine if two files are in fact the same file +try: +from nt import _getfinalpathname +except (NotImplementedError, ImportError): +# On Windows XP and earlier, two files are the same if their absolute +# pathnames are the same. +# Also, on other operating systems, fake this method with a +# Windows-XP approximation. +def _getfinalpathname(f): +return abspath(f) This only needs to catch ImportError now. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins Good catch. I put up a patch on http://bugs.python.org/issue9790 to rework this yet again. The NotImplementedError had to do with the underlying Win32 call only existing on Vista and above, and it was loaded at runtime. I added another condition to the import dance which should have us covered. ___ 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] Goodbye
On 9/23/2010 7:12 PM, dar...@ontrenet.com wrote: So if there turns out to be a major security hole or sever bug in 2.7, then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of branch? In that case, would you just suggest everyone using 2.7 to jump to 3.x? As long as a 2.x version is supported, filing bugs, branching and even releasing critical updates is, although rare, a fact of life. I am not sure who or what you are responding to. The below is based on the fact the 2.7 is now closed to *new features* and will be as long as the CPython pydev group maintains it. In another post I said that the Versions field is needed for *bugs* as long as we are maintaining 2.7, which will be for several years, because there are and will continue to be 2.7 and 3.x specific bugs. If you want *new features*, then yes, you need to jump to 3.x. Otherwise you can relax, and perhaps contribute to 2.7 bug fixes if you want. Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Call for proposals -- PyCon 2011
[Forwarding to Python-Dev, as it's of some interest - jesse] Call for proposals -- PyCon 2011 -- http://us.pycon.org/2011/ === Proposal Due date: November 1st, 2010 PyCon is back! With a rocking new website, a great location and more Python hackers and luminaries under one roof than you could possibly shake a stick at. We've also added an Extreme talk track this year - no introduction, no fluff - only the pure technical meat! PyCon 2011 will be held March 9th through the 17th, 2011 in Atlanta, Georgia. (Home of some of the best southern food you can possibly find on Earth!) The PyCon conference days will be March 11-13, preceded by two tutorial days (March 9-10), and followed by four days of development sprints (March 14-17). PyCon 2011 is looking for proposals for the formal presentation tracks (this includes extreme talks). A request for proposals for poster sessions and tutorials will come separately. Want to showcase your skills as a Python Hacker? Want to have hundreds of people see your talk on the subject of your choice? Have some hot button issue you think the community needs to address, or have some package, code or project you simply love talking about? Want to launch your master plan to take over the world with Python? PyCon is your platform for getting the word out and teaching something new to hundreds of people, face to face. In the past, PyCon has had a broad range of presentations, from reports on academic and commercial projects, tutorials on a broad range of subjects, and case studies. All conference speakers are volunteers and come from a myriad of backgrounds: some are new speakers, some have been speaking for years. Everyone is welcome, so bring your passion and your code! We've had some incredible past PyCons, and we're looking to you to help us top them! Online proposal submission is open now! Proposals will be accepted through November 10th, with acceptance notifications coming out by January 20th. To get started, please see: http://us.pycon.org/2011/speaker/ For videos of talks from previous years - check out: http://python.mirocommunity.org/category/conferences For more information on Extreme Talks see: http://us.pycon.org/2011/speaker/extreme/ We look forward to seeing you in Atlanta! Please also note - registration for PyCon 2011 will also be capped at a maximum of 1,500 delegates, including speakers. When registration opens (soon), you're going to want to make sure you register early! Speakers with accepted talks will have a guaranteed slot. Important Dates: * November 1st, 2010: Talk proposals due. * December 15th, 2010: Acceptance emails sent. * January 19th, 2010: Early bird registration closes. * March 9-10th, 2011: Tutorial days at PyCon. * March 11-13th, 2011: PyCon main conference. * March 14-17th, 2011: PyCon sprints days. Contact Emails: Van Lindberg (Conference Chair) - v...@python.org Jesse Noller (Co-Chair) - jnol...@python.org PyCon Organizers list: pycon-organiz...@python.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] Moving the developer docs?
On Fri, 24 Sep 2010 01:50:34 am Steven Elliott Jr wrote: What I have done in various organizations has been to create a system where an official repository is kept with all of the *official* documentation and a way for users (developers) to submit their proposals as to what they would like to add and change. [...] I do however, discourage the use of wikis at all costs. It has been said that they feel loose and unofficial, and although that my not be the intent, over time this becomes reality. Surely that depends on how widely you give write-privileges to the wiki? If you wouldn't give arbitrary people write-access to your documentation repository, why would you give them write-access to your wiki? If the wiki doesn't allow you control who has read and write access, then use a different wiki. I'm not familiar with any wiki that doesn't allow you to track and review history of the documents. Some of them are just web interfaces to standard VCSes like Mercurial. Wikipedia is now experimenting with pending changes and having stable and unstable versions of pages. I've known people to work themselves into a tizz at the thought of their developers making unauthorized changes to the documentation, while not even tracking changes to the source code *at all*, let alone reviewing the commits. This makes no sense to me at all -- if you (generic you, not you specifically) trust your developers to make changes to the source code, why not trust them to make changes to the documentation? The real problem, it seems to me, is the difficulty in getting developers to write and update documentation, not in preventing them from writing it. -- Steven D'Aprano ___ 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] Moving the developer docs?
On Fri, 24 Sep 2010 01:42:03 am Martin v. Löwis wrote: By nature (quick-quick), information is unorganized in a Wiki. This is what wiki advocates cite as its main feature, and wiki opponents as its main flaw. I've never heard wiki advocates say that, and even a cursory glace at wikis like Wikipedia disprove the idea that wikis are necessarily disorganised. Quick does not mean unstructured, disorganised or unorganised. Do you mean that the *contributors* to the wiki are disorganised, rather than the wiki itself? If so, perhaps, but again Wikipedia demonstrates that this is not necessarily the case. Wikipedia has a hierarchy of contributors. In reverse order: - anonymous editors - editors with accounts - administrators - Wikimedia Foundation, which is responsible for policy - BDFL Jimmy Wales who is ultimately responsible for setting policy One of the criticisms of Wikipedia is that it has diverged from its official aim to be the encyclopedia that anyone can edit to one where contributions from insiders, particularly the Cabal, are preferred to those of new anonymous editors. Other wikis have other policies: Citizendium and Scholarpedia are notable examples that attempt to increase the (real or perceived) reliability and accountability of their articles by prohibiting anonymous edits altogether. Despite the influence of Wikipedia, wiki does not mean open to everyone to edit without supervision. -- Steven D'Aprano ___ 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] Python wiki
On Fri, 24 Sep 2010 01:57:19 am Barry Warsaw wrote: I certainly agree with that. So, how can we solve those problems? Radomir has shell access now so perhaps we can ask him to make the Python wiki theme more visually appealing. What roadblocks do people encounter when they want to help garden or reorganize the wiki? For me, the number one roadblock is unfamiliarity -- I always forget that there is a Python wiki. I think it would be helpful if the wiki could be integrated with the docs in some fashion, perhaps by having each page link to a sister page in the wiki. It seems to me that the wiki won't be useful until people regularly use it, and people won't regularly use it until it is useful. It will take a conscious effort by people (including myself) to break this vicious circle by improving articles and regularly linking to them. Number two, I just went to the wiki to see how I might get started. I randomly choose this page: http://wiki.python.org/moin/BeginnersGuide/Download and looked for an edit button or something. Unlike Wikipedia, there is no obvious Edit button. Eventually I noticed in tiny type at the bottom of the page: Immutable page. Hmmm, that's not promising. Then I discovered a *tiny* icon that looks like a speech bubble that apparently means edit. Clicking it gives me a message: You are not allowed to edit this page. Not friendly, nor helpful. A better message might be something like This page is locked. You must log in to edit this page. or similar. How does one get an account? Can I edit anonymously? Once I found a page I could edit, it was relatively straightforward. So that's a plus :) -- Steven D'Aprano ___ 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] Moving the developer docs?
Georg Brandl writes: You should read my tweets more often :) Now *there* is an innovation that never should have happened! At least you're bringing up the average quality with every twit I mean tweet. ___ 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] Python wiki
Am 24.09.2010 00:39, schrieb Guido van Rossum: On Thu, Sep 23, 2010 at 3:35 PM, Martin v. Löwis mar...@v.loewis.de wrote: With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people (e.g. only devs, only the triage team, only the wiki admins). But keeping those user lists up to date is itself something that requires a strong wiki admin team. There actually is an admin team, and they actually do set ACLs. Who are they? I don't actually know entirely; at a minimum, Skip Montanaro. IIUC, this is primarily for spam protection, though. So would they object against additions to the team? I don't think they would. 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] Goodbye
Martin v. Löwis writes: I didn't say the field does not matter. I said adjusting it doesn't advance the issue. Anybody *really* working on the issue might choose to update it, or might choose to leave it incorrect when the issue is going to be closed, anyway. Yes, and we'd all like more people to do more real work. But not everybody has the time or skills. I think this is a case where agreeing to disagree is the best we can do. Specifically, Terry has made a strong case that a few minutes per issue *can* improve the tracker in ways that *are* noticable to some of the developers (and some of them have acknowledged that). It would be nice if the tracker trimmers[1] could assemble 60 of those into a few hours, and do some real work, but that's often just not possible (especially for people with minimal programming expertise as yet). Footnotes: [1] Trawlers take fish out of the ocean: not really the best metaphor. Gardening is a better metaphor. ___ 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
