On Feb 12, 2008 8:33 PM, Andrew Mathas <[EMAIL PROTECTED]> wrote:
> >> As William indicated, import the class and modify locally, and when
> >> stable, maybe copy them over to the partition.py file, and
> >>
> >> If you're adding interesting methods to builtin Sage classes, why
> >> [not] release them for inclusion in Sage?
> >>
> >> [the missing 'not' should have been clear] upload changes to trac:
> >>
> Once I get up an running I'm more than happy to make what I write
> available: One of the nice features of sage/python is that it is
> (potentially) self-documenting which was one of the more painful parts
> of writing in gap (for my newer code I have some shell scripts which do
> something similar but it is not as well thought out as what you have.
Excellent.
> Unless there are good reasons for doing otherwise, rather than adding
> pieces of code to partition.py etc it seems easier for me to just create
> a new package which occasionally adds methods to existing classes.
> This has the advantage that it is clear who is responsible for fixing it if
> there's a bug and also makes it harder for me to introduce bugs into
> existing code. I guess that there are no overhead issues with adding a
> lot of methods to a class, particularly if they are not used often?
That's a perfectly fine style for your own code. However,
code written that way will not be accepted for inclusion in Sage
for several reasons:
1. It is potentially confusing and difficult to read, and likely
to lead to accidental code duplication down the line.
2. There is some runtime overhead.
3. You write this has the "advantage that it is clear who is
responsible for fixing it". It is extremely undesirable for *any*
code to go into Sage for which only one person is responsible
for fixing it. We work extremely hard whenever possible to
(a) not have only one person responsible for any code
in Sage, and
(b) make sure that no single person "owns" any particular code in
Sage (this is related to (a)).
All code that goes into Sage must pass a peer review process
before it gets included in Sage. Thus at least one other person is
going to read through and (presumably) understand the code
you've written before it goes into Sage.
Also, the revision control system for Sage records exactly
who wrote any particular line of code in Sage, who changed it,
etc., and this is easily browseable by everybody; just type
sage: hg_sage.browse()
in any copy of Sage.
I just want to emphasize again the extent to which we try to
avoid having "one person only" code in Sage. That sort of
thinking has been a massive problem for many other free
computer algebra system projects, and we've made a concerted
effort to make sure we head off that problem.
(4) You write "and also makes it harder for me to introduce bugs into
existing code." Technically I see no way that your suggested
approach would make it harder to introduce bugs.
Keep in mind that:
(a) every line you add to Sage will be looked at (as
part of a diff file) by whoever referees your code.
(b) There are over 40,000 lines of input automated tests
that are run regular to ensure that Sage is working.
(c) Every function you add to Sage will have examples
in their documentation that will be used for automated
testing. (Code submissions won't pass the referee
process unless every function has such tests.)
> I do want to try and
> use sage to do a major calculation that gap is unable to complete for
> me. I hope to get this done within the next few months, which means that
> I will have to port at least the basic "specht infrastructure" over to
> sage. I am sure that I will have some initial teething problems in
> finding things in sage and remembering how to program in python, but I
> can consult google and the groups that David mentioned as needed. (Btw,
> you should add "Dive into python" http://www.diveintopython.org/ to your
> list of free reference books on python as it is excellent!)
>
> Thanks for your help so far.
>
> Andrew
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
