> To get back to the original issue, this has been the case for many years - I
> guess implemented in http://trac.sagemath.org/ticket/6554 ? See there for
> the original design decision rationale - unless it was even earlier... I
> don't have an opinion on this but people who want sparse matrices
On Friday, February 5, 2016 at 9:43:38 AM UTC-5, Nathann Cohen wrote:
>
> Hello everybody,
>
> I am writing here to share an inconsistency with the behaviour of
> Matrix.plot:
>
> When M is sparse:
> M.plot() shows which entries of M are nonzero.
>
> When M is dense:
> M.plot() show
> Any function that takes **kwargs as argument must:
>> 1) Remove from kwargs all values it understands
>> 2) Forward the remaining content of kwargs to a subfunction
>>
>
> And:
>
> 3) Doctest that an unknown argument raises an error
>
This is already doctested occasional
Dear Nils,
Ddo not doubt that you and I (and everybody else) agrees that the
current behaviour of subs (*) is the desired behaviour.
This discussion is about the obvious cases where **kwargs is wrongly
used, e.g. in Matrix. I saw it happen in many places already. I even
saw this one:
def a_f
On Friday, February 5, 2016 at 12:46:54 PM UTC-8, Nathann Cohen wrote:
>
> > Well, the call syntax for polynomials and symbolic expressions really
> > benefits from arbitrary keywords.
>
> Yeah, I guess there is nothing wrong with
> "an_expression.subs(whatever=4)" returning nothing even though
> Well, the call syntax for polynomials and symbolic expressions really
> benefits from arbitrary keywords.
Yeah, I guess there is nothing wrong with
"an_expression.subs(whatever=4)" returning nothing even though
'whatever' is not a variable appearing in an_expression.
Nathann
--
You received t
On Friday, February 5, 2016 at 10:23:17 AM UTC-8, Nathann Cohen wrote:
>
> > I suppose you meant to add a third rule
> > 3) In any branch where a **kwargs -taking function does not call
> another
> > function it forwards the **kwargs argument to, it must raise an error if
> any
> > unrecog
> In general, though, I think it's worth emphasizing **kwargs incurs a dict
> copy anyway. That means that the difference in cost of calling signatures
> def f(a=optional,**kwargs) versus def f(**kwargs) is not as big as you might
> initially guess. I suspect that the verbosity of the former might
On Friday, February 5, 2016 at 10:20:22 AM UTC-8, Volker Braun wrote:
>
> Passing the keywords down individually also incurs some overhead, plus we
> are talking about fairly small dicts. Its unlikely to be of a performance
> concern IMHO
>
> As Travis noted, Python *always* makes a shallow copy
On Fri, 5 Feb 2016, Nathann Cohen wrote:
I object. It is a *very* simple mistake that has a *very* simple solution:
Any function that takes **kwargs as argument must:
1) Remove from kwargs all values it understands
2) Forward the remaining content of kwargs to a subfunction
Th
> I suppose you meant to add a third rule
> 3) In any branch where a **kwargs -taking function does not call another
> function it forwards the **kwargs argument to, it must raise an error if any
> unrecognized kwargs are left.
I thought about it for a moment, and wondered if there was any
sit
On Friday, February 5, 2016 at 6:47:19 PM UTC+1, Nils Bruin wrote:
>
> Note that this solution comes as a fairly significant penalty: you end up
> copying/modifying the kwargs argument *all the time*.
>
Passing the keywords down individually also incurs some overhead, plus we
are talking about f
>
> I suppose you meant to add a third rule
>
3) In any branch where a **kwargs -taking function does not call
> another function it forwards the **kwargs argument to, it must raise an
> error if any unrecognized kwargs are left.
>
> Note that this solution comes as a fairly significant pena
On Friday, February 5, 2016 at 9:08:45 AM UTC-8, Nathann Cohen wrote:
>
> > Yes, this is a more universal problem in the UI:
>
> I object. It is a *very* simple mistake that has a *very* simple solution:
>
> Any function that takes **kwargs as argument must:
> 1) Remove from kwargs a
On Friday, February 5, 2016 at 6:08:45 PM UTC+1, Nathann Cohen wrote:
>
> Any function that takes **kwargs as argument must:
> 1) Remove from kwargs all values it understands
> 2) Forward the remaining content of kwargs to a subfunction
>
And:
3) Doctest that an unknown arg
On 2016-02-05 18:08, Nathann Cohen wrote:
Yes, this is a more universal problem in the UI:
I object. It is a *very* simple mistake that has a *very* simple solution:
Any function that takes **kwargs as argument must:
1) Remove from kwargs all values it understands
Or just not u
In particular, we cannot consider each function with such a bug to be
'just an instance of a more general problem'. They have to be fixed
one by one, especially when the function involved is perhaps the most
common constructor function new users will call.
There was some talk here of making Sage m
> Yes, this is a more universal problem in the UI:
I object. It is a *very* simple mistake that has a *very* simple solution:
Any function that takes **kwargs as argument must:
1) Remove from kwargs all values it understands
2) Forward the remaining content of kwargs to a subf
On Friday, February 5, 2016 at 6:43:38 AM UTC-8, Nathann Cohen wrote:
>
> Let me add to that:
>
> sage: Matrix(whatever=58)
> []
>
Yes, this is a more universal problem in the UI: it's quite common that
unknown keywords just get pass through, usually because they might be of
use for a
19 matches
Mail list logo
