Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

"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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

> 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Steve Holden]

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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz  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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 16:22, Stephen J. Turnbull 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Stephen J. Turnbull]

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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
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] patch to make IDLE load IDLESTARTUP/PYTHONSTARTUP on restart

[Mitchell L Model]

I have submitted patches to idlelib/PyShell.py for Python 2.7 (Issue 
5233) and 3.1 (5234), made against local repository copies as updated 
an hour ago. The purpose of the patch is to have IDLE load 
IDLESTARTUP or PYTHONSTARTUP on restart.


Along the way I also made -s the default so IDLESTARTUP or 
PYTHONSTARTUP gets loaded when IDLE is started by double-clicking 
rather than from the command line (no reasonable way for the user to 
get the -s switch into IDLE.app on the Mac). I decided that on 
restart IDLE should load the file that was loaded when it started in 
the first place, on the off chance that something had changed in the 
interim.


I changed the meaning of the -s switch to take an argument that is an 
alternate startup file to load instead of IDLESTARTUP or 
PYTHONSTARTUP. It might be better, though, to leave -s as it is and 
mark it deprecated or obsolete or the default or whatever and use a 
different letter to specify a load file.


I added a switch -q to suppress loading of the startup file.

___
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] .Idle.py init file

[Mitchell L Model]

I was trying to disentangle some IDLE behavior today and discovered 
that If the user has a .Idle.py file IDLE will run it when it starts 
up. This is independent of running IDLESTARTUP or PYTHONSTARTUP when 
the -s switch is given. It is run by Tk.readprofile as called from 
Tk.__init__. The "Idle" comes from the name passed to TK() when 
PyShell.py creates its Tk root. In fact, not only is it independent, 
but it works differently: any imports done in .Idle.py go into Tk's 
name space, whereas IDLESTARTUP/PYTHONSTARTUP is exec'd and imports 
go into the interpreter's namespace.


I don't think this behavior is documented anywhere, although since I 
had a .Idle.py file I must have seen something about this somewhere 
at some point. It's very hard to search for ".Idle.py" when "idle.py" 
is a file whose name appears frequently in discussions.


Is this something that I should submit as an Issue or is it widely 
known behavior? It should at least be documented.

___
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] Adding T_SIZET to structmember.h

[Lisandro Dalcin]

After a rather long hacking on Cython in order to support 'Py_ssize_t'
and 'size_t' the right way, 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?



-- 
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
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] 3.0.1 and 2.6.2

[Jesse Noller]

On Thu, Feb 12, 2009 at 1:57 PM, Barry Warsaw  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 12, 2009, at 1:44 PM, Brett Cannon wrote:
>
>> What about the segfault problem? Shouldn't that get in?
>
> If it can be done without a regression, yes.  Do it now and that will give
> the buildbots time to run.  If they go red, we'll back it out.
>
> Barry
>

I am waiting for the tests to complete, and then I will check in the merge.
___
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] 3.0.1 and 2.6.2

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 12, 2009, at 1:44 PM, Brett Cannon wrote:


What about the segfault problem? Shouldn't that get in?


If it can be done without a regression, yes.  Do it now and that will  
give the buildbots time to run.  If they go red, we'll back it out.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZRxDnEjvBPtnXfVAQLJCQP/d+BUqjwxHDyK0Dv8i7TlgoYfjHCgCu/M
zQVrMihB3lyoem7os2VdGubButLwOoMP69uU9Rieo62Fag1bxF6ME2HJC6dgJ3ge
xUwRD+01hCkkWNeONdYN/cANjkezE7i4O9z7YyGVJuktO3ZbdY/vjYbY/HE2ZrGK
+wguhd06tA0=
=c6q3
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

>> 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
___
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] 3.0.1 and 2.6.2

[Brett Cannon]

On Thu, Feb 12, 2009 at 10:40, Barry Warsaw  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 12, 2009, at 1:29 PM, Jesse Noller wrote:
>
>  On Thu, Feb 12, 2009 at 1:20 PM, Antoine Pitrou 
>> wrote:
>>
>>> Jesse Noller  gmail.com> writes:
>>>

 I'm afraid I've gone branch-stupid. I have a a few changes that should
 be on the boat for the next release, but I can't for the life of me
 remember which branch to push to - right now the changes are on trunk
 and py3k.

>>>
>>> The next release (3.0.1) is tomorrow. Unless those changes are really
>>> important,
>>> I humbly advocate deferring them to after tomorrow, for fear that they
>>> introduce
>>> last-minute breakage.
>>>
>>> (the branch names are release26-maint and release30-maint, if that's what
>>> you're
>>> asking :-))
>>>
>>>
>> The changes have been stable since checked in, I have no problems
>> holding off, but they're also not big. Doc changes, fixes to the
>> logger and a segfault fix mainly. I have no problem holding off.
>>
>
> The documentation change is probably safe.  Given that I'm tagging 3.0.1 in
> about 4.5 hours, please be very conservative with any other changes.
>

What about the segfault problem? Shouldn't that get in?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0.1 and 2.6.2

[Jesse Noller]

On Thu, Feb 12, 2009 at 1:40 PM, Barry Warsaw  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 12, 2009, at 1:29 PM, Jesse Noller wrote:
>
>> On Thu, Feb 12, 2009 at 1:20 PM, Antoine Pitrou 
>> wrote:
>>>
>>> Jesse Noller  gmail.com> writes:

 I'm afraid I've gone branch-stupid. I have a a few changes that should
 be on the boat for the next release, but I can't for the life of me
 remember which branch to push to - right now the changes are on trunk
 and py3k.
>>>
>>> The next release (3.0.1) is tomorrow. Unless those changes are really
>>> important,
>>> I humbly advocate deferring them to after tomorrow, for fear that they
>>> introduce
>>> last-minute breakage.
>>>
>>> (the branch names are release26-maint and release30-maint, if that's what
>>> you're
>>> asking :-))
>>>
>>
>> The changes have been stable since checked in, I have no problems
>> holding off, but they're also not big. Doc changes, fixes to the
>> logger and a segfault fix mainly. I have no problem holding off.
>
> The documentation change is probably safe.  Given that I'm tagging 3.0.1 in
> about 4.5 hours, please be very conservative with any other changes.
>
> Barry
>

I'm going to hold off. But now I know, and knowing is half the battle.
___
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] 3.0.1 and 2.6.2

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 12, 2009, at 1:29 PM, Jesse Noller wrote:

On Thu, Feb 12, 2009 at 1:20 PM, Antoine Pitrou  
 wrote:

Jesse Noller  gmail.com> writes:


I'm afraid I've gone branch-stupid. I have a a few changes that  
should

be on the boat for the next release, but I can't for the life of me
remember which branch to push to - right now the changes are on  
trunk

and py3k.


The next release (3.0.1) is tomorrow. Unless those changes are  
really important,
I humbly advocate deferring them to after tomorrow, for fear that  
they introduce

last-minute breakage.

(the branch names are release26-maint and release30-maint, if  
that's what you're

asking :-))



The changes have been stable since checked in, I have no problems
holding off, but they're also not big. Doc changes, fixes to the
logger and a segfault fix mainly. I have no problem holding off.


The documentation change is probably safe.  Given that I'm tagging  
3.0.1 in about 4.5 hours, please be very conservative with any other  
changes.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZRtMnEjvBPtnXfVAQKIMAP+MgyP05QgaRJ52+oonlusZVDEGilrJPN8
7HZxT8Mh/zuYUXiizcZqYxYErj+GNfiM9vIBegLrPz9L+DvZfKCvNiOHcKFzdNxU
b01XBYi82gylsZ9Xeou2CKZrppquyP/Ug+1GIMsrScCyE0YSz9Jk1E/YIZ8wsJd0
AiDGuFOYmjI=
=fRRY
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 05:08, Daniel (ajax) Diniz  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
___
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] 3.0.1 and 2.6.2

[Jesse Noller]

On Thu, Feb 12, 2009 at 1:20 PM, Antoine Pitrou  wrote:
> Jesse Noller  gmail.com> writes:
>>
>> I'm afraid I've gone branch-stupid. I have a a few changes that should
>> be on the boat for the next release, but I can't for the life of me
>> remember which branch to push to - right now the changes are on trunk
>> and py3k.
>
> The next release (3.0.1) is tomorrow. Unless those changes are really 
> important,
> I humbly advocate deferring them to after tomorrow, for fear that they 
> introduce
> last-minute breakage.
>
> (the branch names are release26-maint and release30-maint, if that's what 
> you're
> asking :-))
>

The changes have been stable since checked in, I have no problems
holding off, but they're also not big. Doc changes, fixes to the
logger and a segfault fix mainly. I have no problem holding off.

r68862 | jesse.noller | 2009-01-22 16:53:22 -0500 (Thu, 22 Jan 2009) | 1 line

Issue 4593: apply() documentation is unclear

r68839 | jesse.noller | 2009-01-20 21:08:17 -0500 (Tue, 20 Jan 2009) | 1 line

Issue 5009: multiprocessing: failure in manager._debug_info()

r68787 | jesse.noller | 2009-01-19 19:16:38 -0500 (Mon, 19 Jan 2009) | 1 line

issue 5002: fix windows warning that I intro'ed with r68768

r68768 | jesse.noller | 2009-01-19 10:12:22 -0500 (Mon, 19 Jan 2009) | 1 line

Resolve issue 3321: (segfault) _multiprocessing.Connection() doesn't
check handle

r68737 | jesse.noller | 2009-01-18 16:04:36 -0500 (Sun, 18 Jan 2009) | 1 line

issue 4301: patch logging to add processName, remove the old
_check_logger_class code

r68708 | jesse.noller | 2009-01-17 21:45:38 -0500 (Sat, 17 Jan 2009) | 1 line

Resolve issue 4449: AssertionError in mp_benchmarks.py

___
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] 3.0.1 and 2.6.2

[Antoine Pitrou]

Jesse Noller  gmail.com> writes:
> 
> I'm afraid I've gone branch-stupid. I have a a few changes that should
> be on the boat for the next release, but I can't for the life of me
> remember which branch to push to - right now the changes are on trunk
> and py3k.

The next release (3.0.1) is tomorrow. Unless those changes are really important,
I humbly advocate deferring them to after tomorrow, for fear that they introduce
last-minute breakage.

(the branch names are release26-maint and release30-maint, if that's what you're
asking :-))

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 3.0.1 and 2.6.2

[Jesse Noller]

I'm afraid I've gone branch-stupid. I have a a few changes that should
be on the boat for the next release, but I can't for the life of me
remember which branch to push to - right now the changes are on trunk
and py3k.

-jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [issue2263] struct.pack() + numpy int raises SystemError

[grubert]

hello,

i took a look at unassigned open issue with the oldest activity
this happened to be issue2263

Original bug report:

  struct.pack() raises SystemError when fed a numpy integer in some cases.
  The following was run on MacOSX 10.4, little endian (I can only
  reproduce the error if I specify big endian for the struct format). Not
  sure if this could be a numpy bug.

i checked on ubuntu 8.04, Python 2.7a0 (trunk:69044) and numpy 1.2.1
and found

* signed always works, longlong also.
* unsigned native works half of the time
* unsigned little/big endian never works

digging into the source, for pack "B", ">B" and "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]

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
___
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] multiprocessing not compatible with functional.partial

[Jesse Noller]

On Feb 12, 2009, at 10:58 AM, Neal Becker  wrote:

Is it possible to get a better error message (regarding the pickle- 
ability)?





Sure, most of the time it does have a better error msg.
___
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] multiprocessing not compatible with fu nctional.partial

[Neal Becker]

Is it possible to get a better error message (regarding the pickle-ability)?


___
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] multiprocessing not compatible with functional.partial

[Neal Becker]

Hrvoje Niksic wrote:

> Calvin Spealman wrote:
>> I don't think it would be unreasonable to consider either 1) making
>> functools.partial picklable (I don't know how feasible this is)
> 
> It's not only feasible, but quite easy and, I think, useful.  A
> "partial" instance is a simple triplet of (function, args, kwds), and it
> can be pickled as such.  For example:
> 
>  >>> import copy_reg, functools
>  >>> def _reconstruct_partial(f, args, kwds):
> ... return functools.partial(f, *args, **(kwds or {}))
> ...
>  >>> def _reduce_partial(p):
> ... return _reconstruct_partial, (p.func, p.args, p.keywords)
> ...
>  >>> copy_reg.pickle(functools.partial, _reduce_partial)
> 
> Test:
> 
>  >>> import operator, cPickle as cp
>  >>> p = functools.partial(operator.add, 3)
>  >>> p(10)
> 13
>  >>> cp.dumps(p)
> 
'c__main__\n_reconstruct_partial\np1\n(coperator\nadd\np2\n(I3\ntp3\nNtRp4\n.'
>  >>> p2 = cp.loads(_)
>  >>> p2(10)
> 13
> 
> Iedally this should be implemented in the functools.partial object itself.
Confirmed:

from multiprocessing import Pool

def power (x, pwr=2):
return x**pwr

import functools
run_test = functools.partial (power, pwr=3)

import copy_reg, functools
def _reconstruct_partial(f, args, kwds):
return functools.partial(f, *args, **(kwds or {}))

def _reduce_partial(p):
return _reconstruct_partial, (p.func, p.args, p.keywords)

copy_reg.pickle(functools.partial, _reduce_partial)

if __name__ == "__main__":

pool = Pool()
cases = [3,4,5]
results = pool.map (run_test, cases)
print results

$python test_multi.py
[27, 64, 125]


___
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] multiprocessing not compatible with functional.partial

[Hrvoje Niksic]

Calvin Spealman wrote:

I don't think it would be unreasonable to consider either 1) making
functools.partial picklable (I don't know how feasible this is)


It's not only feasible, but quite easy and, I think, useful.  A 
"partial" instance is a simple triplet of (function, args, kwds), and it 
can be pickled as such.  For example:


>>> import copy_reg, functools
>>> def _reconstruct_partial(f, args, kwds):
... return functools.partial(f, *args, **(kwds or {}))
...
>>> def _reduce_partial(p):
... return _reconstruct_partial, (p.func, p.args, p.keywords)
...
>>> copy_reg.pickle(functools.partial, _reduce_partial)

Test:

>>> import operator, cPickle as cp
>>> p = functools.partial(operator.add, 3)
>>> p(10)
13
>>> cp.dumps(p)
'c__main__\n_reconstruct_partial\np1\n(coperator\nadd\np2\n(I3\ntp3\nNtRp4\n.'
>>> p2 = cp.loads(_)
>>> p2(10)
13

Iedally this should be implemented in the functools.partial object itself.
___
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] multiprocessing not compatible with functional.partial

[Jesse Noller]

On Thu, Feb 12, 2009 at 9:22 AM, Calvin Spealman  wrote:
> On Thu, Feb 12, 2009 at 9:06 AM, Christian Heimes  wrote:
>> Neal Becker schrieb:
>>> If the argument to pool.map (f, args)
>>> is
>>> f = functional.partial (my_func, some_keyword_arg=whatever)
>>>
>>> I get:
>>>
>>> Traceback (most recent call last):
>>>   File 
>>> "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>>> self.run()
>>>   File 
>>> "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>>> self._target(*self._args, **self._kwargs)
>>>   File 
>>> "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>>> task = get()
>>>   File 
>>> "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>>> return recv()
>>> TypeError: type 'partial' takes at least one argument
>>
>> functool.partial instances are not picklable. You have to teach
>> multiprocessing how to serialize a functool.partial instance.
>
> I don't think it would be unreasonable to consider either 1) making
> functools.partial picklable (I don't know how feasible this is) or 2)
> having multiprocessing, specifically, handle more stdlib types that
> are likely to be used here.
>
> Of course, if we get into "this is an extended set of types safe for
> multiprocessing", we are likely to see more problems between versions
> as a more difficult backwards compat target. So, maybe both are more
> harm than good?

While maintaining a back port which contains all of the current and
future functionality is an admirable goal, the fact is is that over
time, there will simply be features added which will only work on
current+future, and not be able to be back ported.

Case in point, I want to look into adding a lot more contextmanager
support into the module - this can work back to 2.5, but not further
than that.

.02 cents.

-jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] multiprocessing not compatible with functional.partial

[Calvin Spealman]

On Thu, Feb 12, 2009 at 9:06 AM, Christian Heimes  wrote:
> Neal Becker schrieb:
>> If the argument to pool.map (f, args)
>> is
>> f = functional.partial (my_func, some_keyword_arg=whatever)
>>
>> I get:
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>> self.run()
>>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>> self._target(*self._args, **self._kwargs)
>>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>> task = get()
>>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
>> return recv()
>> TypeError: type 'partial' takes at least one argument
>
> functool.partial instances are not picklable. You have to teach
> multiprocessing how to serialize a functool.partial instance.

I don't think it would be unreasonable to consider either 1) making
functools.partial picklable (I don't know how feasible this is) or 2)
having multiprocessing, specifically, handle more stdlib types that
are likely to be used here.

Of course, if we get into "this is an extended set of types safe for
multiprocessing", we are likely to see more problems between versions
as a more difficult backwards compat target. So, maybe both are more
harm than good?

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
___
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] multiprocessing not compatible with functional.partial

[Christian Heimes]

Neal Becker schrieb:
> If the argument to pool.map (f, args)
> is
> f = functional.partial (my_func, some_keyword_arg=whatever)
> 
> I get:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
> self.run()
>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
> self._target(*self._args, **self._kwargs)
>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
> task = get()
>   File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
> return recv()
> TypeError: type 'partial' takes at least one argument

functool.partial instances are not picklable. You have to teach
multiprocessing how to serialize a functool.partial instance.

Christian

___
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] multiprocessing not compatible with functional.partial

[Neal Becker]

If the argument to pool.map (f, args)
is
f = functional.partial (my_func, some_keyword_arg=whatever)

I get:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
self.run()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
task = get()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux-
return recv()
TypeError: type 'partial' takes at least one argument

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Victor Stinner]

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/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 12, 2009, at 7:52 AM, Benjamin Peterson wrote:

On Thu, Feb 12, 2009 at 6:28 AM, Daniel (ajax) Diniz  
 wrote:

Barry Warsaw wrote:
A quick reminder that I am planning to release Python 3.0.1 this  
Friday, February 13.


Cool :)

Should I hold the tracker cleanup until then (the posting part, not
the searching)? I'd hate to bury some important report in a sea of
ancientness.


No, don't worry. We can just search issues by priority.


That's fine.  All I care about at this point are show stoppers for 3.0.

Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZQdvHEjvBPtnXfVAQLeTQP/VhiWIv8KIM2nGyEQaO7HylGkblMtcQ1J
fBbhbJ4lwcvstRjrCYsHN8TKWhhUZnxDtXVigV3vvLHRX5SfYj/oV5oL0tWPfw5i
183oXNk2RIMmlP/oMSPK8OVgS01nt7wmj1RdkDBx6hq0r6TnIBV90JjPT45H06rB
wzXsy/Fw/mw=
=oXeZ
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

[Benjamin Peterson]

On Thu, Feb 12, 2009 at 6:28 AM, Daniel (ajax) Diniz  wrote:
> Barry Warsaw wrote:
>> A quick reminder that I am planning to release Python 3.0.1 this Friday, 
>> February 13.
>
> Cool :)
>
> Should I hold the tracker cleanup until then (the posting part, not
> the searching)? I'd hate to bury some important report in a sea of
> ancientness.

No, don't worry. We can just search issues by priority.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

[Daniel (ajax) Diniz]

Barry Warsaw wrote:
> A quick reminder that I am planning to release Python 3.0.1 this Friday, 
> February 13.

Cool :)

Should I hold the tracker cleanup until then (the posting part, not
the searching)? I'd hate to bury some important report in a sea of
ancientness.

Daniel

PS: Are you aiming at  23:31:30 UTC ? :)
___
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] test_tk failing

[Guilherme Polo]

On Thu, Feb 12, 2009 at 6:59 AM, Raymond Hettinger  wrote:
> C:\py27>py27 lib\test\regrtest.py -uall test_tk
> test_tk
> test test_tk failed -- Traceback (most recent call last):
>  File "c:\py27\lib\lib-tk\test\test_tkinter\test_text.py", line 32, in
> test_search
>   self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
> AssertionError:  != '1.2'
>
> 1 test failed:
>   test_tk
> [35724 refs]
>
>
>
>
> C:\py31>py31 lib\test\regrtest.py -uall test_tk
> test_tk
> test test_tk failed -- Traceback (most recent call last):
>  File "c:\py31\lib\tkinter\test\test_tkinter\test_text.py", line 32, in
> test_search
>   self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
> AssertionError:  != '1.2'
>
> 1 test failed:
>   test_tk
> [73837 refs]

http://bugs.python.org/issue5193



-- 
-- Guilherme H. Polo Goncalves
___
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_tk failing

[Raymond Hettinger]

C:\py27>py27 lib\test\regrtest.py -uall test_tk
test_tk
test test_tk failed -- Traceback (most recent call last):
 File "c:\py27\lib\lib-tk\test\test_tkinter\test_text.py", line 32, in 
test_search
   self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
AssertionError:  != '1.2'

1 test failed:
   test_tk
[35724 refs]




C:\py31>py31 lib\test\regrtest.py -uall test_tk
test_tk
test test_tk failed -- Traceback (most recent call last):
 File "c:\py31\lib\tkinter\test\test_tkinter\test_text.py", line 32, in 
test_search
   self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
AssertionError:  != '1.2'

1 test failed:
   test_tk
[73837 refs]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Victor Stinner]

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/
___
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