On 3/29/12 11:54 AM, kcrisman wrote:


On Mar 29, 11:49 am, Jason Grout<jason-s...@creativetrax.com>  wrote:
On 3/29/12 10:20 AM, kcrisman wrote:

experience is consistent with the initial experience, at the cost of
some possible developer confusion since the default value isn't really
Integers(3)(2), but rather sage_eval(repr(Integers(3)(2))).

I hope others have some input on this one, which I think is the only
really controversial part.  Given the purpose of interacts, I find it
hard to imagine that a developer would have sent something like the
original example to someone who didn't know what they were doing.
Explicit is better than implicit, right...?  But I could imagine some
problems.  For instance, what if the Sage object didn't have a repr
that was sage_eval-able?  (A common critique of sage vis-a-vis other
systems, IIRC.)

So then how would the user enter it in the input box as a changed input?
   Remember, everything coming from the user is a string (that is usually
sage_eval'd)

Like a matrix.  Someone could submit an input whose string is just
words about it.  Am I unclear?  Sorry.  I'm still wrapping my head
around all this, and my opinion (as someone who uses interacts a lot
without all the advanced features) are not going to be as useful.

I welcome any discussion! I want to push these changes to the cell server (as they also fix some bugs we currently have that are impacting users), but in good faith, I wanted to discuss the backwards-incompatible changes first.

First, a matrix by default uses input_grid, so that's a little different.

Second, you're right that some things don't have a repr that can reconstruct themselves. My point is that in that case, it is confusing for the user, since *they* see the repr in the input box, but when they enter that same repr, the results are different because they aren't constructing the same object.


Are you asking if we will make the change to interact documentation so
that the shortcut:

@interact
def _(n="ABCDE"):
      print n

is the preferred way to deal with string inputs?  Sure, though sometimes
we want to explicitly use input_box to set other options (like the width
of the box).

Naturally.  I just mean that it should be obvious how to avoid all the
horrible things you mention earlier :)

Sure.

Jason


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to