Re: [Python-Dev] Should we move to replace re with regex?
On 2011-08-27, at 2:20 PM, Dan Stromberg wrote: On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.com wrote: On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote: No, this was not the intent of __future__. The intent is that a feature is desirable but also backwards incompatible (e.g. introduces a new keyword) so that for 1 (sometimes more) releases we require the users to use the __future__ import. There was never any intent to use __future__ for experimental features. If we want that maybe we could have from __experimental__ import whatever. OK. So what -is- the purpose of from __future__ import? It's in the first paragraph. I disagree. The first paragraph says this has something to do with new keywords. It doesn't appear to say what we expect users to -do- with it. Both are important. Is it You'd better try this, because it's going in eventually. If you don't try it out before it becomes default behavior, you have no right to complain? And if people do complain, what are python-dev's options? __future__ imports have nothing to do with trying stuff before it comes, it has to do with backward compatibility. For example, the with_statement was a __future__ import because introducing the with keyword would break any code using with as a token. I don't think that the goal of introducing with as a future import was we're gonna see how it pans out, and decide if we really introduce it later. __future__ means It's coming, prepare your code. ___ 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] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011-02-01, at 4:51 PM, anatoly techtonik wrote: I'll abandon my efforts when you prove me that current documented process is a top-notch way for all interested parties to do a quality contributions to make Python better. So that the process is open, straightforward, transparent and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate. There are many ways for improvement, but if people won't try alternative approaches, they won't see them. I am not sure if I can manage to get to PyCon, so I didn't do any talk preparation, but if by chance I get there and there will be an Open Space, we can definitely find a lot of ways to improve Python development process for general public. As well as discuss ways to get around stdlib graveyard and dealing with really complicated problems that won't budge over the years - like out of the box UTC support. The most valuable contributions are coming from professionals, and these people often don't have enough time to follow documented process. In the era of information abundance you often have only 140 symbols to communicate the idea, and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated. So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with. The problem is to keep non-core people outside motivated, and the biggest problem with current documented process is that nobody even thinks about it. It's nice to see that you want to improve the tracker. I'm happy to point you to the appropriate place for such proposals: http://psf.upfronthosting.co.za/roundup/meta/ The mailing list about the tracker is: http://mail.python.org/mailman/listinfo/tracker-discuss As for the mailing list/patch proposal, I think you should drop it. It's been made abundantly clear, by people much more knowledgable about the dev process of Python than you, why it can't work. Also, not being keen on following the documented process is a good indication, IMHO, of unprofessionalism. -- Virgil Dupras ___ 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] API refactoring tracker field for Python4
On 2011-01-07, at 7:14 PM, anatoly techtonik wrote: Don't you think that if people could review issues and star them then such minor issues could be scheduled for release not only by severity status as decided be release manager and several core developers, but also by community vote? Patch requires time, experience and approved contribution agreement, which you've sent using ground mail beforehand. Voting doesn't require any of this, but helps core developers see what user community wants. With the list of desired features Jesse Noller sponsored sprints will have more value for all of us. Two things. First, technically, the bug tracker already has stars. It's the nosy list. You can even run a search by nosy count. Second, I'm not sure starring matters that much. Ultimately, for something to be done, you need a patch. Sure, sometimes, the patch is going to be made by someone who has no interest in it, but I think most of the time the patch is submitted by someone wanting the patch to be applied. I don't think the number of stars affect the likeliness of a patch being created very much. Maybe you can point to a google code project for which starring is used intensively and to observably good results? Virgil Dupras ___ 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] [issue8033] sqlite: broken long integer handling for arguments to user-defined functions
On 2011-01-05, at 8:16 AM, Phil Le Bienheureux wrote: Hello, I am quite new to development in python, and as a first contribution to the community, I have provided a patch to the issue 8033 (quite trivial). I then ran the test suite an everything was ok. However, the status has not changed, and nobody has answered so far (patch provided one month ago). So my question : has I missed something in the procedure that I read carefully, to deliver a patch, or something else? I'm not a core developer, but there's two reasons I can think of: 1. Your diff doesn't include tests. 2. Core developers are busy, these things take time. I don't think any bugfix gets checked in without a regression test to go with it. A core developer coming by your issue could maybe do it himself, but since he's likely very busy, he won't have time for this. So your best bet for this fix to be checked in is to add a test, but even then, sometimes, patches fade into oblivion and you might have to regularly freshen your diff to match with the trunk so it applies cleanly. Virgil Dupras ___ 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] Licensing
On Tue, Jul 6, 2010 at 9:22 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: That's the point: selling, and commercial activity in general, is explicitly encouraged and permission granted by the GPL. Too many people speak as though it were otherwise. To those who do: Please stop. Please, GPL advocates also spread their own type of FUD, claiming free as in speech ain't the same thing as free as in beer, people!. While true, the bottom line is that Python being BSD-type enables me to make money with it that I wouldn't make if Python was GPL-type. Moreover, I don't think that GPL license allows money-making that BSD type wouldn't allow. Hence the common point of view saying BSD-type is more commercial-friendly than GPL. I've written an article last year that, while it doesn't address this issue specifically, it touches it. http://www.hardcoded.net/articles/going_open_source.htm Virgil Dupras ___ 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] patch to make list.pop(0) work in O(1) time
On Wed, Jan 27, 2010 at 4:55 PM, Steve Howell showel...@yahoo.com wrote: --- On Wed, 1/27/10, John Arbash Meinel john.arbash.mei...@gmail.com wrote: From: John Arbash Meinel john.arbash.mei...@gmail.com Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time To: Steve Howell showel...@yahoo.com Cc: Guido van Rossum gu...@python.org, Nick Coghlan ncogh...@gmail.com, python-dev@python.org Date: Wednesday, January 27, 2010, 7:45 AM Right now the Python programmer looking to aggressively delete elements from the top of a list has to consider the tradeoff that the operation takes O(N) time and would possibly churn his memory caches with the O(N) memmove operation. In some cases, the Python programmer would only have himself to blame for not using a deque in the first place. But maybe he's a maintenance programmer, so it's not his fault, and maybe the code he inherits uses lists in a pervasive way that makes it hard to swap in deque after the fact. What advice do you give him? Or he could just set them to None. Fair enough, but that's still wasteful of memory, keeping around a bunch of None elements because you can't inexpensively delete them. I concede that you can break the dangling references, though, and that's often where large programs waste a lot of memory, so your point is well taken. Why is this thread still going? It seems to me that the case for this change is very weak. Lists, like dicts and tuples, are used *everywhere* and in *vast* quantities. Making them grow by 4 or 8 bytes each for such a corner case can't be an option. I'm sure your new list class has a lot of uses, but it should be an external class. If it stays close in behavior to the lists' behavior, then we could even add a notice in pop()'s documentation that recommends to use your new class in case they want a painless way to replace list usage (to make the life of those poor developers maintaining other people's code easier), maybe even add it in stdlib's collections unit. -- Virgil Dupras ___ 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] as keyword woes
On 06 Dec 2008, at 20:38, Warren DeLano wrote: Date: Fri, 05 Dec 2008 22:22:38 -0800 From: Dennis Lee Bieber [EMAIL PROTECTED] Subject: Re: as keyword woes To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] I'm still in the dark as to what type of data could even inspire the use of as as an object name... A collection of a objects? In which case, what are the as? G Please let me clarify. It is not as as a standalone object that we specifically miss in 2.6/3, but rather, the ability to use .as used as a method or attribute name. In other words we have lost the ability to refer to as as the generalized OOP-compliant/syntax-independent method name for casting: new_object = old_object.as(class_hint) # For example: float_obj = int_obj.as(float) # or float_obj = int_obj.as(float_class) # as opposed to something like float_obj = int_obj.asFloat() # which requires a separate method for each cast, or float_obj = (float)int_obj # which required syntax-dependent casting [language-based rather than object-based]. Of course, use of explicit casting syntax (float) is fine if you're restricting yourself to Python and other languages which support casting, but that solution is unavailable inside of a pure OOP message-passing paradigm where object.method(argument) invocations are all you have to work with. Please note that use of object.asClassname(...) is a ubiqitous convention for casting objects to specific classes (seen in ObjectiveC, Java, SmallTalk, etc.). There, I assert that 'object.as(class_reference)' is the simplest and most elegant generalization of this widely-used convention. Indeed, it is the only obvious concise answer, if you are limited to using methods for casting. Although there are other valid domain-specific uses for as as either a local variable or attribute names (e.g. systematic naming: as, bs, cs), those aren't nearly as important compared to as being available as the name of a generalized casting method -- one that is now strictly denied to users of Python 2.6 and 3. As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name object_name.as(...) must necessarily conflict with a standalone keyword as . It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. So, assuming I now wish to propose a corrective PEP to remedy this situation for Python 3.1 and beyond, what is the best way to get started on such a proposal? Cheers, Warren As long as as is widely known as a keyword, I don't see the problem. Every python developer knows that the convention is to add a trailing underscore when you want to use a reserved word in your code. Besides, your examples are quite abstract. I'm sure it's possible to find good examples for while, with, import, from (I often use from_) or try as well. Or perhaps that the python keywords should be as_ so we leave as free for eventual methods? As for the implicit proposition of allowing keywords only for methods, I agree with Guido about it being a slippery slope. So we would end up with a language where it is allowed to name methods after keywords, but not functions (they can be declared in the local scope)? Yikes! Oh well, maybe it's possible for an intelligent parser to distinguish between keywords and function references, but think of the poor grammar highlighters in all source editors! What a nightmare it will be for them. Anyway, is there any language that does this, allowing keywords as method names? I don't know, but if not, there's probably a reason for it. Your views on code elegance are also rather Javaish. I'd go for class_reference(object) (and why the heck would you be limited to using method for casting?). Ciao, Virgil ___ 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] Weak Dictionary Iteration Behavior in Python 3
I would also like to point out that I submitted a patch related to that a couple of months ago in: http://bugs.python.org/issue839159 But it never got any attention :( I'm not sure if it is still relevant. Virgil On 13-Sep-08, at 10:20 PM, Armin Ronacher wrote: Hi everybody, In Python 2.x when iterating over a weak key dictionary for example, the common idom for doing that was calling dictionary.keys() to ensure that a list of all objects is returned it was safe to iterate over as a weak reference could stop existing during dict iteration which of course raises a runtime error by the dict iterator. This was documented behavior and worked pretty well, with the small problem that suddenly all references in the dict wouldn't die until iteration is over because the list holds references to the object. This no longer works in Python 3 because .keys() on the weak key dictionary returns a generator over the key view of the internal dict which of course has the same problem as iterkeys in Python 2.x. The following code shows the problem:: from weakref import WeakKeyDictionary f1 = Foo() f2 = Foo() d = WeakKeyDictionary() d[f1] = 42 d[f2] = 23 i = iter(d.keys()) # or use d.keyrefs() here which has the same problem print(next(i)) del f2 print(next(i)) This example essentially dies with RuntimeError: dictionary changed size during iteration as soon as f2 is deleted. Iterating over weak key dictionaries might not be the most common task but I know some situations where this is necessary. Unfortunately I can't see a way to achieve that in Python 3. Regards, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/hsoft%40hardcoded.net ___ 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] Py3k DeprecationWarning in stdlib
Hi Devs, Today, I saw the Py3k beta 1 announcement, so I thought Well, I gotta do my duty and try to migrate my own code base to see if I can uncover any problems. I'm just at the step where I run my test suite with the -3 flag, and I noticed something peculiar: I get DeprecationWarning from stdlib code (namely, difflib, logging and unittest). Is it something to be expected or should I create tickets for those? I'm sure that the stdlib on the 3k side is fixed, but shouldn't the 2.6 side be fixed as well? Sorry if this question is already answered somewhere else, I searched for an answer but I couldn't find it. Additionally, one thing that strikes me as strange is how hard it is to find a Migration guide on the website. I had to dig in the PEP 3000 to find the brief bullet list telling me to run py26 with the -3 flag. Virgil Dupras ___ 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] Py3k DeprecationWarning in stdlib
On Tue, Jun 24, 2008 at 12:34 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Probably because nobody has stepped up to write a migration HOWTO yet... I'm not much of a writer, but once I'm finished with the migration, I'll do it (if it hasn't been done then). It's about time I try to learn reST... Virgil Dupras ___ 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] test_support.have_unicode
The test_support unit has this have_unicode. Do we need the Python's test unit to be *that* backward compatible? Is there still an implementation of Python that doesn't support unicode? If there is, should the test suite care? As a side question. Considering that I'm not sure whether have_unicode is relevant or not, is it more appropriate to create a ticket for it or to ask python-dev? Virgil Dupras ___ 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] Small RFEs and the Bug Tracker
On 2/23/08, Christian Heimes [EMAIL PROTECTED] wrote: We have over 1,700 open issues - bug reports, feature requests and patches - in our bug tracker. In my humble opinion it's a sure sign for a problem. There is also 12000 closed tickets, with 1200 of them having been closed in the last 6 months (well, having had activity in the last 6 month, but I guess that's almost equivalent). The number of issues (open or closed) that have been created in the last 6 months is about 1050. The flow seems healthy to me. Virgil ___ 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] Unit Test Guide
On 2/21/08, Nick Coghlan [EMAIL PROTECTED] wrote: Virgil Dupras wrote: On 2/21/08, Virgil Dupras [EMAIL PROTECTED] wrote: Hi devs, Being a python dev newbie, I look in http://www.python.org/dev/ for some guide to write unit tests in python and I can't find any. Specifically, I'd like to know about files managements in tests. Is every test expected to clean after itself, or is there an automatic cleanup mechanism in place? Even more specifically, I'd like to create a test for the proposed patch in http://bugs.python.org/issue2127 so I need to create a subdir with non-ascii character in it, then connect to a db in it. So, do I need to do the cleanup in the test? Is there a special path I can write to that will automatically be cleaned up? If not, wouldn't it be a good idea to have one? The tempfile module provides some useful tools for making individual files that clean themselves up, but individual tests are currently pretty much left to fend for themselves as far as cleaning up temporary directories. This can be done using the setUp/tearDown methods of the test case (as Giampaolo described), or more directly using context managers (that latter is obviously only common in tests added for 2.6/3.0) Something to consider would be to relocate the temp_dir() context manager from test_cmd_line_script [1] to test.test_support and use that. That context manager should be able to clean up for you no matter what you put in the temporary directory. The major downside of that approach is that test_support would end up depending on yet more modules being available for import (shutil and tempfile in this case), which isn't hugely desirable for test infrastructure). A way around that may be to guard the imports and define a dummy context manager that raises TestSkipped if either import fails. (If you do come up with a patch to relocate temp_dir(), put it up as a separate tracker item and add me to the nosy list for it) What do you people think about this issue I just opened? http://bugs.python.org/issue2156 ___ 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] Small RFEs and the Bug Tracker
On 2/21/08, Facundo Batista [EMAIL PROTECTED] wrote: This is the result for the open status issues? I guess not, because the rejected, fixed, etc, should be closed. Could you run this again, please, but filtering by open tickets? I don't see why would want to run this query on open tickets. What would it tell you? How many old issue there is? You can already know that with a simple search. The goal of this script is to know the resolution of tickets that had a 6+ month gap in their activity. Virgil ___ 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] Small RFEs and the Bug Tracker
On 2/19/08, Martin v. Löwis [EMAIL PROTECTED] wrote:
No, I don't, which is why I would find it interesting to run some
queries on the roundup database to have completion statistics for low
activity tickets. Is is possible to get a copy of that db somehow?
I would rather not make it available, as it contains certain
privacy-related information that we need to withhold. If you provide
some SQL statement or Python script that you want me to run on the
server - that should be possible.
Hum, Roundup has a rather nice little API to it's issues. Here we go.
It would be nice to have stats for 360 days as well.
#!/usr/bin/env python
# I'm building this out of a demo db of roundup, and it doesn't have a
Resolution, so
# I'm doing guesswork here. It shouldn't be very hard to modify the
script to fit the
# python db.
PATH_TO_TRACKER = 'demo'
ACTIVITY_DAY_THRESHOLD = 180
import roundup.instance
def has_large_activity_gap(issue, db):
for first, second in zip(issue.messages, issue.messages[1:]):
date1 = db.msg.getnode(first).date
date2 = db.msg.getnode(second).date
if date2.differenceDate(date1).as_seconds() =
ACTIVITY_DAY_THRESHOLD * 3600:
return True
return False
tracker = roundup.instance.Tracker(PATH_TO_TRACKER)
db = tracker.open()
closed_status = db.status.lookup('chatting')
resolution2count = {}
for resolution_id in db.resolution.getnodeids():
resolution2count[resolution_id] = 0
closed_issues = (db.issue.getnode(issue_id) for issue_id in
db.issue.find(status=closed_status))
low_activity_issues = (issue for issue in closed_issues if
has_large_activity_gap(issue, db))
for issue in low_activity_issues:
resolution2count[issue.resolution] += 1
print 'Low activity tickets (%d days) broken down per resolution
status:' % ACTIVITY_DAY_THRESHOLD
print
for resolution_id, count in resolution2count.items():
resolution = db.resolution.getnode(resolution_id)
print '%s\t%d' % (resolution.name, count)
___
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] Small RFEs and the Bug Tracker
On 2/18/08, Facundo Batista [EMAIL PROTECTED] wrote: Hi! Don't now if always, or in the last few months where I've been following the issues more closely, but I found that are appearing a lot of small RFEs in the tracker. These normally are small but not trivial things. In most cases when I read them I think Mmm, yes... it won't hurt to have it, but it's not so important, and definitively not my itch to scratch. See, for example, this [1] one, that ask for a factorial method in the integers. Normally these RFEs stay there for a long time, unless they're clearly negative, because they don't raise any discussion. OTOH, we have a PEP for feature requests [2]. I quote part of it: This PEP was created to allow us to close bug reports that are really feature requests. Marked as Open, they distract from the list of real bugs (which should ideally be less than a page). Marked as Closed, they tend to be forgotten. The procedure now is: if a bug report is really a feature request, add the feature request to this PEP; mark the bug as feature request, later, and closed; and add a comment to the bug saying that this is the case (mentioning the PEP explicitly). This is still valid? Should we start moving RFEs to this PEP and closing their issues in the tracker? Or should we try to get more discussion regarding these RFEs? Maybe, for example, a weekly digest where the latests RFEs added are sent to python-dev, so we can actually say no way and close them, or say nice and *then* moving them to the PEP (this has the risk of nobody saying anything, and to stay in the same position as before). What do you think? Opinions? Thank you very much! Regards, [1] http://bugs.python.org/issue2138 [2] http://www.python.org/dev/peps/pep-0042/ -- .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/hsoft%40hardcoded.net Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them. What I really think should be done is first to get rid of all these 8+ months old issues, and then have a kind of system that after 8 months, an issue goes back in dying mode where it surfaces back with a message Does anyone have any reason to believe this issue should still be alive? If there is no answer after a week, the issue is closed. -- Virgil ___ 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] Small RFEs and the Bug Tracker
On 2/18/08, Brett Cannon [EMAIL PROTECTED] wrote: On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc [EMAIL PROTECTED] wrote: Jeroen Ruigrok van der Werven wrote: -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote: Personally, I think that a bug tracker is a good place to keep RFE, not a PEP. I think that the PEP would tend to be cluttered with RFE nobody cares about forever. So the clutter can never be cleaned unless someone takes the responsibility to mercilessly remove them. A bug tracker is a much better way of registering such information. It also can be easier referenced in the future since even though when it is closed, the debate and other stuff will remain in the tracker's tickets for posterity. :) PEP: -1 tracker: +1 I agree. Then we can set some status/keyword when the subject of a RFE is accepted by core developers, saying if someone proposes a patch, it has a chance to be reviewed and applied. It may incite occasional contributors to work on some of these tasks, confident that their work will not be thrown away in two seconds. My issue with keeping the RFEs in the tracker as they are is that it artificially inflates the open issue count. Python does not have over 1,700 open bugs. So I have no issue with keeping the RFEs in the tracker, at some point I do want to change how they are represnted so that they are a separate things from issues representing bugs and patches. -Brett Which is why I propose to have a mechanism to close bugs and RFE nobody cares about. over *1000* out of those 1700 open issues are 6+ months old. Virgil ___ 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] Small RFEs and the Bug Tracker
On 2/18/08, Steve Holden [EMAIL PROTECTED] wrote: I'm not sure we should be throwing RFE's away with such casual abandon just because nobody had time to pay them any attention in six months - nor bugs neither, come to that. Well, we have to evaluate the chances of our older tickets to come to completion. I'm of the opinion that ticket getting older have very small chances of ever being completed. RFE for python 2.4 are likely to be irrelevant. old bugs are likely to already be fixed. Maybe we could run a statistical analysis to compute the chances of a ticket that have seen no activity for 8 months to ever be successfully completed? How many successful tickets to we have that had a 8+ months gap between activity? Or maybe we could just clean out the 400 tickets that are 2+ years old? What are the chances for a 2 years old ticket to be completed? -- Virgil ___ 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] Small RFEs and the Bug Tracker
On 2/19/08, Martin v. Löwis [EMAIL PROTECTED] wrote: Well, we have to evaluate the chances of our older tickets to come to completion. I'm of the opinion that ticket getting older have very small chances of ever being completed. RFE for python 2.4 are likely to be irrelevant. Do you have any facts to base this theory on? Two years for a bug report is *nothing*. Ten years, and I would start to worry that it might never get implemented. No, I don't, which is why I would find it interesting to run some queries on the roundup database to have completion statistics for low activity tickets. Is is possible to get a copy of that db somehow? Virgil ___ 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
