[Python-Dev] PEP 239 - Rational
PEP 239 says that Rational type was Rejected, but some time ago this decision is reverted, and now python 3.0 and python 2.6 includes a fractions.Fraction type. Shouldn't this PEP be updated? (At least to include a note of its obsoleted status or to point to the reversion) ___ 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] IDLE maintenance
As I said, I don't know the plans or people surrounding IDLE are. If it needs a new maintainer I hereby volunteer. Can you please start by looking into the issues reported for the IDLE component? (there are currently 71 of them) For those with a patch in particular (17 currently), make a recommendation whether to accept or reject the patch (perhaps giving the submitter a chance to revise the patch if you have complaints). Post a list of patches that you have triaged to this list. For the bug reports, review whether the bug is reproducible, and if so, propose a patch. If not, put an analysis into the report, and post a list of patches that you propose to close here. For feature requests, analyze whether the feature is desirable and sound. If it is, propose a patch. If not, post a list of requests to close here (and an analysis into the report). 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] Integrate BeautifulSoup into stdlib?
I'd like to suggest that any new candidate for the standard library be discussed and then set aside for a cooling off period of ONE YEAR. If then folks can all agree the library is not only Goodness, but of general interest, especially for bootstrapping small projects, then take a vote, or the BDFL can decide. A key criteria should be, Will the new library help small projects get started by providing basic capabilities without introducing a steep learning curve? These are all thoughts that I can sympathize with. 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] RELEASED Python 3.1 alpha 1
On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Are there any plans for a Windows installer? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.1 alpha 1
On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Are there any plans for a Windows installer? Yes. However, I cannot produce them on weekends. 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] RELEASED Python 3.1 alpha 1
Martin v. Löwis wrote: On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Are there any plans for a Windows installer? Yes. However, I cannot produce them on weekends. Sounds like a bug in the MS installer. Dates are just sooo hard to handle these days, especially since 7 was nominated prime. Stefan ;o) ___ 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] BZR mirror and pushing to Launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 9, 2009, at 1:26 AM, Andrew Bennetts wrote: On the other hand, it does appear that https://code.launchpad.net/~rdmurray/python/bug5450 is a branch that is not stacking-capable. I'm not sure how this could happen by following the instructions on the the wiki page. Perhaps RDM branched from code.python.org before I upgraded the repository format to 1.9-rich-root? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSbUIcnEjvBPtnXfVAQI47AP/QdS/7qyrGXseNsDYLIl/aRC4DV3HOBxm G4721SchQAw8CF6zJw1gU/Guw4b+S96eYD3MHBM2B6qgSXZ3SMXGoWvVl2xwKbFd s29f9ALZZaXuj3YU5YY3ildCQmKx0Kxaqbp9Hu1UdaAAZrq25rI2vMbtdTphtG2j i8vQZZifegY= =1HK/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BZR mirror and pushing to Launchpad
On Mon, 9 Mar 2009 at 08:15, Barry Warsaw wrote: On Mar 9, 2009, at 1:26 AM, Andrew Bennetts wrote: On the other hand, it does appear that https://code.launchpad.net/~rdmurray/python/bug5450 is a branch that is not stacking-capable. I'm not sure how this could happen by following the instructions on the the wiki page. Perhaps RDM branched from code.python.org before I upgraded the repository format to 1.9-rich-root? I grabbed the tarball and made my initial branch on 2/20, from python.org. Then I branched from that to make the branch I pushed to Launchpad. Could the second branch be the problem? I just did 'bzr branch trunk trunk-myfix'. Is there a way I can check if my branch is stacking capable? (I'm very new to bzr.) -- R. David Murray http://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] BZR mirror and pushing to Launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 9, 2009, at 9:02 AM, R. David Murray wrote: On Mon, 9 Mar 2009 at 08:15, Barry Warsaw wrote: On Mar 9, 2009, at 1:26 AM, Andrew Bennetts wrote: On the other hand, it does appear that https://code.launchpad.net/~rdmurray/python/bug5450 is a branch that is not stacking-capable. I'm not sure how this could happen by following the instructions on the the wiki page. Perhaps RDM branched from code.python.org before I upgraded the repository format to 1.9-rich-root? I grabbed the tarball and made my initial branch on 2/20, from python.org. Then I branched from that to make the branch I pushed to Launchpad. Could the second branch be the problem? I just did 'bzr branch trunk trunk-myfix'. I upgraded the repository on 2/25, so it's possible your older tarball is the problem. try running 'bzr upgrade --1.9.rich-root' on it and see if that allows you to stack on Launchpad. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSbUaAnEjvBPtnXfVAQLnggP/bF/P4N5WqwW4ozHOrbL1hJ9mc1nDdb9s 4z8V75qIiHJTYRQ3A9koTQJzEzCrsrqwhW04zs+hJikhHp1ZqjEVYdEvI4ibDikr yigsbiI/XWHt1KaKBiRGXDal47NXyvy7VDkc5QMoPAyx7ed7lvbqslHIkJJqJR1N 6ZmnZ9AZnvw= =+6oN -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BZR mirror and pushing to Launchpad
On Mon, 9 Mar 2009 at 10:49, Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- On Mar 9, 2009, at 10:48 AM, R. David Murray wrote: On Mon, 9 Mar 2009 at 09:30, Barry Warsaw wrote: On Mar 9, 2009, at 9:02 AM, R. David Murray wrote: On Mon, 9 Mar 2009 at 08:15, Barry Warsaw wrote: Perhaps RDM branched from code.python.org before I upgraded the repository format to 1.9-rich-root? I grabbed the tarball and made my initial branch on 2/20, from python.org. Then I branched from that to make the branch I pushed to Launchpad. Could the second branch be the problem? I just did 'bzr branch trunk trunk-myfix'. I upgraded the repository on 2/25, so it's possible your older tarball is the problem. try running 'bzr upgrade --1.9.rich-root' on it and see if that allows you to stack on Launchpad. Hmm. My client is 1.12, and it says: rdmur...@maestro:~/src/python/bzrbzr upgrade --1.9.rich-root bzr: ERROR: no such option: --1.9.rich-root Do I need to downgrade to 1.9? No, sorry, that was a typo on my part. Try --1.9-rich-root Also, 'bzr help upgrade' Ach. I looked at an example of running the command I found on the web and didn't see the typo. I'd probably have spotted it if I'd checked the help :(. Upgrade running now, I'll report back after I try the push again. -- R. David Murray http://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] BZR mirror and pushing to Launchpad
On Mon, 9 Mar 2009 at 11:23, R. David Murray wrote: On Mon, 9 Mar 2009 at 10:49, Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- On Mar 9, 2009, at 10:48 AM, R. David Murray wrote: On Mon, 9 Mar 2009 at 09:30, Barry Warsaw wrote: On Mar 9, 2009, at 9:02 AM, R. David Murray wrote: On Mon, 9 Mar 2009 at 08:15, Barry Warsaw wrote: Perhaps RDM branched from code.python.org before I upgraded the repository format to 1.9-rich-root? I grabbed the tarball and made my initial branch on 2/20, from python.org. Then I branched from that to make the branch I pushed to Launchpad. Could the second branch be the problem? I just did 'bzr branch trunk trunk-myfix'. I upgraded the repository on 2/25, so it's possible your older tarball is the problem. try running 'bzr upgrade --1.9.rich-root' on it and see if that allows you to stack on Launchpad. Hmm. My client is 1.12, and it says: rdmur...@maestro:~/src/python/bzrbzr upgrade --1.9.rich-root bzr: ERROR: no such option: --1.9.rich-root Do I need to downgrade to 1.9? No, sorry, that was a typo on my part. Try --1.9-rich-root Also, 'bzr help upgrade' Ach. I looked at an example of running the command I found on the web and didn't see the typo. I'd probably have spotted it if I'd checked the help :(. Upgrade running now, I'll report back after I try the push again. OK, that fixed it. New push is properly stacked. Thanks everyone, especially Barry. -- R. David Murray http://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] PEP 239 - Rational
On Sun, Mar 8, 2009 at 11:41 PM, Lie Ryan lie.1...@gmail.com wrote: PEP 239 says that Rational type was Rejected, but some time ago this decision is reverted, and now python 3.0 and python 2.6 includes a fractions.Fraction type. Shouldn't this PEP be updated? (At least to include a note of its obsoleted status or to point to the reversion) Good idea. I've added a reference to PEP 3141 mentioning the Rational ABC and the fractions module. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0 grammar ambiguous?
To be honest I wasn't aware of this ambiguity. It seems that whoever
wrote the patch for argument unpacking (a, b, *c = ...) got lucky
with an ambiguous grammar. This surprises me, because IIRC usually
pgen doesn't like ambiguities. Other parser generators usually have
some way to deal with ambiguous grammars, but they also usually have
features that make it unnecessary to use the exact same grammar as
pgen -- for example, most parser generators are able to backtrack or
look ahead more than one token, so that they can distinguish between
a = b and a once the '=' token is seen, rather than having to
commit to parse an expression first.
JavaCC can actually do that, but in the current construct, the
ambiguity is not dependent on a lookahead, because both '*' test and
star_expr will match it equally well -- because they're actually the
same thing grammar-wise (so, there's no way to disambiguate without a
semantic handling later on)
After taking a 2nd look, I think that probably the best solution would
be creating a new testlist to be used from the expr_stmt -- something
like testlist_start_expr.
E.g.:
testlist: test (',' test)* [',']
testlist_star_expr: [test | star_expr] (',' [test | star_expr])* [',']
And also, star_expr could probably be just
'*' NAME
(to make it faster to match -- or could it match something else?)
Note that I still haven't tested this -- I'll have time to do it
tomorrow on my JavaCC grammar (so, I can give you a better feedback if
this actually works).
Ok, I've created a bug for that at: http://bugs.python.org/issue5460
and commented on a solution (and just to note, star_expr could match
b, *a.a = [1,2,3], so, it cannot be changed for NAME)
The solution is working for me, and it should be straightforward to
apply it to Python.
Regards,
Fabio
___
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] draft 3.1 release schedule
Benjamin Peterson wrote: You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ Please add auto-numbered replacement fields in str.format() strings http://bugs.python.org/issue5237 Guido wrote today Please go ahead and finish this. I'm glad this is going in! Eric Smith says he should have a final patch ready by the end of PyCon or so. ___ 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] Integrate BeautifulSoup into stdlib?
On Thu, Mar 05, 2009 at 01:30:25PM -0500, Barry Warsaw wrote: Ubuntu (and probably Debian): apt-get install python-lxml Tested in Debian: yes, the incantation works. Oleg. -- Oleg Broytmannhttp://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] draft 3.1 release schedule
2009/3/9 Terry Reedy tjre...@udel.edu: Benjamin Peterson wrote: You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ Please add auto-numbered replacement fields in str.format() strings http://bugs.python.org/issue5237 Done. -- 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] Regexp 2.7
2009/3/7 Antoine Pitrou solip...@pitrou.net: Matthew Barnett has been doing a lot of work on the regular expressions engine (it seems he hasn't finished yet) under http://bugs.python.org/issue2636. However, the patches are really huge and touch all of the sre internals. I wonder what the review process can be for such patches? Is there someone knowledgeable enough to be able to review them? All test cases run ok? How well covered is that library? Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Regexp 2.7
Facundo Batista facundobatista at gmail.com writes: Matthew Barnett has been doing a lot of work on the regular expressions engine (it seems he hasn't finished yet) under http://bugs.python.org/issue2636. However, the patches are really huge and touch all of the sre internals. I wonder what the review process can be for such patches? Is there someone knowledgeable enough to be able to review them? All test cases run ok? How well covered is that library? I don't know, I haven't even tried it. 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
[Python-Dev] reviewing patches
Hi all, I have seen it said that one very useful activity is reviewing patches. Of the issues in the tracker, it is not immediately clear to me what is required of such a review. Many of these patches appear to be bundled in with feature requests, leaving the question of whether the review it judging the quality of the code or the merits of the feature request. I do realise that these issues have probably been previously discussed on this list. Let's take as an example the following issue: http://bugs.python.org/issue1818 This has obviously been around for a while, but not been implemented for some reason. There are no links in any of the comments to any email threads regarding its merits, however I recognise the name of the submitter. This makes me think the patch is probably implementing desirable functionality. However, it has no priority set, which makes me think that the community hasn't yet given it any kind of 'status', insofar as a priority can stand in for desirability. It seems to make sense that code quality reviews should be separated from feature request reviews (quality code evaluation vs desirability of function evaluation) but I don't see how this occurs. I feel a lot more qualified to evaluate code quality than desirability of function. Questions like this make it difficult for someone in my position, who is happy to tackle 'whatever needs to be done', to begin the task of patch reviews. While I'm not sure that a formal or semi-formal approval process would make anything better, I think it would be good if there were some kind of 'executive review' process by which an issue could be marked as being a good thing or not. Regards, -Tennessee -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; http://bugs.python.org/issue4847 Not yet fixed. Needs: * Decision about the correct fix (I think it will involve an API change). * Test case and a patch. * Probably small documentation changes as well. I'm wiped out this evening. I'll try to look into it, but I suspect it might require a bit more time than I have in the next day or two. 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] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; Bob Ippolito has a good sized patch to update the json module and improve its performance. http://bugs.python.org/issue4136 Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/3/9 Raymond Hettinger pyt...@rcn.com: You might also want to collect a list of serious changes that you want in this release; Bob Ippolito has a good sized patch to update the json module and improve its performance. http://bugs.python.org/issue4136 ...and it's already on the PEP. :) -- 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] draft 3.1 release schedule
2009/3/9 s...@pobox.com: You might also want to collect a list of serious changes that you want in this release; http://bugs.python.org/issue4847 Not yet fixed. Needs: * Decision about the correct fix (I think it will involve an API change). * Test case and a patch. * Probably small documentation changes as well. I'm wiped out this evening. I'll try to look into it, but I suspect it might require a bit more time than I have in the next day or two. That seems important, but quite serious enough to warrant inclusion in the PEP. (and not a feature) If you'd like it to block the release, you can set the priority to release blocker. -- 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] reviewing patches
I have seen it said that one very useful activity is reviewing patches. Of the issues in the tracker, it is not immediately clear to me what is required of such a review. Many of these patches appear to be bundled in with feature requests, leaving the question of whether the review it judging the quality of the code or the merits of the feature request. That's correct. I do realise that these issues have probably been previously discussed on this list. Let's take as an example the following issue: http://bugs.python.org/issue1818 This is somewhat of a special case, as the original submission is from a committer (Raymond). If he would feel like it, he could commit it at any time. That he didn't is probably because he is uncertain himself. This has obviously been around for a while, but not been implemented for some reason. There are no links in any of the comments to any email threads regarding its merits This likely means there hasn't been any email communication. This is common; often discussion is carried out entirely in the tracker (and if you aren't on the nosy list of the issue, you will miss the discussion completely) This makes me think the patch is probably implementing desirable functionality. However, it has no priority set, which makes me think that the community hasn't yet given it any kind of 'status', insofar as a priority can stand in for desirability. No. It means that the classification fields are often completely ignored, both by submitters and reviewers. It seems to make sense that code quality reviews should be separated from feature request reviews (quality code evaluation vs desirability of function evaluation) but I don't see how this occurs. Most likely, the functionality itself is uncontested. This is typically because a) some reviewers agreed that the functionality is desirable, and b) some reviewers didn't consider the possibility of questioning the functionality, and c) some possible opponents are unaware of the discussion in the first place. I feel a lot more qualified to evaluate code quality than desirability of function. I think it is fairly straight-forward to ask that you can access the fields of a CSV list by field name, rather than by index; I would take that as granted. Notice that much of the discussion is about fine points of the API, which is an indication that the actual design of the functionality is tricky, not just the implementation. It would be helpful to be a heavy CSV user to understand all aspects, and to evaluate usefulness of a specific API. Questions like this make it difficult for someone in my position, who is happy to tackle 'whatever needs to be done', to begin the task of patch reviews. I recommend that you look at patches with no long discussions - things that did not get any attention at all so far. Issues that have already long discussions typically are inherently difficult, and its not always clear that another reviewer will be able to progress the issue - unless he happens to be an export on the matter, such as Alexander for knots on ox carts. While I'm not sure that a formal or semi-formal approval process would make anything better, I think it would be good if there were some kind of 'executive review' process by which an issue could be marked as being a good thing or not. If you think creating more keywords would help, please feel free to propose some. If it is more status values, or more whatever - likewise. All of these are cheap to create. 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] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; I'm making minor updates to the decimal module to match the 1.68 version of the spec. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
I'm making minor updates to the decimal module to match the 1.68 version of the spec. Looks like most was already done. Just needs some doc fixes. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on Py3K urllib -- urlencode()
Yes, that was a good idea. I found some problems, and attached a new version. It looks more complicated than I wanted, but it is a very regular repetition, so I hope it is generally readable. I used doctest to include the test scenarios. I was not familiar with it before, but it seems to work quite well. The main snag I hit was that I had to jazz around with the escape sequences (backslashes) in order to get the doc string to go in properly. That is, the lines in the string are not the lines I typed at the command prompt, as Python is interpreting the escapes in the strings when the file is imported. In an effort to make fewer tests, the lines of the test strings grew pretty long. I'm not sure if I should try to cut the lengths down or not. Any suggestions would be welcome before I try to submit this as a patch. - Dan Bill Janssen wrote: Aahz a...@pythoncraft.com wrote: On Sat, Mar 07, 2009, Dan Mahn wrote: After a harder look, I concluded there was a bit more work to be done, but still very basic modifications. Attached is a version of urlencode() which seems to make the most sense to me. I wonder how I could officially propose at least some of these modifications. Submit a patch to bugs.python.org And it would help if it included a lot of test cases. Bill from urllib.parse import quote_plus import sys def urlencode(query, doseq=0, safe='', encoding=None, errors=None): Encode a sequence of two-element tuples or dictionary into a URL query string. If any values in the query arg are sequences and doseq is true, each sequence element is converted to a separate parameter. If the query arg is a sequence of two-element tuples, the order of the parameters in the output will match the order of parameters in the input. urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (1, 2), (a:, b$))) '%C2%A0=%C3%81%A0%24=%C1%241=2a%3A=b%24' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (1, 2), (a:, b$)), safe=:$) '%C2%A0=%C3%81%A0$=%C1$1=2a:=b$' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (1, 2), (a:, b$)), encoding=latin=1) '%A0=%C1%A0%24=%C1%241=2a%3A=b%24' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (1, 2), (a:, b$)), safe=$:, encoding=latin=1) '%A0=%C1%A0$=%C1$1=2a:=b$' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (d:, 0xe), (1, (b, b'\\x0c\\x24', 0xd, e$))), 1) '%C2%A0=%C3%81%A0%24=%C1%24d%3A=141=b1=%0C%241=131=e%24' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (d:, 0xe), (1, (b, b'\\x0c\\x24', 0xd, e$))), 1, safe=:$) '%C2%A0=%C3%81%A0$=%C1$d:=141=b1=%0C$1=131=e$' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (d:, 0xe), (1, (b, b'\\x0c\\x24', 0xd, e$))), 1, encoding=latin-1) '%A0=%C1%A0%24=%C1%24d%3A=141=b1=%0C%241=131=e%24' urlencode(((\\u00a0,\\u00c1), (b'\\xa0\\x24', b'\\xc1\\x24'), (d:, 0xe), (1, (b, b'\\x0c\\x24', 0xd, e$))), 1, safe=:$, encoding=latin-1) '%A0=%C1%A0$=%C1$d:=141=b1=%0C$1=131=e$' urlencode(((\\u00a0, \\u00c1),), encoding=ASCII, errors=replace) '%3F=%3F' urlencode(((\\u00a0, (1, \\u00c1)),), 1, encoding=ASCII, errors=replace) '%3F=1%3F=%3F' if hasattr(query,items): # mapping objects query = query.items() else: # it's a bother at times that strings and string-like objects are # sequences... try: # non-sequence items should not work with len() # non-empty strings will fail this if len(query) and not isinstance(query[0], tuple): raise TypeError # zero-length sequences of all types will get here and succeed, # but that's a minor nit - since the original implementation # allowed empty dicts that type of behavior probably should be # preserved for consistency except TypeError: ty,va,tb = sys.exc_info() raise TypeError(not a valid non-string sequence or mapping object).with_traceback(tb) l = [] if not doseq: # preserve old behavior for k, v in query: if isinstance(k, bytes): k = quote_plus(k, safe) else: k = quote_plus(str(k), safe, encoding, errors) if isinstance(v, bytes): v = quote_plus(v, safe) else: v = quote_plus(str(v), safe, encoding, errors) l.append(k + '=' + v) else: for k, v in query: if isinstance(k, bytes): k = quote_plus(k, safe) else: k = quote_plus(str(k), safe, encoding, errors) if isinstance(v, str): v = quote_plus(v, safe, encoding, errors) l.append(k + '=' + v) elif isinstance(v, bytes): v = quote_plus(v, safe)
[Python-Dev] Addition of further status options to tracker
Hi all, I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a '+'): Open: Means that the issue has been created and not further reviewed + Request Approved: Means that the issue is marked as worth further development by the community + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms) + Under Development: Means that an implementation is currently under development Pending Feedback: Means that work is suspended pending feedback + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value) My reasoning for this is as follows: Example one: I am currently reviewing issue 2706 which covers datetime.timedelta operators. I have a reasonable amount of familiarity with time programming and think I have some valuable input on the functionality aspects, however I'm not a super-great C programmer. I'd like to help with coming up with the final feature specification, but then leave it to others to consider the merits of the C code patch. Being able to help get this marked as request approved, then specification approved might help speed up a lot of the process of developing the patch and getting it accepted. It also saves code developers from having to develop an implementation while a functionality debate is still ongoing... I think that having these additional steps will help to avoid erroneous development of non-features, and also break up the review process into more manageable chunks of work. Of course I realise not everything needs such a delineated process, but by the same token it might assist in keeping some of the less visible/popular changes moving through the process... Comments welcome! Crocker's rules, but please keep it constructive... -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] reviewing patches
Martin v. Löwis wrote: I have seen it said that one very useful activity is reviewing patches. Of the issues in the tracker, it is not immediately clear to me what is required of such a review. Many of these patches appear to be bundled in with feature requests, leaving the question of whether the review it judging the quality of the code or the merits of the feature request. Both may be needed, depending on the issue. But see below. That's correct. I do realise that these issues have probably been previously discussed on this list. Let's take as an example the following issue: http://bugs.python.org/issue1818 Briefly, as I read it: Raymond proposed that his named tuples be used with Barry and Skip's csv module. He got a short reply from Skip but went on to other things. A year later, two new people entered and energized the discussion, Barry said 'useful', Skip commented on the details. The second half of the discussion has been thrashing out and getting consesus on the devilish details. What is devilish is that the merits of feature details sometimes interacts with code quality. This is pretty typical. It looks to me like this will be in 3.1. often discussion is carried out entirely in the tracker (and if you aren't on the nosy list of the issue, you will miss the discussion completely) Every Friday a list of opened and closed issues is posted. Even if you have nothing to say, you can add yourself to the nosy list. I feel a lot more qualified to evaluate code quality than desirability of function. Good, in the sense that I believe the former is rarer and more needed. There are 5 broad areas covered in the tracker: 1. C code, interpreter core 2. C code, extension modules 3. Python code, modules 4. Tests of the above 5. Documentation of above Where to start? What interests you most? Or look at the thread draft 3.1 release schedule and posts giving features aimed at 3.1. For instance, http://bugs.python.org/issue5237 has a new C patch that could use at least a preliminary eyeball, pending the more polished patch. Help adding the test patches would be welcome by me and, I am sure, by Eric. 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] Addition of further status options to tracker
On Tue, Mar 10, 2009 at 2:39 PM, Brett Cannon br...@python.org wrote: On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg tleeuwenb...@gmail.com wrote: Hi all, I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a '+'): Open: Means that the issue has been created and not further reviewed + Request Approved: Means that the issue is marked as worth further development by the community + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms) + Under Development: Means that an implementation is currently under development Pending Feedback: Means that work is suspended pending feedback + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value) I assume you want all of this for the Status field, correct? As for the options, some of these overlap with the Stage field. For instance, if something has been set to any stage other than accepted/rejected it means it needs to be looked into, so that duplicates your Request Approved status. Similar thing with the review stages and Under Final Review. But a general under development status would probably be worth adding. That way if an issue is open it needs attention, Under development means someone is working on a solution, pending means someone is blocking the issue for more information, and closed means closed. One thing to watch out for, Tennessee, is getting too specific. Like your Request Approved and Specification Approved just seems too heavy-handed to my tastes. Personally, I prefer to make sure the issue workflow to be somewhat simple so that people don't end up arguing over stuff like whether something has been specified well enough to have it set to Spec Approved even if someone else disagrees (which you know would happen). -Brett Hi Brett, Some great points. The stage settings do overlap a lot of what I had suggested. What I'm trying to reach is a way to flag quite clearly whether a tracker issue is: * In need of a first response * Being taken care of by someone * Needs the attention of core developers, just about ready At the moment, the open/closed settings are a bit useless -- issues are Open until they are finished, at which point they are Closed. I personally suspect that Pending feedback is little-used. At the moment, many Open issues are in various states of maturity or disrepair, so the only really useful information is whether an issue is Closed. Examining the stage options more closely, they are very code-oriented. Really they relate to implementation, not other parts of the process. It's difficult for me as someone who wants to help out with the Issue resolution process as much as coding to take an atomic action to help advance the issue through a process. What do you think about the following Status flags: * Open: Means newly-created, needs early attention * + Request for Comment: Means that a discussion regarding functionality is requested * + Under Development: Means that a caring developer is taking care of it * Pending Feedback: blocking on new information * Closed: Means closed Once the issue is marked as under development, more information is then provided by the Stage flag. Request for Comment means that anyone who is stuck on trying to get their ideas sorted or a loose specification agreed on can call for feedback through this flag. There's still some risk of arguments blocking the progression to Under development, but the issue owner can at least pass to Under development at their own will without requiring universal agreement. Core developers can then search on 'commit review' or 'patch review' to see what could use their attention, while people who are happy to contribute to the debate can search on Open and Request for Comment issues. Obviously the RFC flag is redundant when an issue is first raised, since the submitter always has the option of simply emailing this list. However, for older, potentially stale issues, it is a useful indicator that the issue may be either closed out or could use refreshing. I don't mind what approach is taken -- I'm happy to work within the current infrastructure if someone can suggest a good way. I really just want to be able to start distinguishing between issues that are essentially new and under debate versus issues that most people agree are a Good Thing To Do, and then helping those issues advance to the point of implementation by discussing and, if necessary, formalising or recording requirements against them. Regards, -Tennessee --
Re: [Python-Dev] Addition of further status options to tracker
Hi Tennessee, I plan to take a look at all open issues before PyCon, do you want to join forces? :) Tennessee Leeuwenburg wrote: I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a '+'): Great! Thanks a lot :) I think your ideas are good, but believe you should take a better look at the Stages, some messages from this list and tracker-discuss from February, and Brett's document linked from there. + Request Approved: Means that the issue is marked as worth further development by the community Not sure it's a 'status', but I like the idea of disambiguating between 'send us tests/patches so we can think whether the bug/feature is valid' and 'the bug/feature is valid, send us tests/patches'. However, it might be better to merge this with 'Specification Approved', as the important bit is 'contributions on this are welcome'. + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms) See above. +1 on a way to make this clear, -0 on it being separate from the above, -1 on being a status. + Under Development: Means that an implementation is currently under development This one I like a lot, but think it should be a keyword, like 'claimed'. I think it should be set when someone says I'll work on this one. But if you mean 'should be under development', -1 :) + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process -1, as it is rather redundant with Stage. [...] My reasoning for this is as follows: Example one: I am currently reviewing issue 2706 which covers datetime.timedelta operators. I have a reasonable amount of familiarity with time programming and think I have some valuable input on the functionality aspects, however I'm not a super-great C programmer. I'd like to help with coming up with the final feature specification, but then leave it to others to consider the merits of the C code patch. Being able to help get this marked as request approved, then specification approved might help speed up a lot of the process of developing the patch and getting it accepted. It also saves code developers from having to develop an implementation while a functionality debate is still ongoing... You can provide unit tests (and perhaps an equivalent Python implementation), they are a great way to specify behavior. Also, they are required for a healthy commit and make the corner cases easier to spot. I think that having these additional steps will help to avoid erroneous development of non-features, and also break up the review process into more manageable chunks of work. I think core developers shouldn't waste time setting a hundred little fields on each issue, but giving them practical ways to query (and denote) these extended properties seems worthwhile. Of course I realise not everything needs such a delineated process, but by the same token it might assist in keeping some of the less visible/popular changes moving through the process... Well, there's the signal-to-noise ratio to consider too. Like with the nosy_count noise issue, things might get in the way of developers work (I'll work on this soon, promise :D). I'll be doing some janitorial tasks this week and next, triaging issues and populating their fields. If you want to discuss specific changes or suggest different methods/goals/rules for this work, I'd be very grateful. If you want to join the tracker janitors club, remember to bring a shrubbery :) Regards, Daniel ___ 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] Addition of further status options to tracker
Brett Cannon wrote: On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg tleeuwenb...@gmail.com mailto:tleeuwenb...@gmail.com wrote: Hi all, I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a '+'): Open: Means that the issue has been created and not further reviewed + Request Approved: Means that the issue is marked as worth further development by the community + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms) + Under Development: Means that an implementation is currently under development Pending Feedback: Means that work is suspended pending feedback + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value) I assume you want all of this for the Status field, correct? As for the options, some of these overlap with the Stage field. For instance, if something has been set to any stage other than accepted/rejected it means it needs to be looked into, so that duplicates your Request Approved status. Similar thing with the review stages and Under Final Review. But a general under development status would probably be worth adding. That way if an issue is open it needs attention, Under development means someone is working on a solution, pending means someone is blocking the issue for more information, and closed means closed. I like this. Open would mean that triage is still needed: reject and close (or provisionally reject 'pending'), fix and close, or move to 'under developemnt. One thing to watch out for, Tennessee, is getting too specific. Like your Request Approved and Specification Approved just seems too heavy-handed to my tastes. Personally, I prefer to make sure the issue workflow to be somewhat simple so that people don't end up arguing over stuff like whether something has been specified well enough to have it set to Spec Approved even if someone else disagrees (which you know would happen). The other problem with too many specifics is non-use. As it is, an issue is sometimes closed with no resolution marked, so one has to scroll down, possibly a long way, to see whether it was accepted or rejected. (Is it possible to require a resolution when closing?) Terry ___ 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] Addition of further status options to tracker
Terry Reedy wrote: The other problem with too many specifics is non-use. As it is, an issue is sometimes closed with no resolution marked, so one has to scroll down, possibly a long way, to see whether it was accepted or rejected. (Is it possible to require a resolution when closing?) Yes, it is possible. If you think it should be implemented, file a RFE in the meta tracker. However, it'll also be much easier to mass-edit issues in the near future, so if this kind of (careful) cleanup can be done by tracker janitors later, it might be best to leave core developers free of these requirements... Soon we'll also have the option of marking an issue as Pending and having it automatically closed some time later. Daniel ___ 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] More on Py3K urllib -- urlencode()
On Mon, Mar 09, 2009, Dan Mahn wrote: Any suggestions would be welcome before I try to submit this as a patch. Just go ahead and submit it now; it's easier to review patches when they're in the system, and it also makes sure that it won't get lost. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ All problems in computer science can be solved by another level of indirection. --Butler Lampson ___ 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] reviewing patches
On Mon, Mar 9, 2009 at 20:55, Terry Reedy tjre...@udel.edu wrote: Martin v. Löwis wrote: I have seen it said that one very useful activity is reviewing patches. Of the issues in the tracker, it is not immediately clear to me what is required of such a review. Many of these patches appear to be bundled in with feature requests, leaving the question of whether the review it judging the quality of the code or the merits of the feature request. Both may be needed, depending on the issue. But see below. That's correct. I do realise that these issues have probably been previously discussed on this list. Let's take as an example the following issue: http://bugs.python.org/issue1818 Briefly, as I read it: Raymond proposed that his named tuples be used with Barry and Skip's csv module. He got a short reply from Skip but went on to other things. A year later, two new people entered and energized the discussion, Barry said 'useful', Skip commented on the details. The second half of the discussion has been thrashing out and getting consesus on the devilish details. What is devilish is that the merits of feature details sometimes interacts with code quality. This is pretty typical. It looks to me like this will be in 3.1. often discussion is carried out entirely in the tracker (and if you aren't on the nosy list of the issue, you will miss the discussion completely) Every Friday a list of opened and closed issues is posted. Even if you have nothing to say, you can add yourself to the nosy list. I feel a lot more qualified to evaluate code quality than desirability of function. Good, in the sense that I believe the former is rarer and more needed. There are 5 broad areas covered in the tracker: 1. C code, interpreter core 2. C code, extension modules 3. Python code, modules 4. Tests of the above 5. Documentation of above This is somewhat covered by components, but it's implicit. Would it be worth making this explicit? I have always wondered if people would be more willing to help out if they could easily search for pure Python code issues if that is as far as they feel comfortable. We could then have the components merge into keywords or just take out the implicit type of issue part. Or we just don't worry about auto-assignment. I think Georg is the only one getting auto-assignment and I think we all know to assign him doc stuff. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Review of Issue http://bugs.python.org/issue2706, timedelta operators
Hi all, I'm just trying to find my feet with regards to the proper process for reviewing. I'm not sure what's best: * Post the review as a comment on the associated issue. Only nosies will be updated. * Post the review as a comment on the issue, then post a one-line information update to this list * Post the review to this list for consideration * other http://bugs.python.org/issue2706 General topic: Math operations on timedelta objects Last activity: 12 Dec 08 Original owner: webograph This issue covers a number of discrete functional changes. I here review each in turn: 1) Allow truediv, the operator '/', to be applied to two timedeltas (e.g. td1 / td2). The return value is a float representing the number of times that td2 goes into td1. Evaluation: Since both time deltas are quantitative values of the same unit, it makes sense they should be able to support basic math operations. In this case, operation to be added is '/' or truediv. I would personally find this functionality useful, and believe it is a natural addition to the code. Recommendation: That this functionality be recommended for development 2) Allow truediv to be applied to a timedelta and an int or float. The return value is a timedelta representing the fractional proportion of the original timedelta. Evaluation: This makes total sense. Recommendation: That this functionality be recommended for development 2) Allow divmod, the operator '%', to be applied to two timedeltas (e.g. td1 % td2). I think there is some debate here about whether the return value be an integer in microsends, or a timedelta. I personally believe that a timedelta should be returned, representing the amount of time remaining after (td1 // td2) * td2 has been subtracted. The alternative is an integer, but due to a lack of immediate clarity over what time quanta this integer represents, I would suggest returning a unit amount. There is also some discussion of returning (long, timedelta), but I personally fail to see the merits of returning the long without some unit attached. 3) Allow divmod, the operator '%', to be applied to a timedelta and an integer or float. (e.g. timedelta % 3). I'm not quite as sold on this. I suggest that more discussion is required to flesh this out further. A patch has been attached which implements some of this behaviour. I would suggest that it's valuable to start doing this work in discrete chunks so that progress can be begun before the issues under debate are resolved. I suggest that it would be appropriate to create three smaller issues, each tackling just one piece of functionality. This should make the changes more atomic and the code patch simpler. -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] Addition of further status options to tracker
I don't mind what approach is taken -- I'm happy to work within the current infrastructure if someone can suggest a good way. I really just want to be able to start distinguishing between issues that are essentially new and under debate versus issues that most people agree are a Good Thing To Do, and then helping those issues advance to the point of implementation by discussing and, if necessary, formalising or recording requirements against them. I have always viewed it that if Stage is set to anything other than its empty default it is worth looking into. But it seems to me what you are after is some obvious way to disambiguate issues that are feature requests that someone has just asked for and anyone can work on if they want, and issues that require attention, i.e. bugs and patches. Is that accurate? Pretty much. I've got two views. One is that I'd like to search for issues that are up for grabs which I could take over, hack on, and generally not get underfoot of core development activity. The other is that I think I can help with issue gardening -- splitting issues up into those which still need some more thought, those which someone should pick up and start working on, etc. * Ideas needing more consideration * Ideas being hotly debated * Good ideas with no owning developer * Ideas currently under initial development * Ideas ready for consideration by the core developers In order to make the most use of experienced developers, I'd say it's important that they spend most of their time concentrated at the bottom of that list. Bugs and patches more or less automatically qualify for that, and they can be searched on pretty effectively now. However, doing gardening on the issues which aren't quite there yet is currently pretty clumsy. Say I'm a core developer and very busy. I'd like to quickly address bugs if possible, and I'm happy to help out on important new issues. I certainly don't want to trawl through a whole lot of immature issues and do the triage myself -- what a waste of time! Right now, what can such a person search on to find the relevant issues? It looks like patch review or commit review will do nicely. This isn't going to change, so that is still supported. Bugs are essentially everything not a feature request, so that doesn't change either. Okay, so the developer workflow is simple and supported. But what about pre-core development workflow? How about for those involved in performing triage and specification? Where I work, at least 50% of the time is spent just working out what to do. There's a lot of real work in triage and specification, and it really shouldn't be done by core developers who could be churning out shiny new stuff. That means that the triage team (or issue janitors) need to be able to support a workflow this is pretty easy on them, too. At this stage, we're not dealing with code, we're just dealing with problems. If we want people with great ideas to get to the top of the heap quickly, we need some way to facilitate that, while issues that are either inappropriate or being hotly contested don't suck time away from more important things. Anyway, I really do just want to fit in. I'm just butting into some workflow things which seem a bit clumsy when doing issue gardening or when finding coding tasks that are up for grabs for a python-dev newbie... Cheers, -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
