trace(x) calling x.trace()

[Jason Grout]

A long time ago, we had a request and vote for making the top-level
trace(x) function call x.trace()---for example, this means that if M is
a matrix, then trace(M) will give the trace of M. The problem is that
the top-level trace() function already does a completely different
thing---it traces execution of code.

So please vote (if you care):

[ ] Change the current trace() to trace_execution(), put in a
deprecation warning for trace() used in this manner (but still let it
function as it used to), and make trace(x) call x.trace() by default.

[ ] Leave things alone and don't do anything.

The first approach is up at
http://trac.sagemath.org/sage_trac/ticket/9704 (my patch), but needs to
be updated because of #13109 and possibly rebased because of code rot.

For the record, I'm +1 on the "Change" option.

Thanks,

Jason

[Andrea Lazzarotto]

+1 for the change for me too. It seems a consistent behaviour like many other functions.

Andrea Lazzarotto

[John Cremona]

On 30 June 2012 19:52, Jason Grout <jason...@creativetrax.com> wrote:
> A long time ago, we had a request and vote for making the top-level trace(x)
> function call x.trace()---for example, this means that if M is a matrix,
> then trace(M) will give the trace of M. The problem is that the top-level
> trace() function already does a completely different thing---it traces
> execution of code.
>
> So please vote (if you care):
>

> [x ] Change the current trace() to trace_execution(), put in a deprecation

> warning for trace() used in this manner (but still let it function as it
> used to), and make trace(x) call x.trace() by default.
>

We want Sage to be easily usable by students doing linear algebra.
Programmers will have no trouble finding out how to trace execution.

John

> [ ] Leave things alone and don't do anything.
>
> The first approach is up at http://trac.sagemath.org/sage_trac/ticket/9704
> (my patch), but needs to be updated because of #13109 and possibly rebased
> because of code rot.
>
> For the record, I'm +1 on the "Change" option.
>
> Thanks,
>
> Jason
>

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

[Robert Bradshaw]

On Sat, Jun 30, 2012 at 11:52 AM, Jason Grout
<jason...@creativetrax.com> wrote:
> A long time ago, we had a request and vote for making the top-level trace(x)
> function call x.trace()---for example, this means that if M is a matrix,
> then trace(M) will give the trace of M.  The problem is that the top-level
> trace() function already does a completely different thing---it traces
> execution of code.
>
> So please vote (if you care):
>

> [X] Change the current trace() to trace_execution(), put in a deprecation

> warning for trace() used in this manner (but still let it function as it
> used to), and make trace(x) call x.trace() by default.
>
> [ ] Leave things alone and don't do anything.

Principle of least surprise, especially for those least capable of
handling surprise (non- and amateur-programmers).

- Robert

[Simon King]

Hi!

On 2012-06-30, Jason Grout <jason...@creativetrax.com> wrote:
> [ ] Change the current trace() to trace_execution(), put in a
> deprecation warning for trace() used in this manner (but still let it
> function as it used to), and make trace(x) call x.trace() by default.
>
> [ ] Leave things alone and don't do anything.

I don't see the problem. As far as I understand, trace(x) in the sense
of "trace execution of code" implies that x is a string (namely some
code). If x is a string then it doesn't have a x.trace attribute. If it
is not a string, then the trace(x) apparently can not be about execution
of code, and thus the only reasonable interpretation of trace(x) is:
"Call x.trace()".

Hence, I suggest (and vote +1) for a third option:

[X] Determine whether x is a string. If it is, then trace(x) traces
execution of code. If it isn't, try to return x.trace().

Best regards,
Simon

[Volker Braun]

On Saturday, June 30, 2012 7:52:07 PM UTC+1, jason wrote:

[X] Change the current trace() to trace_execution()

And provide a link to trace_execution in the trace docstring for those that can't figure it out by tab completion.

[Jason Grout]

On 6/30/12 11:57 PM, Simon King wrote:
> [X] Determine whether x is a string. If it is, then trace(x) traces
> execution of code. If it isn't, try to return x.trace().

First, that is how it will work in the deprecation period. Secondly,
for the long term, my philosophical objection to that is that the
"trace" top-level function is then being used in *completely* different
ways depending on the input. In one, it's a mathematical construct. In
the other, it has absolutely nothing to do with the mathematics or
structure of the object, but instead is purely a low-level programming
tool. This isn't just philosophical, too. It would be extremely
confusing for a new user who accidentally passed in a string. I think
it's much better to throw an error (possibly mentioning
trace_execution). As Robert says, a person really wanting to trace the
code probably will have no problem finding trace_execution (indeed,
probably won't even use trace_execution, as they can use the preparser
and pdb directly).

Thanks,

Jason

[Robert Bradshaw]

On Mon, Jul 2, 2012 at 4:54 AM, Jason Grout <jason...@creativetrax.com> wrote:
> On 6/30/12 11:57 PM, Simon King wrote:
>>
>> [X] Determine whether x is a string. If it is, then trace(x) traces
>> execution of code. If it isn't, try to return x.trace().

That's a clever compromise, but

> First, that is how it will work in the deprecation period. Secondly, for
> the long term, my philosophical objection to that is that the "trace"
> top-level function is then being used in *completely* different ways
> depending on the input. In one, it's a mathematical construct. In the
> other, it has absolutely nothing to do with the mathematics or structure of
> the object, but instead is purely a low-level programming tool.

+1

> This isn't
> just philosophical, too. It would be extremely confusing for a new user who
> accidentally passed in a string. I think it's much better to throw an error
> (possibly mentioning trace_execution). As Robert says, a person really
> wanting to trace the code probably will have no problem finding
> trace_execution (indeed, probably won't even use trace_execution, as they
> can use the preparser and pdb directly).
>
> Thanks,
>
> Jason
>
>