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
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
> 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
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
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
I'm looking at building a "frozenset" instance as a return value from
a C function, and the C API seems ridiculously clumsy. Maybe I'm
misunderstanding it. Apparently, I need to create a list object, then
pass that to PyFrozenSet_New(), then decref the list object.
Is that correct?
What I'd lik
I guess nobody has tried to create frozenset instances from C code
before. Almost everyone uses set anyway. What are you trying to do?
On 9/4/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I'm looking at building a "frozenset" instance as a return value from
> a C function, and the C API seems ridi
Bill Janssen schrieb:
> I'm looking at building a "frozenset" instance as a return value from
> a C function, and the C API seems ridiculously clumsy. Maybe I'm
> misunderstanding it. Apparently, I need to create a list object, then
> pass that to PyFrozenSet_New(), then decref the list object.
>
Hi,
I was building Python 2.5.1 in Visual Studio 2005 and noticed some
problems with the instructions.
Can someone confirm this and update the readme file in the PCbuild8
directory? I don't yet have access to the repository.
This is what the readme.txt file says to do:
All you need to do is
You can create a frozenset from any iterable using PyFrozenSet_New().
If you don't have an iterable and want to build-up the frozenset one element at
a time, the approach is to create a regular set (or some other mutable
container), add to it, then convert it to a frozenset when you're done:
I'm working on issue 1583946. Nagle pointed out that each DN (the
"subject" and "issuer" fields in a certificate) may have multiple
values for the same attribute name, and I haven't been able to rule
this out yet. X.509 DNs are sets of X.500 attributes, and X.500
attributes may be either single-v
Raymond, thanks for the note.
> You can create a frozenset from any iterable using PyFrozenSet_New().
>
> If you don't have an iterable and want to build-up the frozenset one element
> at a time, the approach is to create a regular set (or some other mutable
> container), add to it, then conver
> But your point is still well taken. How about this one, though:
>
> PyDict_NEW(int) => PySetObject *
> PyDict_ADD(s, value)
>
> ADD would just stick value in the next empty slot (and steal its
> reference).
Sorry, I meant to say
PyFrozenSet_NEW(int) => PySetObject *
PyFro
[Bill Janssen]
>
> How about this one, though:
>
>PyDict_NEW(int) => PySetObject *
>PyDict_ADD(s, value)
>
> ADD would just stick value in the next
> empty slot (and steal its reference).
Dicts, sets and frozenset are implemented as hash tables, not as arrays, so the
above suggestion do
> Can someone confirm this and update the readme file in the PCbuild8
> directory? I don't yet have access to the repository.
Please provide patches instead, and post them on bugs.python.org.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
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
> I'm working on issue 1583946. Nagle pointed out that each DN (the
> "subject" and "issuer" fields in a certificate) may have multiple
> values for the same attribute name, and I haven't been able to rule
> this out yet.
This is indeed common. In particular, DN= and OU= often occur multiple
time
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
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
> 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,
I'm trying to fix a failing unit test in revision 57974. The test in
question claims that math.sqrt(-1) should raise ValueError; the code itself
gives "nan" as a result for that expression. I can modify the test and
therefore have it pass, but I'm not sure if an exception would be more
appropriate.
oh, sorry. I'll do that.
Ty
Martin v. Löwis wrote:
>> Can someone confirm this and update the readme file in the PCbuild8
>> directory? I don't yet have access to the repository.
>
> Please provide patches instead, and post them on bugs.python.org.
>
> Regards,
> Martin
>
>
___
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
Is this on OSX? That test has been failing (because on that platform
sqrt(-1) returns nan instead of raising ValueError) for years -- but
the test is only run when run in verbose mode, which mostly hides the
issue. Have you read the comment for the test?
On 9/4/07, Hasan Diwan <[EMAIL PROTECTED]>
On 04/09/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Is this on OSX? That test has been failing (because on that platform
> sqrt(-1) returns nan instead of raising ValueError) for years -- but
> the test is only run when run in verbose mode, which mostly hides the
> issue. Have you read th
> > X.509 DNs are sets of X.500 attributes, and X.500
> > attributes may be either single-valued or multiple-valued.
>
> Conceptually perhaps (although I doubt that).
I got that from David Chadwick's book at http://sec.cs.kent.ac.uk/x500book/.
``An attribute comprises an attribute type and one o
> Dicts, sets and frozenset are implemented as hash tables, not as arrays,
I see, thanks.
> The location of the "next empty slot" depends on a the key
> associated with the value being added (btw, where is the "key" handled
> in your proposed API?).
What key? It's a set, not a mapping. The val
I think it's better for the test to fail, to indicate that there's an
unresolved problem on the platform.
On 9/4/07, Hasan Diwan <[EMAIL PROTECTED]> wrote:
> On 04/09/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Is this on OSX? That test has been failing (because on that platform
> > sqrt(-
Thanks Martin,
Martin v. Löwis wrote:
>> I've started by looking at the parser portion of the code. However I am
>> not certain this is the best place to start. Since there are so many
>> ports I assume there is a well trodden path to completing this kind of
>> task.
>
> I believe this assum
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
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
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
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
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
> In any case, it certainly sounds to me as if there can be multiple
> instances of AttributeTypeAndValue with the same "type" field in a
> single Name. So I'll represent them as tuples, which will preserve
> the order in which they occur in the certificate, and make the value
> immutable. Applic
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
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
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
>>> X.509 DNs are sets of X.500 attributes, and X.500
>>> attributes may be either single-valued or multiple-valued.
>> Conceptually perhaps (although I doubt that).
>
> I got that from David Chadwick's book at http://sec.cs.kent.ac.uk/x500book/.
>
> ``An attribute comprises an attribute type and
> Here's an example of the new format:
>
> {'issuer': (('countryName', u'US'),
> ('organizationName', u'VeriSign, Inc.'),
> ('organizationalUnitName', u'VeriSign Trust Network'),
> ('organizationalUnitName',
>u'Terms of use at https://www
40 matches
Mail list logo
