This is now http://trac.sagemath.org/ticket/15036
--
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, s
On 2013-05-15, Simon King wrote:
> Hi Nils,
>
> On 2013-05-15, Simon King wrote:
>> Did you open a ticket for cythoning sage.misc.lazy_format and
>> sage.misc.lazy_string (and perhaps make them *one* thing)?
>
> Since I didn't find a ticket by searching trac, I created a new one: See
> #14585.
I
Hi Nils,
On 2013-05-15, Simon King wrote:
> Did you open a ticket for cythoning sage.misc.lazy_format and
> sage.misc.lazy_string (and perhaps make them *one* thing)?
Since I didn't find a ticket by searching trac, I created a new one: See
#14585.
Best regards,
Simon
--
You received this mess
Hi Nils,
On 2013-05-14, Nils Bruin wrote:
> Cool. Doesn't the coercion framework end up trying all kinds of things
> that may generate errors which get caught? Aren't those also different
> errors that AttributeError? Shouldn't we be using a similar approach?
>
> def LazyError(Error):
> ...
It w
On May 14, 10:01 pm, Simon King wrote:
> Indeed, when I created the AttributeErrorMessage, it was suggested on
> trac to use LazyString instead. It turns out that a special purpose
> cythoned AttributeErrorMessage is faster, but I agree that in the
> general case (when it makes no sense to have a
Hi Nils,
On 2013-05-15, Nils Bruin wrote:
> We already have a tool for delaying string assembly and it indeed
> makes a difference in creating Exception objects:
>
> sage: from sage.misc.lazy_string import lazy_string
> sage: f=lambda op,A,B:"unsupported operand parent(s) for '%s': '%s'
> and '%s
On May 14, 2:52 pm, Nils Bruin wrote:
> On May 14, 2:13 pm, Simon King wrote:
>
> > There is a lazy object specially designed for attribute errors. See
> > sage.structure.misc.AttributeErrorMessage.
We already have a tool for delaying string assembly and it indeed
makes a difference in creating
On May 14, 2:13 pm, Simon King wrote:
> There is a lazy object specially designed for attribute errors. See
> sage.structure.misc.AttributeErrorMessage.
Cool. Doesn't the coercion framework end up trying all kinds of things
that may generate errors which get caught? Aren't those also different
er
Hi Nils,
On 2013-05-14, Nils Bruin wrote:
> I think someone was considering using a "lazy" object as "message"
> that would only materialize to a full string if it's really asked for.
> Did we ever get to that?
There is a lazy object specially designed for attribute errors. See
sage.structure.mi
On May 14, 11:35 am, Volker Braun wrote:
> Don't do that. Exceptions should be short and to the point. And not do any
> string processing. Don't convert passed values to strings unless you don't
> care about performance.
I agree, but it does happen. And as you see, matrix.__repr__ takes the
whole
On Tuesday, May 14, 2013 6:54:38 PM UTC+1, Nils Bruin wrote:
> Not all "repr"s end up on a terminal, though. They can end up in
> exception messages that get caught, processed, and never printed.
Don't do that. Exceptions should be short and to the point. And not do any
string processing. Don'
On May 14, 10:02 am, Volker Braun wrote:
> I have no opinion on whether or not to do that on each _repr_ call. It
> doesn't do anything for me, but I don't see what the point of flooding the
> terminal even faster is.
Not all "repr"s end up on a terminal, though. They can end up in
exception mess
On Tuesday, May 14, 2013 9:39:22 AM UTC-7, Nils Bruin wrote:
> How about just changing this to "(use str(...) to see all entries)",
> where we rely on the intelligence of the user to interpret "..." to
> mean 'whatever access you have to the matrix'.
>
>
In principle a change like that sounds
I have no opinion on whether or not to do that on each _repr_ call. It
doesn't do anything for me, but I don't see what the point of flooding the
terminal even faster is.
But I do think the functionality to dig for a variable name from an object
is useful, and should be kept.
On Tuesday, Ma
Oh, and sage_getvariablename doesn't quite live up to its advertised
API either:
sage: L=["hi"]
sage: _T=L[0]
sage:
sage.misc.sageinspect.sage_getvariablename(L[0],omit_underscore_names=True)
'_T'
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
T
15 matches
Mail list logo
