On Feb 10, 4:45 am, Martin Albrecht <m...@informatik.uni-bremen.de>
wrote:
Hi Martin,
> > > Think about e.g. the planed break up of gen.pyx into elements that make
> > > sense.
>
> > Sure, but that will happen transparently without any impact to the
> > user's code.
>
> I am pretty sure it will have an impact on user's code because it is supposed
> to clean up the mess that is gen.pyx. Maintaining that interface would defeat
> the purpose of the break up in the first place. On the other hand, maybe
> that's not what Craig and Robert have in mind anwyay.
It is my understanding that the breakup of gen.pyx is purely
logistical, i.e. the file is simply too large and has code that should
live in separate files. AFAIK there are no plans to deprecate
functionality.
> > > Maintaining bug-by-bug backward compatibility will be a nightmare because
> > > the file is pretty messy. I'm sure one can do all kind of weird things
> > > with gen.pyx right now that one shouldn't be able to do. Shall we keep
> > > this functionality for backward compatibility?
>
> > Probably not. But if someone knowingly or unknowingly abuses and
> > interface code will break. Can you give an example of what you mean?
>
> How do we define that someone 'abuses' a class when it is full of weird stuff
> (e.g. stuff to make things faster before proper code was written etc.) That
> kind of stuff has to go because it encourages bad code to be written.
There was a case at SD 12 where Dan Shumow reviewed some Graph theory
patch by Robert Miller. Dan raised the issue that some code that
previously worked was broken and Robert replied that the code Dan
presented worked merely by accident since some of the assumptions in
Robert's code were not fulfilled in Dan's example. That property was
not checked in Robert's code IIRC. Either one of those two can supply
you with all the gory details or if you want me to I can find the
ticket.
I agree with you that such bugs in interfaces need to be fixed, but
that only happens once you have users that are no familiar with the
internals of the code and use it in a way never intended by the author
since the author writes his code in a way it is supposed to be used.
Overall in Sage (as well as any other project) code goes through
phases, i.e. the initial drop which is often shakier than it ought to
be. Then sooner or later other people start to hammer the code and
bugs get shaken out. If we are really lucky someone takes a large
amount of tests and verifies the code against known good third party
implementations. One such example is the graph planarity code where
Jason Grout did throw all graphs below a certain size at the code and
found quite a bunch of problems, in the Sage interface to the external
code as well as the external code itself. Unfortunately this is just
how code matures, i.e. even long standing "internal" testing of some
code by the same group of people will only find so many bugs. Once you
have the "idiot user" [my apologies to the idiot user :)] throw random
things at the interface things break. This has happened so many times
to my non-mathematical as well as mathematical code where I thought
the interface I wrote was idiot proof I no longer claim that such a
thing can be accomplished. But we are getting OT here and I need some
sleep, so I will stop ranting :)
> > I don't mean this in a negative way, I am truly curious :). I know that
> > gen.pyx could certainly use a spring cleaning and that in general as
> > the coverage creeps up we will encounter all kinds of bad code that
> > has been around for a while and no one has touched it. Sage must also
> > be made more consistent and in the process we will have to break some
> > things - this is unavoidable. It would be nice if we had something
> > like a major version jump to clearly indicate the before and after,
> > but it seems that this will be hard to accomplish consistently.
>
> The major version jump is *exactly* what I've been lobbying for since SD12 :)
Yes, I understand your position very well, I just disagree in some of
the finer points :)
> If we can't manage to pull this one off, then at least we should have a
> section in the release notes: this and that behavior was changed and might
> affect your code.
+1 - Minh has been helping out with the release notes and I hope they
have been better and more consistent since then. He certainly can
spell a whole lot better than that idiot who used to write the
notes :p
> Also, if we can we add deprecation warnings (and eventually
> we kill the code if it causes hassles)?
I am not sure if this sentence is done. But I agree that if we
deprecate code we must remove it after some time period. Maybe you
should submit a patch to remove the MPolynomial constructor in Sage
3.3 since it was the first thing we ever deprecated. That way we can
add a section to the release notes about deprecation and removal of
functionality and have it in the default template just like coverage
and all those other sections.
Anyway, we do not fundamentally disagree, just in the details, so a
consensus will be reached at some point.
> Cheers,
> Martin
> --
Cheers,
Michael
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www:http://www.informatik.uni-bremen.de/~malb
> _jab: martinralbre...@jabber.ccc.de
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
