Re: [Python-Dev] Tracker archeology
Daniel (ajax) Diniz schrieb: > Over-spammig: > Sorry, Georg! I only noticed all issues in the Documentation > component are auto-assigned to you today. This meant dozens of unasked > for assignments :-/ That's okay, I'll go through them at the weekend and just unassign what I won't manage to do. But the nice thing about documentation changes is that while writing the change takes about as long as changing an equivalent piece of Python code, there's no new test and waiting for the testsuite needed (except sometimes a spellchecker wouldn't hurt), so it's much quicker :) Thank you for your efforts, they are much appreciated! Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] email package sprint?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The email package needs a lot of love, especially for Python 3.0. I'm already signed up for two sprints for Pycon, but if there's enough interest I would try at least to find some time to talk with others about improving the email package. Those of you who are going to Pycon, is anybody available to sprint a bit on email? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZVz7nEjvBPtnXfVAQK7nwQArJMjC9TVxnuuZ+4kBBD3+1pqyXbnRKa/ /nuWCfrqsW5z/RGxWdPjHf/02TCdGXsnRwGhE8bjDgawL0VnO1lTZIXjovy6JvJ0 EpFX5P9TDCuXmcCpiKAk4xKBHo6SrlGpH9A264jTzVe2ri/twVKNBGyUn3eg4tYt ERqH8QrXHok= =1ntw -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding T_SIZET to structmember.h
On Thu, Feb 12, 2009 at 8:42 PM, Lisandro Dalcin wrote: > I would like to propose the inclusion of a new T_SIZET in structmember.h > in order to suport 'size_t' struct fields with PyMemberDef. Would such > addition be accepted for 2.7 and 3.1? Please open a feature request at bugs.python.org, and we'll find out! A working patch would probably be helpful. (It sounds like a sensible addition to me.) Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding T_SIZET to structmember.h
Done, http://bugs.python.org/issue5248 Mark, the patch is not trivial, I cannot spend time on this until this is accepted. Hope you understand. On Fri, Feb 13, 2009 at 1:15 PM, Mark Dickinson wrote: > On Thu, Feb 12, 2009 at 8:42 PM, Lisandro Dalcin wrote: >> I would like to propose the inclusion of a new T_SIZET in structmember.h >> in order to suport 'size_t' struct fields with PyMemberDef. Would such >> addition be accepted for 2.7 and 3.1? > > Please open a feature request at bugs.python.org, and we'll find out! A > working patch would probably be helpful. > > (It sounds like a sensible addition to me.) > > Mark > -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (02/06/09 - 02/13/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2352 open (+56) / 14720 closed (+22) / 17072 total (+78) Open issues with patches: 803 Average duration of open issues: 682 days. Median duration of open issues: 423 days. Open Issues Breakdown open 2328 (+55) pending24 ( +1) Issues Created Or Reopened (82) ___ Separate build dir broken02/12/09 http://bugs.python.org/issue4151reopened doko patch Disabling test_ttk_guionly on mac02/09/09 http://bugs.python.org/issue5120reopened gpolo patch Default hash not equal to id on AMD Sempron 02/09/09 http://bugs.python.org/issue5169reopened jcea python-dev tracker summary emails contain incorrect "median dura 02/06/09 CLOSED http://bugs.python.org/issue5172created exarkun "What's new" claims StandardError was removed in 2.6 02/06/09 CLOSED http://bugs.python.org/issue5173created mjwpp xmlrpclib docs include incorrect file closing02/06/09 CLOSED http://bugs.python.org/issue5174created ironfroggy patch negative PyLong -> C unsigned integral, TypeError or OverflowErr 02/06/09 CLOSED http://bugs.python.org/issue5175created dalcinl patch Special-case string formatting in BINARY_MODULO implementation 02/06/09 http://bugs.python.org/issue5176created collinwinter patch, patch, needs review multiprocessing: SocketListener should use SO_REUSEADDR 02/07/09 http://bugs.python.org/issue5177created jon_dee Add context manager for temporary directory 02/07/09 http://bugs.python.org/issue5178created nascheme patch subprocess leaves open fds on construction error 02/07/09 http://bugs.python.org/issue5179created georg.brandl 3.1 cannot unpickle 2.7-created pickle 02/07/09 http://bugs.python.org/issue5180created pitrou test_urllib failures on the 3.1 buildbots02/08/09 CLOSED http://bugs.python.org/issue5181reopened benjamin.peterson str() on memoryview of bytearray failing on py3k 02/08/09 CLOSED http://bugs.python.org/issue5182created mhammond wsgiref.simple_server not working02/08/09 CLOSED http://bugs.python.org/issue5183created StephenDay Add -3 warning for extension types that implement tp_compare but 02/08/09 http://bugs.python.org/issue5184created marketdickinson Idle doesn't work on 2.6 on Macbook 02/08/09 CLOSED http://bugs.python.org/issue5185created jeaub23 Reduce hash collisions for objects with no __hash__ method 02/08/09 CLOSED http://bugs.python.org/issue5186created marketdickinson patch distutils upload should prompt for the user/password too 02/08/09 http://bugs.python.org/issue5187created tarek telnetlib process_rawq buffer handling is confu
Re: [Python-Dev] Tracker archeology
Daniel (ajax) Diniz wrote: > "Martin v. Löwis" wrote: >> I think HTML scraping is a really bad idea. What is it that you >> specifically want to do with these data? > > For starters, free form searches, aggregation and filtering of > results. The web interface is pretty good for handling individual > issues, but not so good for adding someone as nosy to lots of issues. I should have thought of this earlier: I'm downloading A CSV file (displaying all fields) with all issues and will insert that into a DB (maybe through my local tracker instance). Thanks for asking the 'think about it' question! :) Daniel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Brett Cannon wrote: > On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz wrote: >> I have to test my patch against a good >> representation of the issue, regression tests must pass, 'automated >> test needed' fits well :) > > Go with "Unit test needed" so it's short and to the point and you have a > deal. =) I don't think a real name change is necessary, the help from clicking on 'Stage' says it. Your explanation at https://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw makes it crystal clear. Also, I've realized just now that 'Status: pending' covers both my 'will close unless someone objects' and 'cannot tell if this ancient bug on a antediluvian platform still exists' rather well. So I'll be setting such issues as pending from now on. I'll try to find a way to display the help tips inline, perhaps on selection or hover (has to be unobtrusive). That would be helpful for stages, components and versions (I think users should know that 2.5 is in security-fix-only mode and that feature requests need latest version + 1). Status report and roadmap to be posted later today, before date +%s turns 1234567890 :) Daniel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Steve Holden wrote: > Can I just say (without in any way wanting to get involved in what might > be considered as "work") that it's encouraging the tracker received a > bit more TLC we might eventually be able to see at least the occasional > week where the issue count increment was negative :) That would be cool. It's also a shiny goal that can be used on a call-for-help later on the cleanup road. > So thanks to everyone who's taking the time to deal with this > low-profile not-very-glamorous issue. I, for one, appreciate it. For my part, glad to help. And thanks to all developers, issue reporters and cleanup supporters that are making this work :) tlc'ing-got-me-punched-in-the-face-before-so-this-one-is-a-breeze-ly y'rs Daniel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Wow!
http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wow!
http://en.wikipedia.org/wiki/Kessler_Syndrome On Fri, Feb 13, 2009 at 1:12 PM, Raymond Hettinger wrote: > > http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kirklin.mcdonald%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
I discovered today that Python 2's prohibition against performing
readlines on a file being iterated over appears to have been lifted
in Python 3. Is this intentional? If it is, should it be added to the
What's New in the documentation? I haven't been able to find anything
mentioning the change.
with open("lines.txt") as fil:
for line in fil:
print(line[:-1])
print(fil.readline())
produces a runtime error in 2.5 and 2.6 but not in 3.0 or 3.1 (and
the output is as expected).
Also, I was surprised that nested "for line in file" that use the
same file cause no problems in Python 2.5, 2.6, 3.0, or 3.1.
with open("lines.txt") as fil:
for line1 in fil:
print(line1)
if line1[0] == '1':
for line2 in fil:
print(line2[:-1])
if line2[0] == '2':
break
I would have expected the "for line in file" iterator to get confused
by the file position having been moved out from under it, but I
suppose all it has to do is just more readlines from wherever the
file pointer is when it regains control. I mention this because apart
from implementation considerations any reasoning that would
discourage one from mixing line iterations with readlines might leave
one thinking that nested line iterations wouldn't work either. But if
it is intended that Python 3 allow mixing readlines with line
iterations, there would be much less reason to suspect nested line
iterations.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
> For starters, free form searches, aggregation and filtering of > results. What is "free form searches" (example)? What is aggregation? What results do you want to filter? (roundup can already filter results quite well) > The web interface is pretty good for handling individual > issues, but not so good for adding someone as nosy to lots of issues. Please consider contributing a mass-update template then, perhaps based on search results, with check boxes to include or exclude individual issues from the mass update. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
> Send emails before they were done :D Again: what's that? > Use a VCS for in-progress activities Hmm. Why do you need a database copy for that? > Figure out how to serialize and submit the work done locally Again, don't understand. too brief. > Share results with interested parties off-tracker (e.g., the > auto-nosy mentioned up-thread) The tracker already has auto-assignments based on components. > Right now, more efficient searching and aggregation along with some > (local, flexible) UI tweaks sum it up. Efficient in what way? > Maybe I can offer a patch for something like PyPI's 'simple' interface? Please, no. Contribute the interface you want locally instead as a feature for all users of the tracker. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding T_SIZET to structmember.h
> Mark, the patch is not trivial, I cannot spend time on this until this > is accepted. Hope you understand. I certainly do understand. So it's likely not going to happen. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Small misleadingness in docs
I've discovered something slightly misleading in the docs for PyObject_IsInstance: When testing if B is a subclass of A, if A is B, PyObject_IsSubclass returns true. If A and B are different objects, B‘s __bases__ attribute is searched... This suggests that issubclass(A, A) will always be true, regardless of what attributes A has. However, this turns out not to be so -- A must also have a __bases__ attribute, otherwise it's rejected as not being sufficiently class-like. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small misleadingness in docs
[Greg Ewing] I've discovered something slightly misleading in the docs for PyObject_IsInstance: When testing if B is a subclass of A, if A is B, PyObject_IsSubclass returns true. If A and B are different objects, B‘s __bases__ attribute is searched... This suggests that issubclass(A, A) will always be true, regardless of what attributes A has. However, this turns out not to be so -- A must also have a __bases__ attribute, otherwise it's rejected as not being sufficiently class-like. This smells like a bug that brings issubclass() out of sync with isinstance(). Perhaps issubclass() should do what the docs say and start by testing whether A and B are the same object. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wow!
Is there a Python connection I'm missing? On Fri, Feb 13, 2009 at 13:12, Raymond Hettinger wrote: > > http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small misleadingness in docs
Raymond Hettinger wrote: This smells like a bug that brings issubclass() out of sync with isinstance(). No, it affects both isinstance() and issubclass(). They both raise a TypeError if the purported class object doesn't have a __bases__ attribute that is a tuple. This isn't necessarily wrong, but perhaps the docs could be re-worded slightly to make this clearer. Another thing is that this whole paragraph only appears in the Python/C API reference, not in the docs for the Python isinstance and issubclass functions, where the docs imply that only genuine class or type objects are accepted. And nowhere does it mention that __bases__ must be a tuple. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wow!
Brett Cannon wrote: Is there a Python connection I'm missing? http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story Well, the front page of python.org does say "NASA uses Python"... Also it sounds like they could do with a really good garbage collection algorithm just now. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the availability of Python 3.0.1, the first bug fix release of Python 3.0. Version 3.0.1 fixes dozens of bugs reported since the release of Python 3.0 on December 3rd, 2008. Python 3.0 represents a major milestone in Python's history. This new version of the language is incompatible with the 2.x line of releases, while remaining true to BDFL Guido van Rossum's vision. For more information, links to documentation, and downloadable distributions, see the Python 3.0.1 release page: http://www.python.org/download/releases/3.0.1/ To report bugs in Python 3.0.1, please submit them to the issue tracker at: http://bugs.python.org/ Enjoy! Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZYpSnEjvBPtnXfVAQLQwgP/WSHp12dJVpEYtEOL/X8ynCQACriij9AM PgT6SacbMJLbsy84CTGA1lxF4NdEUQMY1IYz0do/aZ0+nBkSoy7SlkOVcncysLSC hVyTVlWQBdh63yA8QUk1I5dMbKeNpbCqRRgvSHaBrVdVz9mDM/r/L+j9lhBW4Cam 2lHLjRdQaG0= =vy0O -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The fate of 3.0.*
Are we going to keep developing the 3.0 maintenance branch in expectation of releasing 3.0.2 sometime or will we just focus our efforts on 3.1? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of 3.0.*
On Fri, Feb 13, 2009 at 18:35, Benjamin Peterson wrote: > Are we going to keep developing the 3.0 maintenance branch in > expectation of releasing 3.0.2 sometime or will we just focus our > efforts on 3.1? > I almost said "of course we are", but then I realized that 3.1 is going to be very similar to 3.0.1 such that doing a final 3.0.x release probably is not going to be worth it. Lord knows I sure don't want to have to port a bug fix to *five* branches. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of 3.0.*
On Fri, Feb 13, 2009 at 6:49 PM, Brett Cannon wrote: > On Fri, Feb 13, 2009 at 18:35, Benjamin Peterson > wrote: >> >> Are we going to keep developing the 3.0 maintenance branch in >> expectation of releasing 3.0.2 sometime or will we just focus our >> efforts on 3.1? > > I almost said "of course we are", but then I realized that 3.1 is going to > be very similar to 3.0.1 such that doing a final 3.0.x release probably is > not going to be worth it. Lord knows I sure don't want to have to port a bug > fix to *five* branches. Amen. I can see two scenarios where we might release 3.0.2: (a) if we find a really severe error in 3.0.1 (or perhaps a security problem); (b) if 3.1 ends up getting delayed severely. In case (a) happens it's okay if the 3.0 branch is left alone until the time we need to make that one patch. The probability of (b) is low, so let's worry about that when it happens, and let's try not to make it happen. :-) Congratulations all with the release! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of 3.0.*
Benjamin Peterson python.org> writes: > > Are we going to keep developing the 3.0 maintenance branch in > expectation of releasing 3.0.2 sometime or will we just focus our > efforts on 3.1? Focusing on 3.1 should be ok. So what are the expected efforts for 3.1? - io-in-C - import-in-Python - ... anything else? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of 3.0.*
>So what are the expected efforts for 3.1? >- io-in-C >- import-in-Python >- ... anything else? A fixed "email" module. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0.1
On Fri, Feb 13, 2009 at 9:15 PM, Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team, I'm happy to announce the > availability of Python 3.0.1, the first bug fix release of Python 3.0. > Version 3.0.1 fixes dozens of bugs reported since the release of Python 3.0 > on December 3rd, 2008. > > Python 3.0 represents a major milestone in Python's history. This new > version of the language is incompatible with the 2.x line of releases, while > remaining true to BDFL Guido van Rossum's vision. > > For more information, links to documentation, and downloadable > distributions, see the Python 3.0.1 release page: > >http://www.python.org/download/releases/3.0.1/ > > To report bugs in Python 3.0.1, please submit them to the issue tracker at: > >http://bugs.python.org/ > > Enjoy! > Barry Any chance of getting a Mac installer for this one? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Hi Martin, Sorry about being so brief, I got a lot of unexpected interruptions and was rushing things. "Martin v. Löwis" wrote: >> For starters, free form searches, aggregation and filtering of >> results. > > What is "free form searches" (example)? What is aggregation? > What results do you want to filter? (roundup can already filter > results quite well) By free form searches I meant complex queries with more flexible criteria. A real example: "find any issue that has words A and B in juxtaposed in messages, containing words starting with 'url' [ but not ending with 'lib' in title (, unless version >= 3)], where jjlee isn't nosy". Or "issues with less than 5 replies, all from a single user". Lastly, "issues where no Developer is nosy, with messages covering an interval longer than a week". These are useful a few times, but hard to predict and not so recurrent searches, so free form makes more sense than adding support for each combination. By aggregation I meant performing a few disjunct searches and combining them in a result set, eliminating duplication, to process as a unit. Then, add issues A,B and C to that. Free form searches cover this by allowing one to perform a query that gives the result set directly, but combining previous searches sounds more pleasant. And by filtering, I meant refining a set of search results and/or searching over a restricted set of issues, on criteria that are present in them. I.e., I'd like to search for segfault and be given a choice box with the all nosy people in the result set, and exclude or only display issues based choosing one of them. All of the above seems trivial with a database-like interface. I have pretty much emulated them with the current search, the handy CSV results downloads, a text editor and a Python shell. >> The web interface is pretty good for handling individual >> issues, but not so good for adding someone as nosy to lots of issues. > > Please consider contributing a mass-update template then, perhaps > based on search results, with check boxes to include or exclude > individual issues from the mass update. OK, I saw one of these at http://roundup.sf.net/ and will study and adapt it. But it'll solve the 'commit changes' part of the equation, not the 'select set of issues to change'. >> Send emails before they were done :D > > Again: what's that? That's me trying to sound witty after sending the email before finishing it :) >> Use a VCS for in-progress activities > > Hmm. Why do you need a database copy for that? I don't, the database if for selecting issues to edit. But I'd like to be able to submit bulk changes, and a (local, D) VCS is how I imagine storing these locally should be done. For rollbacks, merges and that sort of thing, besides being able to save incomplete work to continue later. >> Figure out how to serialize and submit the work done locally > > Again, don't understand. too brief. The serialization idea comes from this: one would assemble a 'patch' containing different changes to different issues. It's an extension of the mass-update idea, but for non-uniform changes. The deserialization would either happen through a mass-update interface or by running a script to submit them one by one. >> Share results with interested parties off-tracker (e.g., the >> auto-nosy mentioned up-thread) > > The tracker already has auto-assignments based on components. But no way to share aggregated search results (I've sent some off-list), 'follow' users (i.e., be added as nosy for issues where user A is nosy), auto-add as nosy based on keywords, etc. Someday we could have these nosy features hosted externally, e.g. as an AppEngine app that subscribes to python-bugs and sends alerts to users matching the message (by keyword, performed action, new stage, etc.). >> Right now, more efficient searching and aggregation along with some >> (local, flexible) UI tweaks sum it up. > > Efficient in what way? Having those complex searches in a less convoluted workflow, allowing more work to be done faster and in a less error prone way. >> Maybe I can offer a patch for something like PyPI's 'simple' interface? > > Please, no. Contribute the interface you want locally instead as a > feature for all users of the tracker. OK, after some more cleaning up I'll work on the mass-update, my local searches and report back. Regards, Daniel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker archeology
Daniel (ajax) Diniz wrote: > Status report and roadmap to be posted later today, before date +%s > turns 1234567890 :) Missed that and got almost no tracker work done. Postponed to Monday, after some weekend cleaning. Daniel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
