Re: [Python-Dev] Tracker archeology

2009-02-13 Thread Georg Brandl
Daniel (ajax) Diniz schrieb:

 Over-spammig:
   Sorry, Georg! I only noticed all issues in the Documentation
 component are auto-assigned to you today. This meant dozens of unasked
 for assignments :-/

That's okay, I'll go through them at the weekend and just unassign what
I won't manage to do.

But the nice thing about documentation changes is that while writing the
change takes about as long as changing an equivalent piece of Python code,
there's no new test and waiting for the testsuite needed (except sometimes
a spellchecker wouldn't hurt), so it's much quicker :)

Thank you for your efforts, they are much appreciated!

Georg

___
Python-Dev mailing list
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] email package sprint?

2009-02-13 Thread Barry Warsaw

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The email package needs a lot of love, especially for Python 3.0.  I'm  
already signed up for two sprints for Pycon, but if there's enough  
interest I would try at least to find some time to talk with others  
about improving the email package.


Those of you who are going to Pycon, is anybody available to sprint a  
bit on email?


Barry

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

iQCVAwUBSZVz7nEjvBPtnXfVAQK7nwQArJMjC9TVxnuuZ+4kBBD3+1pqyXbnRKa/
/nuWCfrqsW5z/RGxWdPjHf/02TCdGXsnRwGhE8bjDgawL0VnO1lTZIXjovy6JvJ0
EpFX5P9TDCuXmcCpiKAk4xKBHo6SrlGpH9A264jTzVe2ri/twVKNBGyUn3eg4tYt
ERqH8QrXHok=
=1ntw
-END PGP SIGNATURE-
___
Python-Dev mailing list
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

2009-02-13 Thread Daniel (ajax) Diniz
Daniel (ajax) Diniz wrote:
 Martin v. Löwis wrote:
 I think HTML scraping is a really bad idea. What is it that you
 specifically want to do with these data?

 For starters, free form searches, aggregation and filtering of
 results. The web interface is pretty good for handling individual
 issues, but not so good for adding someone as nosy to lots of issues.

I should have thought of this earlier: I'm downloading A CSV file
(displaying all fields) with all issues and will insert that into a DB
(maybe through my local tracker instance). Thanks for asking the
'think about it' question! :)

Daniel
___
Python-Dev mailing list
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

2009-02-13 Thread Daniel (ajax) Diniz
Brett Cannon wrote:
 On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz aja...@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
___
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] Wow!

2009-02-13 Thread Kirk McDonald
http://en.wikipedia.org/wiki/Kessler_Syndrome

On Fri, Feb 13, 2009 at 1:12 PM, Raymond Hettinger pyt...@rcn.com wrote:


 http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story
 ___
 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/kirklin.mcdonald%40gmail.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

2009-02-13 Thread Martin v. Löwis
 For starters, free form searches, aggregation and filtering of
 results.

What is free form searches (example)? What is aggregation?
What results do you want to filter? (roundup can already filter
results quite well)

 The web interface is pretty good for handling individual
 issues, but not so good for adding someone as nosy to lots of issues.

Please consider contributing a mass-update template then, perhaps
based on search results, with check boxes to include or exclude
individual issues from the mass update.

Regards,
Martin
___
Python-Dev mailing list
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

2009-02-13 Thread Martin v. Löwis
  Send emails before they were done :D

Again: what's that?

  Use a VCS for in-progress activities

Hmm. Why do you need a database copy for that?

  Figure out how to serialize and submit the work done locally

Again, don't understand. too brief.

  Share results with interested parties off-tracker (e.g., the
 auto-nosy mentioned up-thread)

The tracker already has auto-assignments based on components.

 Right now, more efficient searching and aggregation along with some
 (local, flexible) UI tweaks sum it up.

Efficient in what way?

 Maybe I can offer a patch for something like PyPI's 'simple' interface?

Please, no. Contribute the interface you want locally instead as a
feature for all users of the tracker.

Regards,
Martin
___
Python-Dev mailing list
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] Adding T_SIZET to structmember.h

2009-02-13 Thread Martin v. Löwis
 Mark, the patch is not trivial, I cannot spend time on this until this
 is accepted. Hope you understand.

I certainly do understand. So it's likely not going to happen.

Regards,
Martin
___
Python-Dev mailing list
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] Small misleadingness in docs

2009-02-13 Thread Greg Ewing

I've discovered something slightly misleading in the docs
for PyObject_IsInstance:

  When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
  returns true. If A and B are different objects, B‘s __bases__
  attribute is searched...

This suggests that issubclass(A, A) will always be true,
regardless of what attributes A has. However, this turns
out not to be so -- A must also have a __bases__ attribute,
otherwise it's rejected as not being sufficiently class-like.

--
Greg

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


Re: [Python-Dev] Small misleadingness in docs

2009-02-13 Thread Raymond Hettinger


[Greg Ewing]

I've discovered something slightly misleading in the docs
for PyObject_IsInstance:

  When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
  returns true. If A and B are different objects, B‘s __bases__
  attribute is searched...

This suggests that issubclass(A, A) will always be true,
regardless of what attributes A has. However, this turns
out not to be so -- A must also have a __bases__ attribute,
otherwise it's rejected as not being sufficiently class-like.


This smells like a bug that brings issubclass() out of sync with isinstance().
Perhaps issubclass() should do what the docs say and start by
testing whether A and B are the same object.


Raymond 


___
Python-Dev mailing list
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] Wow!

2009-02-13 Thread Brett Cannon
Is there a Python connection I'm missing?

On Fri, Feb 13, 2009 at 13:12, Raymond Hettinger pyt...@rcn.com wrote:


 http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story
 ___
 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/brett%40python.org

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


Re: [Python-Dev] Small misleadingness in docs

2009-02-13 Thread Greg Ewing

Raymond Hettinger wrote:

This smells like a bug that brings issubclass() out of sync with 
isinstance().


No, it affects both isinstance() and issubclass().
They both raise a TypeError if the purported class
object doesn't have a __bases__ attribute that is
a tuple.

This isn't necessarily wrong, but perhaps the docs
could be re-worded slightly to make this clearer.

Another thing is that this whole paragraph only
appears in the Python/C API reference, not in the
docs for the Python isinstance and issubclass
functions, where the docs imply that only genuine
class or type objects are accepted.

And nowhere does it mention that __bases__ must
be a tuple.

--
Greg
___
Python-Dev mailing list
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] Wow!

2009-02-13 Thread Greg Ewing

Brett Cannon wrote:


Is there a Python connection I'm missing?


http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story


Well, the front page of python.org does say NASA uses Python...

Also it sounds like they could do with a really good
garbage collection algorithm just now.

--
Greg
___
Python-Dev mailing list
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] RELEASED Python 3.0.1

2009-02-13 Thread Barry Warsaw

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the  
availability of Python 3.0.1, the first bug fix release of Python  
3.0.  Version 3.0.1 fixes dozens of bugs reported since the release of  
Python 3.0 on December 3rd, 2008.


Python 3.0 represents a major milestone in Python's history.  This new  
version of the language is incompatible with the 2.x line of releases,  
while remaining true to BDFL Guido van Rossum's vision.


For more information, links to documentation, and downloadable  
distributions, see the Python 3.0.1 release page:


http://www.python.org/download/releases/3.0.1/

To report bugs in Python 3.0.1, please submit them to the issue  
tracker at:


http://bugs.python.org/

Enjoy!
Barry

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

iQCVAwUBSZYpSnEjvBPtnXfVAQLQwgP/WSHp12dJVpEYtEOL/X8ynCQACriij9AM
PgT6SacbMJLbsy84CTGA1lxF4NdEUQMY1IYz0do/aZ0+nBkSoy7SlkOVcncysLSC
hVyTVlWQBdh63yA8QUk1I5dMbKeNpbCqRRgvSHaBrVdVz9mDM/r/L+j9lhBW4Cam
2lHLjRdQaG0=
=vy0O
-END PGP SIGNATURE-
___
Python-Dev mailing list
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] The fate of 3.0.*

2009-02-13 Thread Benjamin Peterson
Are we going to keep developing the 3.0 maintenance branch in
expectation of releasing 3.0.2 sometime or will we just focus our
efforts on 3.1?

-- 
Regards,
Benjamin
___
Python-Dev mailing list
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] The fate of 3.0.*

2009-02-13 Thread Brett Cannon
On Fri, Feb 13, 2009 at 18:35, Benjamin Peterson benja...@python.orgwrote:

 Are we going to keep developing the 3.0 maintenance branch in
 expectation of releasing 3.0.2 sometime or will we just focus our
 efforts on 3.1?


I almost said of course we are, but then I realized that 3.1 is going to
be very similar to 3.0.1 such that doing a final 3.0.x release probably is
not going to be worth it. Lord knows I sure don't want to have to port a bug
fix to *five* branches.

-Brett
___
Python-Dev mailing list
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] The fate of 3.0.*

2009-02-13 Thread Guido van Rossum
On Fri, Feb 13, 2009 at 6:49 PM, Brett Cannon br...@python.org wrote:
 On Fri, Feb 13, 2009 at 18:35, Benjamin Peterson benja...@python.org
 wrote:

 Are we going to keep developing the 3.0 maintenance branch in
 expectation of releasing 3.0.2 sometime or will we just focus our
 efforts on 3.1?

 I almost said of course we are, but then I realized that 3.1 is going to
 be very similar to 3.0.1 such that doing a final 3.0.x release probably is
 not going to be worth it. Lord knows I sure don't want to have to port a bug
 fix to *five* branches.

Amen. I can see two scenarios where we might release 3.0.2: (a) if we
find a really severe error in 3.0.1 (or perhaps a security problem);
(b) if 3.1 ends up getting delayed severely.

In case (a) happens it's okay if the 3.0 branch is left alone until
the time we need to make that one patch. The probability of (b) is
low, so let's worry about that when it happens, and let's try not to
make it happen. :-)

Congratulations all with the release!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
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] The fate of 3.0.*

2009-02-13 Thread Antoine Pitrou
Benjamin Peterson benjamin at python.org writes:
 
 Are we going to keep developing the 3.0 maintenance branch in
 expectation of releasing 3.0.2 sometime or will we just focus our
 efforts on 3.1?

Focusing on 3.1 should be ok.
So what are the expected efforts for 3.1?
- io-in-C 
- import-in-Python
- ... anything else?

Regards

Antoine.


___
Python-Dev mailing list
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] The fate of 3.0.*

2009-02-13 Thread Andrew McNamara
So what are the expected efforts for 3.1?
- io-in-C 
- import-in-Python
- ... anything else?

A fixed email module.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] RELEASED Python 3.0.1

2009-02-13 Thread Benjamin Kaplan
On Fri, Feb 13, 2009 at 9:15 PM, Barry Warsaw ba...@python.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On behalf of the Python development team, I'm happy to announce the
 availability of Python 3.0.1, the first bug fix release of Python 3.0.
  Version 3.0.1 fixes dozens of bugs reported since the release of Python 3.0
 on December 3rd, 2008.

 Python 3.0 represents a major milestone in Python's history.  This new
 version of the language is incompatible with the 2.x line of releases, while
 remaining true to BDFL Guido van Rossum's vision.

 For more information, links to documentation, and downloadable
 distributions, see the Python 3.0.1 release page:

http://www.python.org/download/releases/3.0.1/

 To report bugs in Python 3.0.1, please submit them to the issue tracker at:

http://bugs.python.org/

 Enjoy!
 Barry



Any chance of getting a Mac installer for this one?
___
Python-Dev mailing list
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

2009-02-13 Thread Daniel (ajax) Diniz
Hi Martin,
Sorry about being so brief, I got a lot of unexpected interruptions
and was rushing things.

Martin v. Löwis wrote:
 For starters, free form searches, aggregation and filtering of
 results.

 What is free form searches (example)? What is aggregation?
 What results do you want to filter? (roundup can already filter
 results quite well)

By free form searches I meant complex queries with more flexible criteria.

A real example: find any issue that has words A and B in juxtaposed
in messages, containing words starting with 'url' [ but not ending
with 'lib' in title (, unless version = 3)], where jjlee isn't nosy.
Or issues with less than 5 replies, all from a single user. Lastly,
issues where no Developer is nosy, with messages covering an interval
longer than a week.

These are useful a few times, but hard to predict and not so recurrent
searches, so free form makes more sense than adding support for each
combination.

By aggregation I meant performing a few disjunct searches and
combining them in a result set, eliminating duplication, to process as
a unit. Then, add issues A,B and C to that. Free form searches cover
this by allowing one to perform a query that gives the result set
directly, but combining previous searches sounds more pleasant.

And by filtering, I meant refining a set of search results and/or
searching over a restricted set of issues, on criteria that are
present in them. I.e., I'd like to search for segfault and be given a
choice box with the all nosy people in  the result set, and exclude or
only display issues  based choosing one of them.

All of the above seems trivial with a database-like interface. I have
pretty much emulated them with the current search, the handy CSV
results downloads, a text editor and a Python shell.

 The web interface is pretty good for handling individual
 issues, but not so good for adding someone as nosy to lots of issues.

 Please consider contributing a mass-update template then, perhaps
 based on search results, with check boxes to include or exclude
 individual issues from the mass update.

OK, I saw one of these at http://roundup.sf.net/ and will study and
adapt it. But it'll solve the 'commit changes' part of the equation,
not the 'select set of issues to change'.

  Send emails before they were done :D

 Again: what's that?

That's me trying to sound witty after sending the email before finishing it :)

  Use a VCS for in-progress activities

 Hmm. Why do you need a database copy for that?

I don't, the database if for selecting issues to edit. But I'd like to
be able to submit bulk changes, and a (local, D) VCS is how I imagine
storing these locally should be done. For rollbacks, merges and that
sort of thing, besides being able to save incomplete work to continue
later.

  Figure out how to serialize and submit the work done locally

 Again, don't understand. too brief.

The serialization idea comes from this: one would assemble a 'patch'
containing different changes to different issues. It's an extension of
the mass-update idea, but for non-uniform changes. The deserialization
would either happen through a mass-update interface or by running a
script to submit them one by one.

  Share results with interested parties off-tracker (e.g., the
 auto-nosy mentioned up-thread)

 The tracker already has auto-assignments based on components.

But no way to share aggregated search results (I've sent some
off-list), 'follow' users (i.e., be added as nosy for issues where
user A is nosy), auto-add as nosy based on keywords, etc. Someday we
could have these nosy features hosted externally, e.g. as an AppEngine
app that subscribes to python-bugs and sends alerts to users matching
the message (by keyword, performed action, new stage, etc.).

 Right now, more efficient searching and aggregation along with some
 (local, flexible) UI tweaks sum it up.

 Efficient in what way?

Having those complex searches in a less convoluted workflow, allowing
more work to be done faster and in a less error prone way.

 Maybe I can offer a patch for something like PyPI's 'simple' interface?

 Please, no. Contribute the interface you want locally instead as a
 feature for all users of the tracker.

OK, after some more cleaning up I'll work on the mass-update, my local
searches and report back.

Regards,
Daniel
___
Python-Dev mailing list
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

2009-02-13 Thread Daniel (ajax) Diniz
Daniel (ajax) Diniz wrote:
 Status report and roadmap to be posted later today, before date +%s
 turns 1234567890 :)

Missed that and got almost no tracker work done. Postponed to Monday,
after some weekend cleaning.

Daniel
___
Python-Dev mailing list
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