Antoon Pardon wrote:
> On 2006-11-15, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Dustan wrote:
>>
>>> 2. While I haven't taken a good look at NumPy, my intuition tells me it
>>> won't work with complex data types, which wouldn't work for me at all.
>>>
>>> Am I correct on that second one?
>> No. num
On 2006-11-15, Robert Kern <[EMAIL PROTECTED]> wrote:
> Dustan wrote:
>
>> 2. While I haven't taken a good look at NumPy, my intuition tells me it
>> won't work with complex data types, which wouldn't work for me at all.
>>
>> Am I correct on that second one?
>
> No. numpy can make arrays of Pytho
Dustan wrote:
> 2. While I haven't taken a good look at NumPy, my intuition tells me it
> won't work with complex data types, which wouldn't work for me at all.
>
> Am I correct on that second one?
No. numpy can make arrays of Python objects in addition to arrays of double,
unsigned int, etc.
-
George Sakkis wrote:
> Dustan wrote:
>
> > Alright, I can see I'm a bit outvoted here. I tried your suggestions
> > and it worked fine.
> >
> > I'll also try to consider in the future that part of the problem might
> > be lack of information conveyed on my part.
>
> If you insist on one-liners, it
On 12 Nov., 00:14, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> if you care about writing robust code, why not just use a for-loop,
> and the list extend method?
>
>
Because generic solutions using HOFs increase abstraction and reduce()
the amount of code one has to write even when they are outcas
Fredrik Lundh wrote:
> Steve Holden wrote:
[...]
>> I suppose it's only a matter of time before someone wants to define
>> dict.__add__ ...
>
> that's been proposed quite a few times, and always gets stuck when it's
> time to define the exact semantics for dealing with collisions. there
> are
Steve Holden wrote:
> In actual fact when Alex Martelli introduced sum() he intended it to be
> polymorphic over all the container types including strings. The check to
> exclude the string case was added when it was determined that it was
> terribly inefficient to concatenate strings that way.
Paddy wrote:
> Dustan wrote:
>
>> Anyway, I figured out a way to get the builtin
>> function 'sum' to work as I need:
>> sum([[1,2,3],[4,5,6],[7,8,9]], [])
>>
>
> Hah!
> No-one expects sum to be used on anything but numbers.
>
> Except lists as above.
>
> No-one expects sum to be used on anyth
Dustan wrote:
> Fredrik Lundh wrote:
>> Dustan wrote:
[...]
>> Repeat after me:
>>
>> "Not everything has to be a one-liner."
>
> Not everything has to be a one-liner. But readability helps.
>
Indeed. And there is absolutely no conflict between those two statements.
Guido resisted introducing te
Dustan wrote:
> Alright, I can see I'm a bit outvoted here. I tried your suggestions
> and it worked fine.
>
> I'll also try to consider in the future that part of the problem might
> be lack of information conveyed on my part.
>
Well, since such honest and public self-examination is so rarely se
Dustan wrote:
> Alright, I can see I'm a bit outvoted here. I tried your suggestions
> and it worked fine.
>
> I'll also try to consider in the future that part of the problem might
> be lack of information conveyed on my part.
If you insist on one-liners, it can be done without sum(), though it
Alright, I can see I'm a bit outvoted here. I tried your suggestions
and it worked fine.
I'll also try to consider in the future that part of the problem might
be lack of information conveyed on my part.
--
http://mail.python.org/mailman/listinfo/python-list
"Dustan" <[EMAIL PROTECTED]> writes:
> Steven D'Aprano wrote:
> > Repeat after me:
> >
> > "Not everything has to be a one-liner."
>
> Not everything has to be a one-liner. But readability helps.
Indeed. Complex one-liners are rarely as readable as a well-named
function call, implemented with sev
Dustan wrote:
> Anyway, I figured out a way to get the builtin
> function 'sum' to work as I need:
> sum([[1,2,3],[4,5,6],[7,8,9]], [])
>
Hah!
No-one expects sum to be used on anything but numbers.
Except lists as above.
No-one expects sum to be used on anything but numbers, and maybe lists
t
Dustan wrote:
> Robert Kern wrote:
>> Dustan wrote:
>>> Fredrik Lundh wrote:
if you care about writing robust code, why not just use a for-loop,
and the list extend method?
>>> Because I'm embedding this expression in a list comprehension (as I
>>> stated in my original post), and last ti
Fredrik Lundh wrote:
> Dustan wrote:
>
> foo =\
> > [[[1,2,3],[4,5,6],[7,8,9]],
> > [[3,2,1],[6,5,4],[9,8,7]]]
> >
> > Here, foo appears to be a 3-dimensional list - except it's supposed to
> > be 2-dimensional. The inner-list-of-lists is a result of how I'm
> > producing the data, and now I
Robert Kern wrote:
> Dustan wrote:
> > Fredrik Lundh wrote:
>
> >> if you care about writing robust code, why not just use a for-loop,
> >> and the list extend method?
> >
> > Because I'm embedding this expression in a list comprehension (as I
> > stated in my original post), and last time I check
On Sat, 11 Nov 2006 17:42:32 -0800, Dustan wrote:
>> alright, let's try again: why do you need a self-contained reduce
>> replacement that can be embedded inside a list comprehension ?
>>
>>
>
>
foo =\
> [[[1,2,3],[4,5,6],[7,8,9]],
> [[3,2,1],[6,5,4],[9,8,7]]]
>
> Here, foo appears to be
Dustan wrote:
foo =\
> [[[1,2,3],[4,5,6],[7,8,9]],
> [[3,2,1],[6,5,4],[9,8,7]]]
>
> Here, foo appears to be a 3-dimensional list - except it's supposed to
> be 2-dimensional. The inner-list-of-lists is a result of how I'm
> producing the data, and now I want to do a mass-concatenation (or
>
Dustan wrote:
> Fredrik Lundh wrote:
>> if you care about writing robust code, why not just use a for-loop,
>> and the list extend method?
>
> Because I'm embedding this expression in a list comprehension (as I
> stated in my original post), and last time I checked, it's not possible
> to treat a
Fredrik Lundh wrote:
> Dustan wrote:
>
> >> > Because I'm embedding this expression in a list comprehension
> >>
> >> because?
> >
> > Because I thought I would be able to get an answer without revealing
> > the exact details of what I am doing.
>
> alright, let's try again: why do you need a se
Dustan wrote:
>> > Because I'm embedding this expression in a list comprehension
>>
>> because?
>
> Because I thought I would be able to get an answer without revealing
> the exact details of what I am doing.
alright, let's try again: why do you need a self-contained reduce
replacement that ca
Fredrik Lundh wrote:
> Dustan wrote:
>
> > Because I'm embedding this expression in a list comprehension
>
> because?
>
>
Because I thought I would be able to get an answer without revealing
the exact details of what I am doing. I didn't realize that wasn't an
option. I'll try once more to give
Dustan wrote:
> Because I'm embedding this expression in a list comprehension
because?
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> Dustan wrote:
>
> > It's always nice to know there are such good-natured people ready to
> > help on this group.
>
> any special reason why you keep pretending that some random wikipedia
> editor knows more about a future Python release than the people that
> develops Python
Dustan wrote:
> It's always nice to know there are such good-natured people ready to
> help on this group.
any special reason why you keep pretending that some random wikipedia
editor knows more about a future Python release than the people that
develops Python ?
> Anyway, I figured out a way
Dustan wrote:
> According to the following page on Wikipedia:
> http://en.wikipedia.org/wiki/Python_%28programming_language%29#Future_development
> reduce is going to be removed in python 3.0. It talks of an
> accumulation loop; I have no idea what that's supposed to mean. So,
>
>
Fredrik Lundh wrote:
> Dustan wrote:
>
> > What's an accumulation loop, and how would I convert this code so it's
> > compatible with the future 3.0
>
> the release of Python 3.0 is far away, and nobody knows how it's going
> to look. trying to be future-compatible at this time is a major waste
>
Dustan wrote:
> What's an accumulation loop, and how would I convert this code so it's
> compatible with the future 3.0
the release of Python 3.0 is far away, and nobody knows how it's going
to look. trying to be future-compatible at this time is a major waste
of time and (not quite as wastefu
According to the following page on Wikipedia:
http://en.wikipedia.org/wiki/Python_%28programming_language%29#Future_development
reduce is going to be removed in python 3.0. It talks of an
accumulation loop; I have no idea what that's supposed to mean. So,
===
>>> x =\
[
30 matches
Mail list logo
