Re: [Python-Dev] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().

2011-03-28 Thread Daniel Stutzbach 
On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan  wrote:

> On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach 
> wrote:
> > Is there a good use-case for the func argument?
>


> The examples that Raymond gives in the docs (cumulative
> multiplication, running min/max, cash flow accumulation) look fairly
> solid to me.


(I had the nagging suspicion that I was making a blunder in my email, but I
couldn't see it despite rereading my email several times before sending.  My
blunder was in not rereading the patch to see the examples.  Anyway...)

When would a running product, min, or max be useful?

for running_min in accumulate(data, min):
# Do what?

-- 
Daniel Stutzbach
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().

2011-03-28 Thread Raymond Hettinger 

On Mar 28, 2011, at 12:38 AM, Daniel Stutzbach wrote:

> On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan  wrote:
> On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach  
> wrote:
> > Is there a good use-case for the func argument?
>  
> The examples that Raymond gives in the docs (cumulative
> multiplication, running min/max, cash flow accumulation) look fairly
> solid to me.
> 
> (I had the nagging suspicion that I was making a blunder in my email, but I 
> couldn't see it despite rereading my email several times before sending.  My 
> blunder was in not rereading the patch to see the examples.  Anyway...)
> 
> When would a running product, min, or max be useful?

There's no need to speculate.  This API has long been present in other 
languages and libraries.

Do a google code search for R's builtin functions cumsum, cumprod, cummin, and 
cummax. Look at mumpy's accumulate ufunc which works with many operators. APL 
and K also have an accumulate tool which takes arbitrary functions.

Or consider as an API principle that there should be s useful default (addition 
in this case) and also hooks or parameters provided so that users don't have to 
do backflips to override hard-wired behaviors.


Raymond  

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

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Paul Moore 
On 27 March 2011 20:15, Neil Schemenauer  wrote:
> Guido van Rossum  wrote:
>> What is "rebase"? Why does everyone want it and hate it at the same time?
[...]
> The other school, which I am a member of, considers a logical
> development sequence more important than actual development history.
> I like to see a feature or fix developed in smallish, logical steps
> and I'm willing to spend a lot of time to rewrite patches to make it
> happen.  IMO, future maintainers will thank you for the effort.

This philosophy is essentially what the "mq" extension to Mercurial
tries to capture. In mq, you maintain a series of patches "on top of"
your repository, amending, refining and rebasing them as you wish
until they are ready to commit, at which time you take them off the
patch queue and convert them into final commits in the repository.

The one downside of mq is that you do not get the usual benefits of
distributed version control - local commits of your work, branching to
manage experiments, etc. This isn't really surprising, as that sort of
"messy" development doesn't really fit with a nice clean picture of
logical and well-defined patches (at least, it doesn't fit easily
enough that it can be automated :-)). There is a facility in mq to try
to integrate the two, by versioning your patch queue, but that makes
my head hurt, so I can't really comment on how useful that is...

For people in the "clean history" school, I'd recommend looking at mq
for your personal use. But it's definitely an advanced feature of
Mercurial, so it may be better to understand core Mercurial (and at
least temporarily accept that Mercurial is based on the "keep all
history" school of thought, or you'll struggle to match the
assumptions of the documentation to your thinking :-)) before diving
into mq.

Paul.

PS You can do everything that mq provides using core Mercurial
commands - and in theory, do it more safely - but it won't necessarily
fit the way you think quite as well...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Nick Coghlan 
On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore  wrote:
> For people in the "clean history" school, I'd recommend looking at mq
> for your personal use. But it's definitely an advanced feature of
> Mercurial, so it may be better to understand core Mercurial (and at
> least temporarily accept that Mercurial is based on the "keep all
> history" school of thought, or you'll struggle to match the
> assumptions of the documentation to your thinking :-)) before diving
> into mq.

I'm seeing if I can get the best of both worlds by having a public
sandbox repo where I work on things (which has the full messy history
of development on its feature branches), and then just drop them into
the main repo as coherent patches. Once I land a patch, I'll close the
original feature branch in the sandbox, so merge conflicts won't be an
issue.

Mercurial makes merging easy enough that I'm happy with the way that
approach is working so far.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Paul Moore 
On 28 March 2011 11:35, Nick Coghlan  wrote:
> On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore  wrote:
>> For people in the "clean history" school, I'd recommend looking at mq
>> for your personal use. But it's definitely an advanced feature of
>> Mercurial, so it may be better to understand core Mercurial (and at
>> least temporarily accept that Mercurial is based on the "keep all
>> history" school of thought, or you'll struggle to match the
>> assumptions of the documentation to your thinking :-)) before diving
>> into mq.
>
> I'm seeing if I can get the best of both worlds by having a public
> sandbox repo where I work on things (which has the full messy history
> of development on its feature branches), and then just drop them into
> the main repo as coherent patches. Once I land a patch, I'll close the
> original feature branch in the sandbox, so merge conflicts won't be an
> issue.
>
> Mercurial makes merging easy enough that I'm happy with the way that
> approach is working so far.

That's in essence what I was thinking of when I said "You can do
everything that mq provides using core Mercurial
commands", but never having done it myself, I wasn't sure how
straightforward it would feel to someone in Neil's "second school".

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Michael Foord 

On 28/03/2011 11:35, Nick Coghlan wrote:

On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore  wrote:

For people in the "clean history" school, I'd recommend looking at mq
for your personal use. But it's definitely an advanced feature of
Mercurial, so it may be better to understand core Mercurial (and at
least temporarily accept that Mercurial is based on the "keep all
history" school of thought, or you'll struggle to match the
assumptions of the documentation to your thinking :-)) before diving
into mq.

I'm seeing if I can get the best of both worlds by having a public
sandbox repo where I work on things (which has the full messy history
of development on its feature branches), and then just drop them into
the main repo as coherent patches. Once I land a patch, I'll close the
original feature branch in the sandbox, so merge conflicts won't be an
issue.

Mercurial makes merging easy enough that I'm happy with the way that
approach is working so far.


For any non-trivial work I think this is the best approach. You still 
get all the advantages of working with mercurial (able to commit 
frequently) without polluting the history of the core repository.


It has the major advantage of also being very simple to understand.

All the best,

Michael

Cheers,
Nick.




--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

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

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Nick Coghlan 
On Mon, Mar 28, 2011 at 10:48 PM, Michael Foord
 wrote:
> On 28/03/2011 11:35, Nick Coghlan wrote:
>> Mercurial makes merging easy enough that I'm happy with the way that
>> approach is working so far.
>
> For any non-trivial work I think this is the best approach. You still get
> all the advantages of working with mercurial (able to commit frequently)
> without polluting the history of the core repository.
>
> It has the major advantage of also being very simple to understand.

Martin also seems to have worked the kinks out of the Roundup patch
generation, so generating updated patches for people to review in the
tracker is just a matter of clicking a button.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] improvement to declaring abstract properties

2011-03-28 Thread Darren Dale 
On Sat, Mar 19, 2011 at 3:06 PM, Darren Dale  wrote:
> I suggested at python-ideas a way that the declaration of abstract
> properties could be improved to support the decorator syntax:
> http://mail.python.org/pipermail/python-ideas/2011-March/009411.html .
> A relatively small change to the property builtin would allow
> properties to identify themselves as abstract when they are passed
> abstract methods (the same way that function objects identify
> themselves as abstract when decorated with @abstractmethod). As a
> result, @abstractproperty would no longer be needed.
>
>  I submitted a patch at http://bugs.python.org/issue11610. It includes
> the changes to the property builtin, documentation, and unit tests.

This patch has been improved so it only touches abc.abstractproperty.
"make test" yields the same results with and without the patch. As a
result of the review (http://bugs.python.org/review/11610/show), the
documentation was improved to make it clear that the changes are
backward compatible. The reviewer seemed satisfied and provided some
encouraging feedback, but will not be available to guide the patch to
submission. So I am soliciting for another core committer to continue
the review and hopefully apply the changes for python-3.3.

Thanks,
Darren
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7 on Irix 6.5.22 fails ctypes callback test

2011-03-28 Thread Antoine Pitrou 
On Sun, 27 Mar 2011 19:07:08 -0400 (EDT)
"David E. Cross"  wrote:
> Trying to compile and install Python 2.7 on irix 6.5.22 IP22 (N32 ABI 
> model), Using gcc-4.5.1 and binutils 2.20.1.  Everything goes well (I 
> applied th patches listed at: 
> http://bugs.python.org/file15915/python-2.7-irix.patch )
> 
> It compiles and the test mostly work except for the callback ctypes 
> (libffi) test where it segfaults on a pyDECREFF.  Digging in, the O_get 
> call is returning a NULL pointer (and pyDECREF is understandably choking 
> on that).
> 
> Since I am very new to python, I am at a bit of a loss to tracing the C 
> code back through this particulat section of code to see why the PyOBJECT 
> isn't being assigned here.  Any help would be welomed.

One thing you might find useful is to instrument gdb to display more
information about Python objects (the opaque PyObject pointers). See:
http://docs.python.org/devguide/gdb.html

Regards

Antoine.


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

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Barry Warsaw 
On Mar 27, 2011, at 01:39 PM, Neil Schemenauer wrote:

>Barry Warsaw  wrote:
>> I'm asking because I don't know hg and git well enough to answer the
>> question.  In my own use of Bazaar over the last 4+ years, I've almost never
>> rebased or even been asked to.
>
>Maybe it depends on what kind of changes you commit.  I consider
>future maintainers the most important "customer" of the repository
>history.  As such, I try to make each commit a logical change that
>takes a working system and produces another working system.  In that
>way, each change to be potentially reversed if later on if it found
>to cause problems.  Also, ideally, each revision can be tested to
>narrow down the version where a bug was introduced.

I always try to follow TDD, so good commit points for local development
branches are places where you've fixed a broken test and done your refactoring
step.  This means that even for local lines of development, revisions should
produce workable code, although perhaps only localized to the tests being
modified.

>If you are able to directly commit A' and B' and your tool does a
>good job of hiding the logically unimportant merge then I guess you
>wouldn't miss the ability to modify history.

Right.  As Ben Finney has pointed out, Bazaar does a very good job of this, so
it's just not something a typical Bazaar user worries much about.  It's there
if you want it of course, and some projects do, but most don't bother.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().

2011-03-28 Thread Georg Brandl 
On 28.03.2011 09:49, Raymond Hettinger wrote:
> 
> On Mar 28, 2011, at 12:38 AM, Daniel Stutzbach wrote:
> 
>> On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan > > wrote:
>>
>> On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach > > wrote:
>> > Is there a good use-case for the func argument?
>>
>>  
>>
>> The examples that Raymond gives in the docs (cumulative
>> multiplication, running min/max, cash flow accumulation) look fairly
>> solid to me.
>>
>>
>> (I had the nagging suspicion that I was making a blunder in my email, but I
>> couldn't see it despite rereading my email several times before sending.  My
>> blunder was in not rereading the patch to see the examples.  Anyway...)
>>
>> When would a running product, min, or max be useful?
> 
> There's no need to speculate.  This API has long been present in other 
> languages
> and libraries.
> 
> Do a google code search for R's builtin functions cumsum, cumprod, cummin, and
> cummax. Look at mumpy's accumulate ufunc which works with many operators. APL
> and K also have an accumulate tool which takes arbitrary functions.

And incidentally I just could have used it myself yesterday.  So thanks for
adding it! :)

Georg

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

[Python-Dev] Issue Tracker

2011-03-28 Thread Ethan Furman 

Greetings!

I'm not sure where the best place is to ask this question, so I'll start 
here -- feel free to redirect me if necessary.


I would like to have some software to keep track of bugs, to-do's, 
ideas, etc., etc. -- you know, an issue tracker!  Naturally I thought of 
the one we use to track Python.  Is it available?  Is it written in 
Python?  Are there any others that are recommended?


Thanks!

~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue Tracker

2011-03-28 Thread Brian Curtin 
On Mon, Mar 28, 2011 at 15:05, Ethan Furman  wrote:

> Greetings!
>
> I'm not sure where the best place is to ask this question, so I'll start
> here -- feel free to redirect me if necessary.
>
> I would like to have some software to keep track of bugs, to-do's, ideas,
> etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
> use to track Python.  Is it available?  Is it written in Python?  Are there
> any others that are recommended?
>
> Thanks!
>
> ~Ethan~


bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
in Python.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue Tracker

2011-03-28 Thread Antoine Pitrou 
On Mon, 28 Mar 2011 15:14:20 -0500
Brian Curtin  wrote:
> On Mon, Mar 28, 2011 at 15:05, Ethan Furman  wrote:
> 
> > Greetings!
> >
> > I'm not sure where the best place is to ask this question, so I'll start
> > here -- feel free to redirect me if necessary.
> >
> > I would like to have some software to keep track of bugs, to-do's, ideas,
> > etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
> > use to track Python.  Is it available?  Is it written in Python?  Are there
> > any others that are recommended?
> >
> > Thanks!
> >
> > ~Ethan~
> 
> 
> bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
> in Python.

Well, don't take bugs.python.org as an example, though, since AFAIK it
is heavily modified. http://mercurial.selenic.com/bts/ and
http://psf.upfronthosting.co.za/roundup/meta/ look more like vanilla
installs.

Otherwise there's also Trac.

Regards

Antoine.


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

Re: [Python-Dev] Issue Tracker

2011-03-28 Thread Ethan Furman 

Brian Curtin wrote:
On Mon, Mar 28, 2011 at 15:05, Ethan Furman > wrote:


Greetings!

I'm not sure where the best place is to ask this question, so I'll
start here -- feel free to redirect me if necessary.

I would like to have some software to keep track of bugs, to-do's,
ideas, etc., etc. -- you know, an issue tracker!  Naturally I
thought of the one we use to track Python.  Is it available?  Is it
written in Python?  Are there any others that are recommended?

Thanks!

~Ethan~


bugs.python.org  
uses http://pypi.python.org/pypi/roundup, which is written in Python. 


Thank you!  That explains a lot.  (I kept wondering about the occasional 
roundup comment I would see in threads, but hadn't put it together.)


~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue Tracker

2011-03-28 Thread Ethan Furman 

Antoine Pitrou wrote:

On Mon, 28 Mar 2011 15:14:20 -0500
Brian Curtin  wrote:

On Mon, Mar 28, 2011 at 15:05, Ethan Furman  wrote:

I would like to have some software to keep track of bugs, to-do's, ideas,
etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
use to track Python.  Is it available?  Is it written in Python?  Are there
any others that are recommended?


bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
in Python.


Well, don't take bugs.python.org as an example, though, since AFAIK it
is heavily modified. http://mercurial.selenic.com/bts/ and
http://psf.upfronthosting.co.za/roundup/meta/ look more like vanilla
installs.

Otherwise there's also Trac.


Thanks, Antoine!  I'll keep that in mind.

~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Terry Reedy 

On 3/28/2011 6:13 AM, Paul Moore wrote:


This philosophy is essentially what the "mq" extension to Mercurial
tries to capture. In mq, you maintain a series of patches "on top of"
your repository, amending, refining and rebasing them as you wish
until they are ready to commit, at which time you take them off the
patch queue and convert them into final commits in the repository.


From what you write, it seems that mq is actually an unordered patch 
set, not a queue (in the FIFO) sense. (Or do you have to commit and 
remove in FIFO order?) Why the confusing mislabel, if indeed I 
understood correctly?


--
Terry Jan Reedy

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

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Paul Moore 
On 28 March 2011 22:29, Terry Reedy  wrote:
> From what you write, it seems that mq is actually an unordered patch set,
> not a queue (in the FIFO) sense. (Or do you have to commit and remove in
> FIFO order?) Why the confusing mislabel, if indeed I understood correctly?

It's a queue (FIFO). Sorry if my description was misleading - I don't
use mq much myself. (There are ways of reordering patches, but that's
advanced use of an already-advanced feature...)

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().

2011-03-28 Thread Daniel Stutzbach 
On Mon, Mar 28, 2011 at 12:49 AM, Raymond Hettinger <
[email protected]> wrote:

> Do a google code search for R's builtin functions cumsum, cumprod, cummin,
> and cummax. Look at mumpy's accumulate ufunc which works with many
> operators. APL and K also have an accumulate tool which takes arbitrary
> functions.
>

Thanks.  I had not been thinking along numeric lines.  I can see how these
would be useful for working with matrices, vectors, and similar constructs.

-- 
Daniel Stutzbach
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: inter-branch workflow

2011-03-28 Thread Ben Finney 
Michael Foord  writes:

> On 28/03/2011 11:35, Nick Coghlan wrote:
> > I'm seeing if I can get the best of both worlds by having a public
> > sandbox repo where I work on things (which has the full messy
> > history of development on its feature branches), and then just drop
> > them into the main repo as coherent patches. Once I land a patch,
> > I'll close the original feature branch in the sandbox, so merge
> > conflicts won't be an issue.

Yes, using Bazaar I get something similar by nominating one of my
branches (often named “devel”) as the integration branch.

All commit-often work is done on feature branches, with all the warts
exposed. Merges into the integration branch are accompanied by a
high-level commit message summarising the changes of interest to
whomever follows that branch.

Patches upstream, in the cases where upstream is not using Bazaar, are
made from the integration branch with their useful-to-others diff and
commit message.

> For any non-trivial work I think this is the best approach. You still
> get all the advantages of working with mercurial (able to commit
> frequently) without polluting the history of the core repository.
>
> It has the major advantage of also being very simple to understand.

I'm glad others have come to a similar conclusion. Perhaps the Python
developers can encourage the Mercurial developers to make this workflow
more obvious to new users?

-- 
 \  “My interest is in the future, as I am going to spend the rest |
  `\  of my life there.” —Charles F. Kettering |
_o__)  |
Ben Finney

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

Re: [Python-Dev] Issue Tracker

2011-03-28 Thread R. David Murray 
On Mon, 28 Mar 2011 22:31:12 +0200, Antoine Pitrou  wrote:
> On Mon, 28 Mar 2011 15:14:20 -0500
> Brian Curtin  wrote:
> > On Mon, Mar 28, 2011 at 15:05, Ethan Furman  wrote:
> > > I would like to have some software to keep track of bugs, to-do's, ideas,
> > > etc., etc. -- you know, an issue tracker!  Naturally I thought of the one 
> > > we
> > > use to track Python.  Is it available?  Is it written in Python?  Are 
> > > there
> > > any others that are recommended?
> > 
> > bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
> > in Python.
> 
> Well, don't take bugs.python.org as an example, though, since AFAIK it
> is heavily modified. http://mercurial.selenic.com/bts/ and
> http://psf.upfronthosting.co.za/roundup/meta/ look more like vanilla
> installs.

Roundup is wonderfully customizable.  It's not hard to do, either,
(though of course there is a learning curve).  I built an issue
tracker for my business with per-customer queues, consultant logins,
and time tracking in about two days of work starting from vanilla
roundup.

The hardest part is debugging the TAL when you make a mistake, but
even that isn't a whole lot worse than any other templating language.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com