
Hi all, For the past two days I've been doing some housekeeping *cough*spamming*cough* on the tracker, mostly on ancient and/or easy bugs. So far, ten bugs have been closed (thanks Antoine, Barry, Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs (below) for closing and added a few simple patches, with a couple more pending feedback. If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker. Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real work and people agree the workflow would be better, I'd like to have developer rights in the tracker, as per Antoine's suggestion. FWIW, I have no problem with the current situation. Talking about Bug Days, I see lots of easy bugs, some with outdated patches. Is there any plan of doing a Bug Day around PyCon time? Best regards, Daniel Bugs nominated for express closing: http://bugs.python.org/issue1103926 email.base64MIME.header_encode vs RFC 1522 http://bugs.python.org/issue727898 Support for sending multipart form data http://bugs.python.org/issue713169 test_pty fails on HP-UX and AIX when run after test_openpty http://bugs.python.org/issue816059 popen2 work, fixes bugs 768649 and 761888 http://bugs.python.org/issue1911 webbrowser.open firefox 3 issues http://bugs.python.org/issue1170065 HTTPResponse.getheaders() returns lowercased header names http://bugs.python.org/issue1175686 add "reload" function http://bugs.python.org/issue779191 BasicModuleLoader behaviour in Python 2.3c2 http://bugs.python.org/issue1327971 HTTPResponse instance has no attribute 'fileno'

2009/2/10 Daniel (ajax) Diniz <ajaksu@gmail.com>:
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
Anything related to Decimal, add me. Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Thanks Daniel! This kind of work is never fun but very much needed and I'm very glad you did it. A round of applause!! On Tue, Feb 10, 2009 at 5:23 AM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
Hi all,
For the past two days I've been doing some housekeeping *cough*spamming*cough* on the tracker, mostly on ancient and/or easy bugs. So far, ten bugs have been closed (thanks Antoine, Barry, Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs (below) for closing and added a few simple patches, with a couple more pending feedback.
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real work and people agree the workflow would be better, I'd like to have developer rights in the tracker, as per Antoine's suggestion. FWIW, I have no problem with the current situation.
Talking about Bug Days, I see lots of easy bugs, some with outdated patches. Is there any plan of doing a Bug Day around PyCon time?
Best regards, Daniel
Bugs nominated for express closing:
http://bugs.python.org/issue1103926 email.base64MIME.header_encode vs RFC 1522
http://bugs.python.org/issue727898 Support for sending multipart form data
http://bugs.python.org/issue713169 test_pty fails on HP-UX and AIX when run after test_openpty
http://bugs.python.org/issue816059 popen2 work, fixes bugs 768649 and 761888
http://bugs.python.org/issue1911 webbrowser.open firefox 3 issues
http://bugs.python.org/issue1170065 HTTPResponse.getheaders() returns lowercased header names
http://bugs.python.org/issue1175686 add "reload" function
http://bugs.python.org/issue779191 BasicModuleLoader behaviour in Python 2.3c2
http://bugs.python.org/issue1327971 HTTPResponse instance has no attribute 'fileno' _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)

In peephole.c I noticed some expression optimizations: /* not a is b --> a is not b not a in b --> a not in b not a is not b --> a is b not a not in b --> a in b */ So, it seems that an operation can be changed to another one which is logically equivalent. Could it be applyable to other operations as well? So, if I wrote: c = not(a < b) the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation: c = a >= b Is it right? Thanks a lot Cesare

On Tue, Feb 10, 2009 at 10:24 AM, Cesare Di Mauro <cesare.dimauro@a-tono.com
wrote:
Could it be applyable to other operations as well? So, if I wrote: c = not(a < b) the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation: c = a >= b
Those two expressions are equivalent for integers, but not necessarily equivalent for objects that define their own comparison operator. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

Daniel Stutzbach wrote:
On Tue, Feb 10, 2009 at 10:24 AM, Cesare Di Mauro <cesare.dimauro@a-tono.com <mailto:cesare.dimauro@a-tono.com>> wrote:
Could it be applyable to other operations as well? So, if I wrote: c = not(a < b) the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation: c = a >= b
Those two expressions are equivalent for integers, but not necessarily equivalent for objects that define their own comparison operator.
That's true, but the same *could* be said about the existing optimizations for objects that define their own __contains__. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

On Tue, Feb 10, 2009 at 11:16 AM, Steve Holden <steve@holdenweb.com> wrote:
That's true, but the same *could* be said about the existing optimizations for objects that define their own __contains__.
No, because there isn't a __not_contains__, so you cannot define the inverse operation differently. "not a in b" and "a not in b" have exactly the same effects. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

Daniel Stutzbach wrote:
On Tue, Feb 10, 2009 at 11:16 AM, Steve Holden <steve@holdenweb.com <mailto:steve@holdenweb.com>> wrote:
That's true, but the same *could* be said about the existing optimizations for objects that define their own __contains__.
No, because there isn't a __not_contains__, so you cannot define the inverse operation differently. "not a in b" and "a not in b" have exactly the same effects.
Ah, right, that guarantees semantic equivalence. Sorry. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

On Mar, Feb 10, 2009 06:24 PM, Daniel Stutzbach wrote:
On Tue, Feb 10, 2009 at 11:16 AM, Steve Holden <steve@holdenweb.com> wrote:
That's true, but the same *could* be said about the existing optimizations for objects that define their own __contains__.
No, because there isn't a __not_contains__, so you cannot define the inverse operation differently. "not a in b" and "a not in b" have exactly the same effects.
Interesting. So at least for "is" and "in" operators it is possible to play with the "not" operator. Thanks Cesare

Steve Holden <steve <at> holdenweb.com> writes:
That's true, but the same *could* be said about the existing optimizations for objects that define their own __contains__.
No, because there is no such thing as __not_contains__. Regards Antoine.

On Mar, Feb 10, 2009 at 05:38 PM, Daniel Stutzbach wrote:
On Tue, Feb 10, 2009 at 10:24 AM, Cesare Di Mauro <cesare.dimauro@a-tono.com
wrote:
Could it be applyable to other operations as well? So, if I wrote: c = not(a < b) the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation: c = a >= b
Those two expressions are equivalent for integers, but not necessarily equivalent for objects that define their own comparison operator.
OK, so I can make assumptions only for built-in types. Thank you Cesare

On Tue, Feb 10, 2009 at 2:36 PM, Cesare Di Mauro <cesare.dimauro@a-tono.com>wrote:
OK, so I can make assumptions only for built-in types.
Yes, but even there you have to be careful of odd corner-cases, such as:
nan = float('nan') nan < nan False nan >= nan False
-- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

On Mar, Feb 10, 2009 09:42PM, Daniel Stutzbach wrote:
On Tue, Feb 10, 2009 at 2:36 PM, Cesare Di Mauro <cesare.dimauro@a-tono.com>wrote:
OK, so I can make assumptions only for built-in types.
Yes, but even there you have to be careful of odd corner-cases, such as:
nan = float('nan') nan < nan False nan >= nan False
Ah, I missed it. OK, and the same apply for decimals, I suppose. Thanks Cesare

And slightly unrelated, but just showing how bizarre floats are:
x = 1e66666 y = x/x cmp(y, y) 0 cmp(x/x, x/x) -1
Yeah object identity checks! From: python-dev-bounces+dinov=microsoft.com@python.org [mailto:python-dev-bounces+dinov=microsoft.com@python.org] On Behalf Of Daniel Stutzbach Sent: Tuesday, February 10, 2009 12:43 PM To: cesare.dimauro@a-tono.com Cc: Python-Dev Subject: Re: [Python-Dev] Expression optimizations On Tue, Feb 10, 2009 at 2:36 PM, Cesare Di Mauro <cesare.dimauro@a-tono.com> wrote: OK, so I can make assumptions only for built-in types. Yes, but even there you have to be careful of odd corner-cases, such as:
nan = float('nan') nan < nan False nan >= nan False -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC

Cesare Di Mauro <cesare.dimauro <at> a-tono.com> writes:
Could it be applyable to other operations as well? So, if I wrote:
c = not(a < b)
the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation:
c = a >= b
Is it right?
No, it would be a bogus optimization:
a = set([1]) b = set([2]) a < b False a >= b False
Regards Antoine.

----- Original Message ----- From: "Cesare Di Mauro" <cesare.dimauro@a-tono.com> To: "Python-Dev" <python-dev@python.org> Sent: Tuesday, February 10, 2009 8:24 AM Subject: [Python-Dev] Expression optimizations
In peephole.c I noticed some expression optimizations:
/* not a is b --> a is not b not a in b --> a not in b not a is not b --> a is b not a not in b --> a in b */
So, it seems that an operation can be changed to another one which is logically equivalent.
Could it be applyable to other operations as well? So, if I wrote:
c = not(a < b)
the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation:
c = a >= b
Is it right?
We've only done conservative transformations that do not change which magic methods get called. The is / isnot transformations are invisible to the programmer and always semantically neutral. Your proposed transformation is changes which methods get called and makes assumptions that the usual relationships between comparison operators holds (but it might not given rich comparisons, for example, sets use the comparison operators for subset/superset tests). Raymond

On Mar, Feb 10, 2009 08:15 PM, Raymond Hettinger wrote:
----- Original Message ----- From: "Cesare Di Mauro" <cesare.dimauro@a-tono.com> To: "Python-Dev" <python-dev@python.org> Sent: Tuesday, February 10, 2009 8:24 AM Subject: [Python-Dev] Expression optimizations
In peephole.c I noticed some expression optimizations:
/* not a is b --> a is not b not a in b --> a not in b not a is not b --> a is b not a not in b --> a in b */
So, it seems that an operation can be changed to another one which is logically equivalent.
Could it be applyable to other operations as well? So, if I wrote:
c = not(a < b)
the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the following operation:
c = a >= b
Is it right?
We've only done conservative transformations that do not change which magic methods get called. The is / isnot transformations are invisible to the programmer and always semantically neutral.
OK, and the same apply to the "in" operator, if I have understood correctly the other messages.
Your proposed transformation is changes which methods get called and makes assumptions that the usual relationships between comparison operators holds (but it might not given rich comparisons, for example, sets use the comparison operators for subset/superset tests).
Raymond, I'm not proposing any changes to the language. I'm playing with the virtual machine and I have some ideas about possibile optimizations that could be applyed. But I need to verify them, so understanding what is possible and what is not, is a primary goal for me. ;) Thanks for you patience Cesare

[Cesare Di Mauro]
I'm playing with the virtual machine and I have some ideas about possibile optimizations that could be applyed. But I need to verify them, so understanding what is possible and what is not, is a primary goal for me.
The best way to understand what is possible is to disassemble bytecode and the look at *exactly* how those are executed by ceval.c. That makes it possible to identify which transformations are semantically neutral. FWIW, I think the path of peephole optimizing been mostly exhausted. A much more fertile field of search is to examine what can be done with the AST. Sections of the tree may provide more context so that a broader range of simplifications and transformations are possible. This should discussion probably be taken off python-dev and moved to to comp.lang.python until the exercise has grown beyond "playing with the virtual machine." Raymond

On Mar, Feb 10, 2009 10:20PM, Raymond Hettinger wrote:
[Cesare Di Mauro]
I'm playing with the virtual machine and I have some ideas about possibile optimizations that could be applyed. But I need to verify them, so understanding what is possible and what is not, is a primary goal for me.
The best way to understand what is possible is to disassemble bytecode and the look at *exactly* how those are executed by ceval.c. That makes it possible to identify which transformations are semantically neutral.
I've already done it, but ceval.c isn't enough. It makes use of external functions to do some works, like PyObject_RichCompare, for example. So I've asked some information here.
FWIW, I think the path of peephole optimizing been mostly exhausted.
I think so too, but there's room for a few optimizations (introducing some new opcodes).
A much more fertile field of search is to examine what can be done with the AST. Sections of the tree may provide more context so that a broader range of simplifications and transformations are possible.
I completely agree.
This should discussion probably be taken off python-dev and moved to to comp.lang.python until the exercise has grown beyond "playing with the virtual machine."
Raymond
I've already rewritten ceval.c, opcode.h and some other files of Python 2.6.1 to implement my ideas. I think it's a little bit beyond "playing" with the VM, and I hope to present my work to the next PyCon at Florence, in Italy, if my paper will be accepted. Now I'm trying to understand how compiler.c works, to fit in my changes (I took a look at peephole.c, and it'll be easier, fortunately, but I'll do it later). It's not easy for me, since I'm alone, I'm working to a code which is not mine, and a bit complicated too. But if you think that this mailing list is not the correct place to ask for, I'll move to comp.lang.python, as you have suggested. Thanks, Cesare

On Tue, Feb 10, 2009 at 1:23 PM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
Feel free to assign anything math-related (math and cmath modules, float and complex objects) to me. Thanks for this! Mark

On Tue, Feb 10, 2009 at 05:23, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
Hi all,
For the past two days I've been doing some housekeeping *cough*spamming*cough* on the tracker, mostly on ancient and/or easy bugs. So far, ten bugs have been closed (thanks Antoine, Barry, Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs (below) for closing and added a few simple patches, with a couple more pending feedback.
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
Warnings and import for me.
Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real work and people agree the workflow would be better, I'd like to have developer rights in the tracker, as per Antoine's suggestion. FWIW, I have no problem with the current situation.
It's been asked on python-committers; just have to wait for any potential objections (really doubt there will be any, though).
Talking about Bug Days, I see lots of easy bugs, some with outdated patches. Is there any plan of doing a Bug Day around PyCon time?
Well, the sprints at PyCon are Bug Days themselves really, although they happen during the week so that tends to cause problems. As of right now there are no plans but someone can obviously plan one if they feel up for it. -Brett

Brett Cannon wrote:
Warnings and import for me.
Done. Tomorrow I'll see what I can triage/test in those.
Talking about Bug Days, I see lots of easy bugs, some with outdated patches. Is there any plan of doing a Bug Day around PyCon time?
Well, the sprints at PyCon are Bug Days themselves really, although they happen during the week so that tends to cause problems. As of right now there are no plans but someone can obviously plan one if they feel up for it.
OK, sometime later I'll try to flag Easy bugs, then. Daniel

On Tue, Feb 10, 2009 at 8:23 AM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
Adding/assigning to me on 2to3 bugs is fine, but usually I notice stuff I'm interested in as it rises to the top.
Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real work and people agree the workflow would be better, I'd like to have developer rights in the tracker, as per Antoine's suggestion. FWIW, I have no problem with the current situation.
+10 for tracker access for you. This is the kind of work is something I think everybody has on their lists and really needs some TLC. Thank you! -- Regards, Benjamin

Benjamin Peterson wrote:
Adding/assigning to me on 2to3 bugs is fine, but usually I notice stuff I'm interested in as it rises to the top.
Done, found a couple more. There are also some -3 warnings open, if that interests you :) Thanks for the support, I only saw it was a +10 now :D Cheers, Daniel

On Tue, Feb 10, 2009 at 05:23, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
[SNIP] Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real work and people agree the workflow would be better, I'd like to have developer rights in the tracker, as per Antoine's suggestion. FWIW, I have no problem with the current situation.
OK, three enthusiastic votes to give them is plenty for me. You should have the Developer role now, Daniel. Let me know if I screwed up at all in switchng the role on for you. -Brett

Brett Cannon wrote:
OK, three enthusiastic votes to give them is plenty for me. You should have the Developer role now, Daniel. Let me know if I screwed up at all in switchng the role on for you.
Thanks a lot! Looks like it worked fine :) Let me try the new thing, then: warnings and import for you, distutils for Tarek, 2to3 (if any left) for Benjamin and Unicode for Ezio (and patches for Antoine!). If anyone else wants to claim or be added to dusty bugs, just give me a shout :) Cheers, Daniel

On 2009-02-10, Tarek Ziadé wrote:
On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
I'll take Distutils related issues,
If you could look at a solution for http://bugs.python.org/issue1533164 I would be eternally grateful. -- Regards, Stephen Thorne Development Engineer NetBox Blue - 1300 737 060 NetBox Blue is proud to be a sponsor and exhibitor at IBM's Solutions Showcase 2009 events. These are held in Perth, Adelaide, Brisbane, Sydney and Melbourne in February and March. For more details and to register please visit: http://www.ibm.com/solutionsshowcase/au Scanned by the NetBox from NetBox Blue (http://netboxblue.com/)

On Wed, Feb 11, 2009 at 12:46 AM, Stephen Thorne <stephen@thorne.id.au> wrote:
On 2009-02-10, Tarek Ziadé wrote:
On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
I'll take Distutils related issues,
If you could look at a solution for http://bugs.python.org/issue1533164 I would be eternally grateful.
ok, that would be the next one I am working on in that case, Regards Tarek

+1 on the cleanup: reading the bug description of http://bugs.python.org/issue1533164, this will also help Jython. Now I know why we see scenarios of package with setup.cfg with optimize=1: Indeed, this is a well-known issue. Many packages put an "optimize=1" in their setup.cfg in order to solve it. Unfortunately that breaks the setup process on Jython, since we don't support -O. And unfortunately it's not as easy to ignore the flag either, this can then break in other ways. - Jim On Wed, Feb 11, 2009 at 2:08 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Wed, Feb 11, 2009 at 12:46 AM, Stephen Thorne <stephen@thorne.id.au> wrote:
On 2009-02-10, Tarek Ziadé wrote:
On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
If anyone is interested in being added as nosy for any category of bugs, let me know and I'll do that as I scan the tracker.
I'll take Distutils related issues,
If you could look at a solution for http://bugs.python.org/issue1533164 I would be eternally grateful.
ok, that would be the next one I am working on in that case,
Regards Tarek _______________________________________________ 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/jbaker%40zyasoft.com
-- Jim Baker jbaker@zyasoft.com

Jim Baker wrote:
+1 on the cleanup: reading the bug description of http://bugs.python.org/issue1533164, this will also help Jython. Now I know why we see scenarios of package with setup.cfg with optimize=1:
Indeed, this is a well-known issue. Many packages put an "optimize=1" in their setup.cfg in order to solve it.
Unfortunately that breaks the setup process on Jython, since we don't support -O. And unfortunately it's not as easy to ignore the flag either, this can then break in other ways.
- Jim
Add this comment to tracker if you want to be sure anyone reading it sees this ;-)

Hi, Here's a status report about the digging. Thanks Benjamin, Antoine, Martin, Raymond, Guilherme, Georg, Brett, Mark and everyone else for helping :) Good: Many requested assignments: Thanks everyone that asked for bugs. If anyone else wants more, just let me know :) Old issues closed: ajaksu2 - 3 Everyone else - about 14 :) Checking and screening: > 100 issues on the 'verify and close or update' queue (most of what is popping up as changed) Bad: Assignment mistakes: Two issues reassigned to Brett (from MvL and JvR) because I didn't see they were already assigned: http://bugs.python.org/issue1419652 PyImport_AppendInittab stores pointer to parameter http://bugs.python.org/issue616247 More documentation for the imp module Sorry about that :-/ 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 :-/ Now will I'll start verifying, adding tests, updating or closing as needed the recently changed old issues, until I've taken a good look at these. Then, if there's still time left before Saturday, I'll focus on verifying/flagging more ancient ones. during-bug-season-every-day-is-bug-day-ly y'rs, Daniel

[Daniel (ajax) Diniz]
Now will I'll start verifying, adding tests, updating or closing as needed the recently changed old issues, until I've taken a good look at these. Then, if there's still time left before Saturday, I'll focus on verifying/flagging more ancient ones.
Thanks for your efforts. Raymond

2009/2/11 Daniel (ajax) Diniz <ajaksu@gmail.com>
Hi,
Here's a status report about the digging. Thanks Benjamin, Antoine, Martin, Raymond, Guilherme, Georg, Brett, Mark and everyone else for helping :)
Good: Many requested assignments: Thanks everyone that asked for bugs. If anyone else wants more, just let me know :)
Old issues closed: ajaksu2 - 3 Everyone else - about 14 :)
Checking and screening:
100 issues on the 'verify and close or update' queue (most of what is popping up as changed)
Bad: Assignment mistakes: Two issues reassigned to Brett (from MvL and JvR) because I didn't see they were already assigned: http://bugs.python.org/issue1419652 PyImport_AppendInittab stores pointer to parameter http://bugs.python.org/issue616247 More documentation for the imp module Sorry about that :-/
No big deal.
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 :-/
I think Georg at this point is the only auto-assignment.
Now will I'll start verifying, adding tests, updating or closing as needed the recently changed old issues, until I've taken a good look at these. Then, if there's still time left before Saturday, I'll focus on verifying/flagging more ancient ones.
One thing to keep an eye on for old issues, Daniel, is the Stage field. Setting that is nice for Bug Days as people can see what issues still need a test written or could use a review, etc. I have a doc I am writing up at http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the various Stage values should mean. Feedback from you and anybody else is welcome, although realize it is rough as I was not planning to make this public quite yet.
during-bug-season-every-day-is-bug-day-ly y'rs,
So true. =) -Brett

Brett Cannon wrote:
One thing to keep an eye on for old issues, Daniel, is the Stage field. Setting that is nice for Bug Days as people can see what issues still need a test written or could use a review, etc.
OK, I'll try to set a useful Stage for bugs I edit. I'll reread your blog post on stages and study the discussion.
I have a doc I am writing up at http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the various Stage values should mean. Feedback from you and anybody else is welcome, although realize it is rough as I was not planning to make this public quite yet.
Looking good, I'll collect doc feedback as I learn Stages better. Here's some feedback on Stages themselves (still learning, probably misguided). Many old issues have patches without tests, or have patches and tests that are outdated. Others have patches (and sometimes tests), but aren't confirmed as bugs. So the Stage field would be easier to use if it included: 'not reproduced in current releases', 'reproduced, needs updating', 'is this really a bug?' (i.e., should I be writing a test/confirming or discussing the issue?), 'on hold/blocked' (has a blocking dependency). I'm not sure those would be useful for new issues, I think handling the important cases efficiently is more desirable than tuning the workflow for old issues. It's telling that the Stage that caught my attention was [triage] :D Thank you for the support and feedback (and Stages guide!), it helps a lot :) Daniel

On Thu, Feb 12, 2009 at 05:08, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
Brett Cannon wrote:
One thing to keep an eye on for old issues, Daniel, is the Stage field. Setting that is nice for Bug Days as people can see what issues still need a test written or could use a review, etc.
OK, I'll try to set a useful Stage for bugs I edit. I'll reread your blog post on stages and study the discussion.
I have a doc I am writing up at http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the various Stage values should mean. Feedback from you and anybody else is welcome, although realize it is rough as I was not planning to make this public quite yet.
Looking good, I'll collect doc feedback as I learn Stages better.
Here's some feedback on Stages themselves (still learning, probably misguided).
Many old issues have patches without tests, or have patches and tests that are outdated. Others have patches (and sometimes tests), but aren't confirmed as bugs. So the Stage field would be easier to use if it included: 'not reproduced in current releases', 'reproduced, needs updating', 'is this really a bug?' (i.e., should I be writing a test/confirming or discussing the issue?), 'on hold/blocked' (has a blocking dependency).
Sounds like a "*verify issue* stage is needed. Although I guess I kind of assumed as part of the triage issue verification would happen as well, but that might be too much as a single step. All the other ones can use the current stages (e.g. a missing test with a patch is still at a *test needed* stage, it just happens to be able to skip to review once that test is ready).
I'm not sure those would be useful for new issues, I think handling the important cases efficiently is more desirable than tuning the workflow for old issues. It's telling that the Stage that caught my attention was [triage] :D
=)
Thank you for the support and feedback (and Stages guide!), it helps a lot :)
Glad it's helpful! -Brett

Brett Cannon wrote:
Sounds like a "*verify issue* stage is needed. Although I guess I kind of assumed as part of the triage issue verification would happen as well, but that might be too much as a single step.
I'd rather think about it a bit more, available stages cover the vast majority of the issues. When more people have spent spend some time setting and querying stages, new ones will be proposed to fill eventual gaps.
All the other ones can use the current stages (e.g. a missing test with a patch is still at a *test needed* stage, it just happens to be able to skip to review once that test is ready).
Yes, it makes a lot of sense. These milestones will help getting things done, anything more fine-grained should have a good, well-thougth use case (tracker-discuss is efficient for this). I have a couple of ideas for the work I'm doing, but they mostly revolve around client-side optimizations. Something like a DVCS flavor to triaging :) Daniel

Brett Cannon writes:
Sounds like a "*verify issue* stage is needed. Although I guess I kind of assumed as part of the triage issue verification would happen as well, but that might be too much as a single step.
Are you confusing "reproduce" with "verify"? Remember, one of the three classes for triage is "not a problem we need to deal with". Reproduction really is the same thing as providing a test.
All the other ones can use the current stages (e.g. a missing test with a patch is still at a *test needed* stage, it just happens to be able to skip to review once that test is ready).
What I did with XEmacs's tracker (which has borrowed a lot from Python's, thank you all *very* much!) is to have an "in progress" stage, with "needs test|patch|doc" and "has test|patch|doc" *keywords*. The difference in semantics is that "needs" is a judgment by the supervising reviewer, and the change (in theory) shouldn't be committed until all "needs" are satisfied, while "has" is what the contributor submitted. So they are independent, and you could even have both "has patch" and "needs patch" present if the current patch isn't good enough. This is too complex to expect people to execute, even IMO, but maybe there's the germ of an idea there? For example you could tell contributors that if the "has patch" flag isn't set, the patch won't get noticed by anybody.

On Thu, Feb 12, 2009 at 16:22, Stephen J. Turnbull <stephen@xemacs.org>wrote:
Brett Cannon writes:
Sounds like a "*verify issue* stage is needed. Although I guess I kind of assumed as part of the triage issue verification would happen as well, but that might be too much as a single step.
Are you confusing "reproduce" with "verify"? Remember, one of the three classes for triage is "not a problem we need to deal with". Reproduction really is the same thing as providing a test.
I was aiming toward Daniel's issue of whether the bug could be reproduced and thus verified as an issue when it is an old issue. But hopefully that won't happen too often so adding a new stage is probably a bit much.
All the other ones can use the current stages (e.g. a missing test with a patch is still at a *test needed* stage, it just happens to be able to skip to review once that test is ready).
What I did with XEmacs's tracker (which has borrowed a lot from Python's, thank you all *very* much!) is to have an "in progress" stage, with "needs test|patch|doc" and "has test|patch|doc" *keywords*. The difference in semantics is that "needs" is a judgment by the supervising reviewer, and the change (in theory) shouldn't be committed until all "needs" are satisfied, while "has" is what the contributor submitted. So they are independent, and you could even have both "has patch" and "needs patch" present if the current patch isn't good enough.
This is too complex to expect people to execute, even IMO, but maybe there's the germ of an idea there? For example you could tell contributors that if the "has patch" flag isn't set, the patch won't get noticed by anybody.
It's a question of whether we can stay on top of updating issues or not. If we can actually stay on the ball and update the status of issues then having the OP update something shouldn't be needed as that is too easy of an oversight for a casual contributor; minimizing the burden on contributions by making the issue workflow easy for the contributor and efficient for us is the top priority, but I think it is reasonable for us to do a little bit more to make it easier on others. And while you are right that the test/patch/doc stages can be view more in a parallel fashion than the linear one the stage drop-down provides, specifying the easiest of what is needed should help get more people involved. Plus they are in the order things should be done in the ideal situation. -Brett

Stephen J. Turnbull wrote:
Reproduction really is the same thing as providing a test.
That was where I got confused: many issues are easy to reproduce ('test'), but need some thinking to get automated tests right. urllib always feels like this to me, except 'thinking' -> 'getting lost over and over'. Reading 'test needed' as 'automated test needed', things make a lot of sense. I have to test my patch against a good representation of the issue, regression tests must pass, 'automated test needed' fits well :) Daniel

On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
Stephen J. Turnbull wrote:
Reproduction really is the same thing as providing a test.
That was where I got confused: many issues are easy to reproduce ('test'), but need some thinking to get automated tests right.
urllib always feels like this to me, except 'thinking' -> 'getting lost over and over'. Reading 'test needed' as 'automated test needed', things make a lot of sense. 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. =) -Brett

Brett Cannon wrote:
On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz <ajaksu@gmail.com <mailto:ajaksu@gmail.com>> wrote:
Stephen J. Turnbull wrote: > Reproduction really is the same thing as providing a test.
That was where I got confused: many issues are easy to reproduce ('test'), but need some thinking to get automated tests right.
urllib always feels like this to me, except 'thinking' -> 'getting lost over and over'. Reading 'test needed' as 'automated test needed', things make a lot of sense. 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. =)
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 :) So thanks to everyone who's taking the time to deal with this low-profile not-very-glamorous issue. I, for one, appreciate it. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

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

Brett Cannon wrote:
On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz <ajaksu@gmail.com> 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

On Thu, Feb 12, 2009 at 4:11 AM, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:
Now will I'll start verifying, adding tests, updating or closing as needed the recently changed old issues, until I've taken a good look at these. Then, if there's still time left before Saturday, I'll focus on verifying/flagging more ancient ones.
during-bug-season-every-day-is-bug-day-ly y'rs,
For urllib,urllib2 and urlparse related, please add me (orsenthil) to nosy list. I should already there. I shall test and provide patches. Thanks, Senthil

Senthil Kumaran wrote:
For urllib,urllib2 and urlparse related, please add me (orsenthil) to nosy list. I should already there. I shall test and provide patches.
Great! I always find it harder to test urllib[x] than to fix the bug. I'm in the process of gluing some tools and scripts together to help with the search/triage/update process, so I'll add you and Victor a later today. Might hold until after 3.0.1 (due tomorrow) if having the tracker less noisy would be better. In the meantime, other people interested in being added to urllib,urllib2 and urlparse are eligible for discounted prices :) Thanks for claiming these! Daniel

Hi Daniel,
Good: Many requested assignments: Thanks everyone that asked for bugs. If anyone else wants more, just let me know :)
I like everything related to Unicode and the separation of byte and character strings in Python3 :-) I already have some pending issues.. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/

Victor Stinner wrote:
I like everything related to Unicode and the separation of byte and character strings in Python3 :-)
That's a big one. But Ezio Melotti already asked for Unicode, so I have some 75 issues selected and ready to add you two to, but I'll do it later today or after 3.0.1 tomorrow. Might find some more until then :) Anyone else interested in Unicode? There's locale, gettext, codecs, the Unicode databases, support for Unicode in tools (network protocols and/or file formats, mostly: email, base64). Thanks for stepping up! Daniel

Le Thursday 12 February 2009 14:10:32, vous avez écrit :
Victor Stinner wrote:
I like everything related to Unicode and the separation of byte and character strings in Python3 :-)
That's a big one. But Ezio Melotti already asked for Unicode, so I have some 75 issues selected and ready to add you two to, but I'll do it later today or after 3.0.1 tomorrow. Might find some more until then :)
Oh, I realized that there is a component called "Unicode". So it should be possible to write a request to list all issues related to unicode. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/

Victor Stinner wrote:
Oh, I realized that there is a component called "Unicode". So it should be possible to write a request to list all issues related to unicode.
Nice, I'll add set this component for issues that don't have it. I can still add people to these issues, if they want. Daniel

Oh, I realized that there is a component called "Unicode". So it should be possible to write a request to list all issues related to unicode.
Nice, I'll add set this component for issues that don't have it. I can still add people to these issues, if they want.
We can also add more components if this would support your triage. As a necessary condition, I'd ask that there would be a "significant" number of issues classified under such a new component. Regards, Martin

Martin v. Löwis wrote:
Oh, I realized that there is a component called "Unicode". So it should be possible to write a request to list all issues related to unicode.
Nice, I'll add set this component for issues that don't have it. I can still add people to these issues, if they want.
We can also add more components if this would support your triage.
As a necessary condition, I'd ask that there would be a "significant" number of issues classified under such a new component.
Thanks, Martin. I don't have any request for new components so far, but would be happy to set new ones that might be created from other people's suggestions. I think some statistics could help us. I have a couple of suggestions regarding the UI, I should submit issues and patches to the meta-tracker sometime next week (got a python-dev instance running here, but haven't even looked at it). Mostly things like checkboxes for components, 'no version' being displayed, easier searches for missing/nothing (-1, right?), and a 'search in all issues' button for logged in users. Now, getting into pie-in-the-sky territory, if someone (not logged in) was to download all issues for scrapping and feeding to a local database, what time of day would be less disastrous for the server? :) Regards, Daniel

Now, getting into pie-in-the-sky territory, if someone (not logged in) was to download all issues for scrapping and feeding to a local database, what time of day would be less disastrous for the server? :)
I think HTML scraping is a really bad idea. What is it that you specifically want to do with these data? Regards, Martin

"Martin v. Löwis" wrote:
Now, getting into pie-in-the-sky territory, if someone (not logged in) was to download all issues for scrapping and feeding to a local database, what time of day would be less disastrous for the server? :)
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. With some more time and effort, I'd be able to: Organize a local workflow with tweaked UI

Daniel (ajax) Diniz wrote:
"Martin v. Löwis" wrote:
Now, getting into pie-in-the-sky territory, if someone (not logged in) was to download all issues for scrapping and feeding to a local database, what time of day would be less disastrous for the server? :)
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.
With some more time and effort, I'd be able to: Organize a local workflow with tweaked UI
Send emails before they were done :D Use a VCS for in-progress activities Figure out how to serialize and submit the work done locally Share results with interested parties off-tracker (e.g., the auto-nosy mentioned up-thread) Right now, more efficient searching and aggregation along with some (local, flexible) UI tweaks sum it up. Maybe I can offer a patch for something like PyPI's 'simple' interface? Cheers, Daniel

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

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

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

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

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.).
Please, please, no. If you can add it to an external application, please, pretty pretty please, add it to roundup directly (or, rather, to this specific tracker).
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.
If it's useful to you, it might be useful to others as well. So consider contributing free-form searches to roundup (in addition to form-based searches). Regards, Martin

Can http://bugs.python.org/issue995458 "Does not build selected SGI specific modules"be closed? PEP11 lists Irix 4 as gone. What about Irix 6? http://www.python.org/dev/peps/pep-0011/ Pep3108 notes that IRIX is no longer produced as of Dec 2006 and that Irix specific modules are gone from Py3. http://www.python.org/dev/peps/pep-3108/#irix Does Py3 still have Irix 6 support?

Irix is long dead and we don't support it in any form or version. On Sat, Feb 14, 2009 at 9:07 AM, Terry Reedy <tjreedy@udel.edu> wrote:
Can http://bugs.python.org/issue995458 "Does not build selected SGI specific modules"be closed?
PEP11 lists Irix 4 as gone. What about Irix 6? http://www.python.org/dev/peps/pep-0011/
Pep3108 notes that IRIX is no longer produced as of Dec 2006 and that Irix specific modules are gone from Py3. http://www.python.org/dev/peps/pep-3108/#irix Does Py3 still have Irix 6 support?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Irix is long dead and we don't support it in any form or version.
On Sat, Feb 14, 2009 at 9:07 AM, Terry Reedy <tjreedy@udel.edu> wrote:
Can http://bugs.python.org/issue995458 "Does not build selected SGI specific modules"be closed?
PEP11 lists Irix 4 as gone. What about Irix 6? http://www.python.org/dev/peps/pep-0011/
Pep3108 notes that IRIX is no longer produced as of Dec 2006 and that Irix specific modules are gone from Py3. http://www.python.org/dev/peps/pep-3108/#irix Does Py3 still have Irix 6 support?
I closed the tracker issue. I will let Martin update PEP11.

Terry Reedy wrote:
Guido van Rossum wrote:
Irix is long dead and we don't support it in any form or version.
I closed the tracker issue. I will let Martin update PEP11.
I think you misunderstand the purpose of PEP 11. It is not meant as a repository of platforms not longer supported, but a list of announcements of which systems will not be supported anymore in *upcoming* releases. It seems that the removal of Irix support has bypassed PEP 11. Perhaps the PEP should be withdrawn. Regards, Martin

Martin v. Löwis wrote:
Terry Reedy wrote:
Guido van Rossum wrote:
Irix is long dead and we don't support it in any form or version. I closed the tracker issue. I will let Martin update PEP11.
I think you misunderstand the purpose of PEP 11. It is not meant as a repository of platforms not longer supported,
However, that would be a useful purpose for people doing triage on tracker issues.
but a list of announcements of which systems will not be supported anymore in *upcoming* releases.
It seems that the removal of Irix support has bypassed PEP 11.
If the complete end of Irix support had been documented, I would not have had to ask and several other issues would have already been closed.
Perhaps the PEP should be withdrawn.
Please no. tjr

Terry Reedy wrote:
Can http://bugs.python.org/issue995458 "Does not build selected SGI specific modules"be closed?
PEP11 lists Irix 4 as gone. What about Irix 6? http://www.python.org/dev/peps/pep-0011/
Thank you, thank you, thank you :) Can I close these other IRIX issues? http://bugs.python.org/issue2048 http://bugs.python.org/issue1086642 http://bugs.python.org/issue1178510 http://bugs.python.org/issue1070140 Do you know of other OSes (among commercial Unix, mostly) that could also get the axe? Regards, Daniel

Daniel (ajax) Diniz wrote:
Can I close these other IRIX issues?
http://bugs.python.org/issue2048 http://bugs.python.org/issue1086642 http://bugs.python.org/issue1178510 http://bugs.python.org/issue1070140
So, I'll close these later this week (citing that "Irix is long dead and we don't support it in any form or version") unless opposition is voiced :) Daniel

[Sorry for stepping in so late] On Thu, Feb 12 2009 at 02:05:23PM BRST, "Daniel (ajax) Diniz" <ajaksu@gmail.com> wrote:
Victor Stinner wrote:
Oh, I realized that there is a component called "Unicode". So it should be possible to write a request to list all issues related to unicode.
Nice, I'll add set this component for issues that don't have it. I can still add people to these issues, if they want.
I think this one might be considered a Unicode issue: http://bugs.python.org/issue1293741 "doctest runner cannot handle non-ascii characters" rbp

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
participants (22)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Benjamin Peterson
-
Brett Cannon
-
Cesare Di Mauro
-
Daniel (ajax) Diniz
-
Daniel Stutzbach
-
Dino Viehland
-
Facundo Batista
-
Georg Brandl
-
Guido van Rossum
-
Jim Baker
-
Mark Dickinson
-
Raymond Hettinger
-
Rodrigo Bernardo Pimentel
-
Senthil Kumaran
-
Stephen J. Turnbull
-
Stephen Thorne
-
Steve Holden
-
Tarek Ziadé
-
Terry Reedy
-
Victor Stinner