On 3/29/12 9:21 AM, Jason Grout wrote:
Hi everyone,
We're working on removing some warts in the interact implementation.
Unfortunately, this involves some changes to how input_box works, as
detailed below. If you care, please comment on these changes. If the
consensus is that these changes are g
On 3/29/12 9:21 AM, Jason Grout wrote:
Make all input_box defaults go through the adapter
==
Current Behavior: If a Sage object is specified as a default value, it
is explicitly used as the default value. The adapter is *not* run on the
default va
> First, a matrix by default uses input_grid, so that's a little different.
So the previous example would be impossible with a matrix, but not
Integers(3)(2)?
> 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 confus
On 3/29/12 11:54 AM, kcrisman wrote:
On Mar 29, 11:49 am, Jason Grout 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(
On Mar 29, 11:49 am, Jason Grout 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))).
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
> 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
