I also agree. Mapping explicitly is a lot clearer and Pythonic. Even the
functional languages, with their focus on lists, do mapping explicitly.
On Thu, Sep 24, 2009 at 2:16 PM, William Stein wrote:
>
> On Wed, Sep 23, 2009 at 11:14 PM, Rado wrote:
> >
> > I am not sure if I get a vote, but I w
On Wed, Sep 23, 2009 at 11:14 PM, Rado wrote:
>
> I am not sure if I get a vote, but I wanted to say my opinion as more
> of a Sage user than developer.
>
> Since n() is type conversion of sorts, I would expect it to behave
> similar to python's int() function. Which means just give error if you
I am not sure if I get a vote, but I wanted to say my opinion as more
of a Sage user than developer.
Since n() is type conversion of sorts, I would expect it to behave
similar to python's int() function. Which means just give error if you
pass it a list (to remind you to use map). "explicit is be
>>> The question is, do we want this case to also raise an error, or the
>>> function n() to iterate over the argument when it's iterable?
>>
>> Why is there list comprehension in Python? I am "-1" concerning
>> iteration over the argument.
>
> Would it be pythonic enough to have n(pi/2,pi,2*pi) r
On Wed, Sep 23, 2009 at 8:20 PM, Jason Grout
wrote:
>
> Nils Bruin wrote:
>> On Sep 8, 3:38 am, Jason Grout wrote:
>>> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
>>> three values? That way we could do:
>>>
>>> n(*my_list)
>>>
>>> Note that min, max, and other functions
Nils Bruin wrote:
> On Sep 8, 3:38 am, Jason Grout wrote:
>> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
>> three values? That way we could do:
>>
>> n(*my_list)
>>
>> Note that min, max, and other functions work something like this, in
>> that they accept a variable num
On Sep 23, 2009, at 7:57 PM, Nils Bruin wrote:
> On Sep 8, 3:38 am, Jason Grout wrote:
>> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
>> three values? That way we could do:
>>
>> n(*my_list)
>>
>> Note that min, max, and other functions work something like this, in
>> t
On Sep 8, 3:38 am, Jason Grout wrote:
> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
> three values? That way we could do:
>
> n(*my_list)
>
> Note that min, max, and other functions work something like this, in
> that they accept a variable number of arguments.
They do,
I think it would be great if n() and other functions mapped to a
list. I don't see the downside, but maybe I am missing something.
-Marshall
On Sep 8, 5:38 am, Jason Grout wrote:
> Simon King wrote:
> > Hi Burcin,
>
> > On Sep 8, 11:21 am, Burcin Erocal wrote:
> >> I would call it a bug, a si
On Sep 8, 2009, at 3:38 AM, Jason Grout wrote:
> Simon King wrote:
>> Hi Burcin,
>>
>> On Sep 8, 11:21 am, Burcin Erocal wrote:
>>> I would call it a bug, a side effect of trying to convert the
>>> argument
>>> to a complex number as a last resort.
>>
>> No, it is documented, at least implicit
Simon King wrote:
> Hi Burcin,
>
> On Sep 8, 11:21 am, Burcin Erocal wrote:
>> I would call it a bug, a side effect of trying to convert the argument
>> to a complex number as a last resort.
>
> No, it is documented, at least implicitly. From the doc string of n:
> INPUT:
> - `
Hi Burcin,
On Sep 8, 11:21 am, Burcin Erocal wrote:
> I would call it a bug, a side effect of trying to convert the argument
> to a complex number as a last resort.
No, it is documented, at least implicitly. From the doc string of n:
INPUT:
- ``x`` - an object that has a numeri
Simon King wrote:
> Hi Jason,
>
> On Sep 8, 10:58 am, Jason Grout wrote:
>> This seems really odd to me. I expected to get back n() applied to each
>> element of the list.
>>
>> sage: n([1,2])
>> 1.00 + 2.00*I
>>
>> Does anyone else find this behavior uncomfortable?
>
>
Hi Jason,
On Sep 8, 10:58 am, Jason Grout wrote:
> This seems really odd to me. I expected to get back n() applied to each
> element of the list.
>
> sage: n([1,2])
> 1.00 + 2.00*I
>
> Does anyone else find this behavior uncomfortable?
Not I, at least.
AFAIK, there are
On Tue, 08 Sep 2009 04:58:38 -0500
Jason Grout wrote:
>
> This seems really odd to me. I expected to get back n() applied to
> each element of the list.
>
> sage: n([1,2])
> 1.00 + 2.00*I
>
> Does anyone else find this behavior uncomfortable?
I would call it a bug, a
15 matches
Mail list logo
