William is right that with Python there is no need to have variable numbers of return variables (for Python functions, I don't mean Magma). In situations like is_isomorphic() we can always return a tuple of 2 values, either (true, i) with i an isomorphism or (false, None). So the calling program can unpack the tuple into 2 values and only look at the second if the first is true. However that breaks code which looks correct if written simply as if E2.is_isomorphic(E2): do something
Still on this specific subthread, I think there must be many situations where as well as David's comment that computing one iso is not much more work than checking if one exists, one can compute *all* isos in not much more time than computing one. In that case I would want to implement E1.isomorphisms_to(E2) [note the "s"!] which returns a possibly empty list of all iso's from E1 to E2. Then E1.is_isomorphic_to(E2) can be *literally* synonymous with E1.isomorphisms_to(E2) thanks to Pythons convention that a list is "true" if and only if not empty (you can see that I have been reading up on Python!). And then E1.isomorphism_to(E2) can return E1.isomorphisms_to(E2)[0] with suitable error-catching if the list was empty. And finally, E1.isomorphisms_to(E1) would return the set of automorphisms of E1. All the above is certainly good for the case of ellitpic curves which have finite automorphsm groups (and almost always of size 2) so the above lists are mainly of length 0 or 2. But maybe elsewhere too? John On 16/01/2008, Justin C. Walker <[EMAIL PROTECTED]> wrote: > > > On Jan 16, 2008, at 10:31 AM, William Stein wrote: > > > > > On Jan 16, 2008 9:26 AM, Robert Bradshaw > > <[EMAIL PROTECTED]> wrote: > >> > >> There is no way in python to detect how many arguments a function > >> result will be assigned to, and I'm not a fan of magma's way of doing > >> it. WIth variable length tuples one has to check the length of a > >> tuple before unpacking it. > > > > I'll just come out and say it -- It's a _terrible_ design in Magma. > > +1. > > I think this is really bad design. Trying to unwind code that relies > on this will be a headache, and we should be considering > maintainability as we go. It's always tough to start tackling a > large code base long after the original developers have moved on, and > this kind of trickery won't help a bit. > > Justin > > -- > Justin C. Walker, Curmudgeon-At-Large > Institute for the Absorption of Federal Funds > -------- > Some people have a mental horizon of radius zero, and > call it their point of view. > -- David Hilbert > -------- > > > > > > -- John Cremona --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
