Guido van Rossum wrote:
> By all means do write up a PEP -- it's hard to generalize from that one
> example.
I'll write a PEP as soon as I get a chance. But the
generalisation is pretty straightforward -- just replicate
that signature for each of the binary operations.
--
Greg
__
Guido van Rossum wrote:
> On 9/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
>> The 3.x compatibility break (however alleviated by 2to3) makes a nice clean
>> cutoff. The numpy that works on Pythons 3.x would essentially be a port from
>> the
>> current numpy. Consequently, we could modify the nump
Robert Kern wrote:
> I invite Greg and Steven and whoever else is interested to discuss ideas for
> the
> PEP on numpy-discussion. I'm skeptical, seeing what currently has been
> suggested, but some more details could easily allay that.
>
> http://projects.scipy.org/mailman/listinfo/numpy-discus
On 9/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> The 3.x compatibility break (however alleviated by 2to3) makes a nice clean
> cutoff. The numpy that works on Pythons 3.x would essentially be a port from
> the
> current numpy. Consequently, we could modify the numpy for Pythons 3.x to
> always
Guido van Rossum wrote:
> On 9/4/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> I still don't see why the standard library needs to be weighed down
>>> with a competitor to numpy. Including a subset of numpy was considered
>>> in the past, but it's hard to decide on
Guido van Rossum wrote:
> What makes 3.0 so special? Additions to the stdlib can be considered
> at any feature release. Frankly, 3.0 is already so loaded with new
> features (and removals) that I'm not sure it's worth pile this onto
> it.
>
I actually wrote 3.x, not 3.0. I agree that it makes
On 9/4/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I still don't see why the standard library needs to be weighed down
> > with a competitor to numpy. Including a subset of numpy was considered
> > in the past, but it's hard to decide on the right subset. In the en
Greg Ewing wrote:
> Martin v. Löwis wrote:
>
>> I think this requires a PEP, and explicit support from the
>> NumPy people.
>>
>
> Someone who knows more about numpy's internals would
> be needed to figure out what the details should be
> like in order to be usable by numpy. But I could wri
Guido van Rossum wrote:
> I still don't see why the standard library needs to be weighed down
> with a competitor to numpy. Including a subset of numpy was considered
> in the past, but it's hard to decide on the right subset. In the end
> it was decided that numpy is too big to become a standard l
By all means do write up a PEP -- it's hard to generalize from that one example.
On 9/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I still don't see why the standard library needs to be weighed down
> > with a competitor to numpy.
>
> The way to get things done efficie
> What I have in mind would be quite small, so it wouldn't
> "weigh down" the stdlib.
If it's a builtin, it certainly would. Every builtin weighs
down the library, as it clutters the global(est) namespace.
> I'm thinking of having a bunch of functions like
>
>add_elementwise(src1, src2, dst,
Nick Coghlan wrote:
> Travis has actually been working on this off-and-on for the last couple
> of years,
Well, yes, but that's concentrating on a different aspect
of things -- the data storage.
My proposal concerns what you can *do* with the data,
independent of the way it's stored. My idea and
Guido van Rossum wrote:
> I still don't see why the standard library needs to be weighed down
> with a competitor to numpy.
The way to get things done efficiently with an interpreted
language is for the language or its libraries to provide
primitives that work on large chunks of data at once, and
Martin v. Löwis wrote:
> I think this requires a PEP, and explicit support from the
> NumPy people.
Someone who knows more about numpy's internals would
be needed to figure out what the details should be
like in order to be usable by numpy. But I could write
a PEP about how what I have in mind wou
Martin v. Löwis wrote:
>> I'd like to see some of the core machinery of numpy moved into the
>> Python stdlib, and numpy refactored so that it builds on that. Then
>> there wouldn't be duplication.
>
> I think this requires a PEP, and explicit support from the NumPy
> people.
Travis has actually
On 9/4/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Concur. Array processing would be a very practical addition to the
> standard library. It's used extensively in engineering, finance, and
> the sciences. It looks like they may find room in the OLPC XO for key
> subsets of NumPy and Matplo
> I'd like to see some of the core machinery of numpy moved
> into the Python stdlib, and numpy refactored so that it
> builds on that. Then there wouldn't be duplication.
I think this requires a PEP, and explicit support from the
NumPy people.
Regards,
Martin
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> But what's the point, given that numpy already exists? Wouldn't you
>> just be redoing the work that numpy has already done?
>>
>
> Sometimes I just want to do something simple like
> adding two vectors together, and it seems unreasonable
> t
Guido van Rossum wrote:
> But what's the point, given that numpy already exists? Wouldn't you
> just be redoing the work that numpy has already done?
Sometimes I just want to do something simple like
adding two vectors together, and it seems unreasonable
to add the whole of numpy as a dependency j
On 9/3/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Speaking of such things, I was thinking the other day
> that it might be useful to have somewhere in the stdlib
> a full set of functions for doing elementwise operations
> and reductions on the built-in array type.
>
> This would make it possible
Ryan Freckleton wrote:
> At one time Guido mentioned adding a built-in product() function to
> cover some of the remaining use cases of the built-in reduce().
Speaking of such things, I was thinking the other day
that it might be useful to have somewhere in the stdlib
a full set of functions for d
Actually, if you use Google code search, you'll find that multiplying
the numbers in a list doesn't have much use at all. After summing
numbers, joining strings is by far the most common usage -- which is
much better done with the str.join() method.
(PS. I rejected the issue; product() was propose
>> At one time Guido mentioned adding a built-in product() function to
>> cover some of the remaining use cases of the built-in reduce().
Martin> What is the use case for product()?
As I recall, there were basically two uses of reduce(), to sum a series or
(less frequently) to take t
> At one time Guido mentioned adding a built-in product() function to
> cover some of the remaining use cases of the built-in reduce().
What is the use case for product()?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Hello,
At one time Guido mentioned adding a built-in product() function to
cover some of the remaining use cases of the built-in reduce(). I
don't know if this function is still wanted or needed, but I've
created an implementation with tests and documentation at
http://bugs.python.org/issue1093 .
25 matches
Mail list logo
