Another option might be to force certain construction paths to use keyword arguments. For example, matrix(4,4,scalar = x+y) matrix(4,4,iterator = x+y) David
On Fri, Jun 19, 2015 at 11:03 AM, Nils Bruin <nbr...@sfu.ca> wrote: > On Friday, June 19, 2015 at 9:10:41 AM UTC-7, Darij Grinberg wrote: >> >> > Unfortunately, this is invited by the design of sage: The "__call__" >> entry >> > on a parent is the main interface to element construction and since >> this is >> > "conversion", all kinds of wild input are allowed. >> >> I think this is the main design mistake here. >> >> > Do we have a default >> > place where a rigid-interfaced element constructor goes? Would >> providing one >> > improve the situation? I suspect not, since that just adds another >> corridor >> > to the maze. >> >> I am used to such constructors being implemented in methods that begin >> with "from_" (such as "from_permutation", "from_scalar", etc.). >> Probably not really standardized, but still better than everything >> heaped together in one method. >> > > But that would be a design that could work, right? Have constructors with > well-defined signatures on the parent and have the generic "__call__" > dispatch over them using heuristics and guessing and whatnot. "matrix" on > top of that would have, in addition, heuristics for constructing the > appropriate parent to dispatch to. > > We'd still need to document better (and more accurately!) what the > heuristics are that the conversions and "matrix" use, and in what > precedence, but then we'd have both: a clean way of generating elements > without any guessing as to what the entries mean *and* a convenience method > that, contrary to the Zen of Python, guesses whenever it can. > > >> > Perhaps sane, but also hardly necessary. One can immediately rewrite >> > >> > matrix(n,m,f) -> matrix(n,m,[f(i,j) for i in range(n) for j in >> range(m)]) >> >> One can, but does one want to? >> > > We need the second one, since using this transformation the other way > around really is less efficient. The interface gets cluttered by supporting > both, is there is a gain by supporting only one. By that argument, I would > say "yes". > > If you're coming from LISP or functional languages, the form matrix(n,m,f) > looks natural and concise. The reality is that in Python, list > comprehensions and iterators/generator expressions are much better > supported. So the second form, or properly using iterators: > > matrix(n,m,(f(i,j) for i in range(n) for j in range(m))) > > would be preferable. Especially because most of the time, the expression > that gets wrapped in "f" is a one-off "lambda" expression. The "lambda" can > be omitted in the generator expression and will execute much more > efficiently (since function calls in python are very expensive). > > That said, I would not advocate actually removing the option to specify > the entries via a callable. I don't think it really gets in the way. I > would not particularly advertise its use, though. > > What is the full Mapping protocol? Is it this? >> https://docs.python.org/2/library/collections.html#collections.Mapping >> The doc doesn't make me much wiser. What Sage types implement this >> protocol, or claim to? > > > Yes, I had trouble finding a proper definition too. The code defining > collections.Mapping helps a little, but it would be nice to see explicitly > listed what constitutes the Mapping protocol. > In practice, you can get Python's view of things by asking > > isinstance(...,collections.Mapping) > > >> Also, I don't think we can assume that elements of a ring don't >> implement some protocol, whatever the protocol is. Free module >> elements, for example, are fairly good at pretending to be vectors >> and/or dictionaries. > > > So... perhaps we should first define behaviour in terms of actual > typechecks and classes we can do on sage types and only rely on behaviour > dependent on protocols once we've found nothing applies. In practice we can > still speed certain common things up by shortcutting when we find that > something really has type "list" or "tuple" (but I guess not subtypes of > those, since for those in principle the sage type information could take > precedence). > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
