Re: [Python-Dev] Product function patch [issue 1093]
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 just to get that. Currently Python has built-in ways of doing arithmetic, and built-in ways of storing arrays of numbers efficiently, but no built-in way of doing arithmetic on arrays of numbers efficiently. 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. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 > to add the whole of numpy as a dependency just to > get that. ... > > 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. > 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 Matplotlib. They want it both as a teaching resource and to optimize their software suite as a whole. If they're successful, we'll have a lot of young pythoneers expecting this functionality. # Steve ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
> 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 Matplotlib. They want it both as a teaching > resource and to optimize their software suite as a whole. If they're > successful, we'll have a lot of young pythoneers expecting this > functionality. 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 library. Given all the gyrations it has gone through I definitely believe this was the right decision. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 been working on this off-and-on for the last couple of years, including mentoring an SoC project last year. I believe PEP 3118 (the revised buffer protocol) was one of the major outcomes - rather than having yet-another-array-type to copy data to and from in order to use different libraries, the focus moved to permitting better interoperability amongst the array types that already exist. Once we support better interoperability at the data storage level, it will actually become *more* useful to have a simple multi-dimensional array type in the standard library as you could easily pass those objects to functions from more powerful array manipulation libraries as your needs become more complicated. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] frozenset C API?
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 like is something more like PyFrozenSet_NEW(int) => PySetObject * PyFrozenSet_SET_ITEM(s, i, v) Any idea why these aren't part of the API? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
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 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 like is something more like > > PyFrozenSet_NEW(int) => PySetObject * > PyFrozenSet_SET_ITEM(s, i, v) > > Any idea why these aren't part of the API? > > Bill > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
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. > > Is that correct? Almost. It doesn't have to be a list - any iterable object would do. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compiling cpython2.5.1 in VS2005?
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 open the workspace "pcbuild.sln" in VisualStudio
2005, select the platform, select the Debug or Release setting (using
"Solution Configuration" from the "Standard" toolbar"), and build the
solution.
The proper order to build subprojects:
1) pythoncore (this builds the main Python DLL and library files,
python25.{dll, lib} in Release mode)
NOTE: in previous releases, this subproject was
named after the release number, e.g. python20.
2) python (this builds the main Python executable,
python.exe in Release mode)
This is my experience. DEBUG configuration:
When I select 'pythoncore' (right click) from the solution explorer,
select 'project only', select 'build only pythoncore' I get this error
report:
Warning 1 warning C4005: 'Yield' : macro redefinition E:\Program
Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\winbase.h57
Warning 2 warning C4005: 'Yield' : macro redefinition E:\Program
Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\winbase.h57
Error 3 fatal error C1083: Cannot open source file:
'.\getbuildinfo2.c':
No such file or directory c1
It looks like the project dependencies are not kicking in. I assume
this is caused by building the project instead of the solution. So I
did them manually.
First make_versioninfo project:
I select 'make_versioninfo' (right click) from the solution explorer,
select 'project only', select 'build only make_versioninfo'. This succeeds.
Second make_buildinfo project:
I select 'make_buildinfo' (right click) from the solution explorer,
select 'project only', select 'build only make_buildinfo'. This succeeds.
Finally I try to make pythoncore again:
I select 'pythoncore' (right click) from the solution explorer, select
'project only', select 'build only pythoncore'. This succeeds.
Now I build python and it also succeeds.
One last thing I noticed is if there are spaces in the path of the
source files the compilation also fails.
Regards,
Ty
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
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: s = PySet_New(NULL); PySet_Add(s, obj1); PySet_Add(s, obj2); PySet_Add(s, obj3); f = PyFrozenSet_New(s); Py_DECREF(s); That approach is similar to what you do with tuples in pure python. You either build them from an iterable "t = tuple(iterable)" or your build-up a mutable object one element at a time and convert it all at once: s = [] s.append(obj1) s.append(obj2) t = tuple(s) The API you propose doesn't work because sets and frozensets are not indexed like tuples and lists. Accordingly, sets and frozensets have a C API that is more like dictionaries. Since dictionaries are not indexable, they also cannot have an API like the one you propose: PyDict_NEW(int) => PySetObject * PyDict_SET_ITEM(s, index, key, value) If you find all this really annoying and need to fashion a small frozenset with a few known objects, consider using the abstract API: f = PyObject_CallFunction(&PyFrozenSet_Type, "(OOO)", obj1, obj2, obj3); That will roll the whole process up into one line. Hope this was helpful, Raymond --- Bill Janssen <[EMAIL PROTECTED]>Add To Address Book|This is Spam Subject:[Python-Dev] frozenset C API? To:python-dev@python.org 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 like is something more like PyFrozenSet_NEW(int) => PySetObject * PyFrozenSet_SET_ITEM(s, i, v) Any idea why these aren't part of the API? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
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-valued or multiple-valued. I haven't found anything in the X.509 standard that prohibits multiple-valued attributes (yet -- I'm still looking), so I'm working on an alternative to using dicts to represent the set of attributes in the certificate that's returned from ssl.sslsocket.getpeercert(). "frozenset" seems the most appropriate -- it's a non-ordered immutable set of attributes. Could use a tuple, but (1) that implies order, and (2) using set operations on the attribute set would be handy to test for various things, particularly "issubset" and "issuperset". I think frozenset is quite analogous to tuple at this level, and I suggest that a similar set of C construction functions would be a good thing. Bill > 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 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 like is something more like > > > > PyFrozenSet_NEW(int) => PySetObject * > > PyFrozenSet_SET_ITEM(s, i, v) > > > > Any idea why these aren't part of the API? > > > > Bill > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
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 convert it to a frozenset when you're done: > > s = PySet_New(NULL); > PySet_Add(s, obj1); > PySet_Add(s, obj2); > PySet_Add(s, obj3); > f = PyFrozenSet_New(s); > Py_DECREF(s); This is essentially the same thing I mentioned, except using a set instead of a list as the iterable. I'm just a tad annoyed at the fact that I know at set creation time exactly how many elements it's going to have, and this procedure strikes me as a somewhat inefficient way to create that set. Just tickles my "C inefficiency" funnybone a bit :-). > The API you propose doesn't work because sets and frozensets are not > indexed like tuples and lists. Accordingly, sets and frozensets have > a C API that is more like dictionaries. Since dictionaries are not > indexable, they also cannot have an API like the one you propose: > > PyDict_NEW(int) => PySetObject * > PyDict_SET_ITEM(s, index, key, value) Didn't really mean to propose "PyDict_SET_ITEM(s, index, key, value)", should have been PyDict_SET_ITEM(s, index, value) 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). Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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 * PyFrozenSet_ADD(s, value) Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
[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 doesn't make any sense to me. 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?). Consequently, the PyDict_New(int) step would have no way to know where to create the n empty slots (since their location is determined by the hash value of the keys). That is a reason that the tuple/list API differs from the set/frozenet/dict API. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling cpython2.5.1 in VS2005?
> 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 would look from the Python level. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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
times.
> 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). Practically, Name is
Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
valueAttributeValue }
So it's a sequence of sets of key/value pairs. If you want to
have the same type twice, you have two options: either make
multiple RDNs, each single-valued, or make a single RDN,
with multiple kv-pairs.
IIUC, the intention of the multi-valued RDNs is that you have
an entity described by multiple attributes. For example,
relative to O=Foo, neither GN=Bill nor SN=Janssen might correctly
identify a person. So you would create O=Foo,GN=Bill+SN=Janssen.
That's allowed, but not really common - instead, people both
a) use CN as a unique identifier, and b) put separate
attributes for a single object into separate RDNs, as if
[EMAIL PROTECTED] was a subnode in the DIT relative
to CN="Bill Janssen".
> I haven't
> found anything in the X.509 standard that prohibits multiple-valued
> attributes (yet -- I'm still looking), so I'm working on an
> alternative to using dicts to represent the set of attributes in the
> certificate that's returned from ssl.sslsocket.getpeercert().
Conceptually, it should be a list (order *is* relevant). It can
then be debated whether the RDN can be represented as a dictionary;
my understanding is that the intention of RDNs is that the AttributeType
is unique within an RDN (but I may be wrong).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 can be combined in flexible ways. Python provides many such primitives for working with strings -- the string methods, regexps, etc. But it doesn't provide *any* for numbers, and that strikes me as an odd gap in functionality. What I have in mind would be quite small, so it wouldn't "weigh down" the stdlib. You could think of it as an extension to the operator module that turns it into something useful. :-) And, as I said, if it's designed so that numpy can build on it, then it needn't be competing with numpy. > Including a subset of numpy was considered > in the past, but it's hard to decide on the right subset. What I'm thinking of wouldn't be a "subset" of numpy, in the sense that it wouldn't necessarily share any of the numpy API from the Python perspective. All it would provide is the minimum necessary primitives to get the grunt work done. I'm thinking of having a bunch of functions like add_elementwise(src1, src2, dst, start, chunk, stride) where src1, src2 and dst are anything supporting the new buffer protocol. That should be sufficient to support something with a numpy-like API, I think. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 Travis's would complement each other, I think. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
> 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, start, chunk, stride) > > where src1, src2 and dst are anything supporting the > new buffer protocol. That should be sufficient to support > something with a numpy-like API, I think. This sounds like a topic for python-ideas. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Math.sqrt(-1) -- nan or ValueError?
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. I'd be happy for some direction here. Many thanks! -- Cheers, Hasan Diwan <[EMAIL PROTECTED]> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling cpython2.5.1 in VS2005?
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 > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 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 > can be combined in flexible ways. > > Python provides many such primitives for working with > strings -- the string methods, regexps, etc. But it doesn't > provide *any* for numbers, and that strikes me as an odd > gap in functionality. > > What I have in mind would be quite small, so it wouldn't > "weigh down" the stdlib. You could think of it as an > extension to the operator module that turns it into > something useful. :-) > > And, as I said, if it's designed so that numpy can build > on it, then it needn't be competing with numpy. > > > Including a subset of numpy was considered > > in the past, but it's hard to decide on the right subset. > > What I'm thinking of wouldn't be a "subset" of numpy, in > the sense that it wouldn't necessarily share any of the > numpy API from the Python perspective. All it would > provide is the minimum necessary primitives to get the > grunt work done. > > I'm thinking of having a bunch of functions like > >add_elementwise(src1, src2, dst, start, chunk, stride) > > where src1, src2 and dst are anything supporting the > new buffer protocol. That should be sufficient to support > something with a numpy-like API, I think. > > -- > Greg > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Math.sqrt(-1) -- nan or ValueError?
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]> wrote: > 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. I'd be happy for some direction here. Many thanks! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Math.sqrt(-1) -- nan or ValueError?
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 the comment for the test? Indeed, I am on OSX. Yes, I have read the comment for the test. Would the following pseudocode be an acceptable fix for the problem: if sys.platform == 'darwin' and math.sqrt(-1) == nan: return else: try: x = math.sqrt(-1) except ValueError: pass ... or should I just not bother? -- Cheers, Hasan Diwan <[EMAIL PROTECTED]> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> > 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 or more attribute values.''
The question is, how would a multiple-valued attribute be represented
in a certificate Name? I'm presuming it would appear as multiple
attributes with the same "type", but different values.
> Conceptually, it should be a list (order *is* relevant). It can
> then be debated whether the RDN can be represented as a dictionary;
> my understanding is that the intention of RDNs is that the AttributeType
> is unique within an RDN (but I may be wrong).
> Name ::= CHOICE { RDNSequence }
>
> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>
> RelativeDistinguishedName ::=
> SET OF AttributeTypeAndValue
>
> AttributeTypeAndValue ::= SEQUENCE {
> type AttributeType,
> valueAttributeValue }
Order is important in the directory tree, but not (I think) in the DN;
that name is just an unordered set of attributes, because the
hierarchy information has already been lost (the RDN elements cannot
be distinguished from each other using only the internal certificate
information).
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. Applications which need them as sets can create their
own frozensets from that tuple.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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 value is the key. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Math.sqrt(-1) -- nan or ValueError?
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(-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? > > Indeed, I am on OSX. Yes, I have read the comment for the test. Would the > following pseudocode be an acceptable fix for the problem: > if sys.platform == 'darwin' and math.sqrt(-1) == nan: > return > else: > try: > x = math.sqrt(-1) > except ValueError: > pass > ... > or should I just not bother? > -- > Cheers, > > Hasan Diwan < [EMAIL PROTECTED]> -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Porting information
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 assumption is wrong. There are not many ports, only a > handful (or less - Jython, IronPython, PyPy). While Jython and > IronPython may have similar implementation strategies, I would expect > that PyPy took an entirely different approach. > > In any case, there certainly is a step that you apparently failed > to perform as the very first step: set some explicit goals. What > kind of compatibility do you want to achieve in your port, what > other goals would you like to follow? > I thought I'd try and keep my message short so I decided not to go into the explicit objectives. At the most basic it is the ability for developers to run compiled Python as part of the game code. The next step up from that is allowing Python source code to execute and be modified in a 'simple' interactive coding tool: allowing for 'tweaking' code to be implemented outside of the game engine team. Principal constraint: Microsoft support for independent development on the 360 is only provided through the use of their slimmed down .Net compact framework and the XNA Game Studio Express development environment (C# only). This allows Microsoft to implement security within the tool chain and deployment pipeline to sandbox strictly. > IOW, why is IronPython not what you want (it *is* a port of CPython > to C#, in a sense), and why is the C# support in PyPy not good enough > for you? > The impact, to this project, of the reduced API and strict sandboxing in the 360 dev environment is Python implementations like IronPython are not feasible. IronPython uses the reflection capabilities of C# to interpret directly to CLR. Without reflection IronPython simply cannot operate. Unfortunately the 360 API does not include reflection functionality. I had a look into PyPy and concluded that it could produce a result that would operate however I was less certain about integrating it into a development tool chain for the 360. It seems more likely that a 'C#Python' would result in a cleaner development environment - much like the embedded inclusion of Lua scripting in many games software. >> I would prefer to break the task into portions that can be verified >> (tested for correctness) independently or as a stack (one on top of the >> next). That way I can catch errors early and have more confidence in >> what I am creating. > > As I don't know what you want to achieve, it is difficult to tell > you what steps to take. > > I assume your implementation would be similar to CPython in that > it uses the same byte code format. So one path would be to ignore > the compiler at all, and assume that the byte code format is given, > i.e. start with port ceval.c. > > I'm not sure whether you also want to provide the same low-level > API (i.e. whether you want to provide "Embedding and Extending"); > it surely can't be the *same* API, since your's will be C#, whereas > CPython's is, well, C. If you implement ceval.c, you will find > quickly that you need much of the Objects folder, so implementing > the 10 or so most important objects would be the natural starting > point (type, int, string, tuple, dict, frame, code, class, method - > assuming you would target Python 1.5 first, i.e. no bool, cell, > descr, gen, iter, weakref, unicode, object). > >> When I looked through the test suites they all seem to be written in >> Python. Is there a test suite for the core of CPython i.e. before the C >> code can interpret Python code? > > Yes and no. The core Python is tested through compilation - if it > compiles without warnings on the relevant compilers, it is considered > good enough to run the Python test suite. For selected features of > the interpreter, there are specific tests, in particular test_capi. > > The core of CPython (compiler, objects, builtins) is then tested > through Python code. > This seems like a sensible way to start since the test harness needs a Python interpreter. Although it seems counter-intuitive to build the bytecode interpreter so that I can test the bytecode compiler... > Regards, > Martin > > Thanks for the advice Martin. Regards, Ty ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 library. > Given all the gyrations it has gone through I definitely believe this > was the right decision. A competitor to NumPy would be counter-productive, but including a core subset in the standard library that NumPy could be built upon would add valuable functionality to Python out of the box. It was probably the best decision to not include NumPy when it was previously considered, but I think it should be reconsidered for Python 3.x. While defining the right subset to include has it's difficulties, I believe it can be done. What would be a reasonable target size for inclusion in the standard library? # Steve ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 write > a PEP about how what I have in mind would look from > the Python level. > I'm confident that the NumPy developers would support this in principle. If you want help with the PEP, I'm willing to help. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 end > > it was decided that numpy is too big to become a standard library. > > Given all the gyrations it has gone through I definitely believe this > > was the right decision. > A competitor to NumPy would be counter-productive, but including a core > subset in the standard library that NumPy could be built upon would add > valuable functionality to Python out of the box. It was probably the > best decision to not include NumPy when it was previously considered, > but I think it should be reconsidered for Python 3.x. While defining > the right subset to include has it's difficulties, I believe it can be > done. What would be a reasonable target size for inclusion in the > standard library? 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. That said, I would much rather argue with a detailed PEP than with yet another suggestion that we do something. I am already doing enough -- it's up for some other folks to get together and produce a proposal. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 no sense to add anything more to 3.0. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 the right subset. In the end >>> it was decided that numpy is too big to become a standard library. >>> Given all the gyrations it has gone through I definitely believe this >>> was the right decision. >> A competitor to NumPy would be counter-productive, but including a core >> subset in the standard library that NumPy could be built upon would add >> valuable functionality to Python out of the box. It was probably the >> best decision to not include NumPy when it was previously considered, >> but I think it should be reconsidered for Python 3.x. While defining >> the right subset to include has it's difficulties, I believe it can be >> done. What would be a reasonable target size for inclusion in the >> standard library? > > What makes 3.0 so special? Additions to the stdlib can be considered > at any feature release. 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 rely on the stdlib API to build on top of. We couldn't do that for the version targeted to Pythons 2.x because we could only rely on its presence for 2.6+. I don't mind maintaining two versions of numpy, one for Python 2.x and one for 3.x, but I don't care to maintain three. 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-discussion -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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. Applications which need them as sets can create their
> own frozensets from that tuple.
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.verisign.com/rpa (c)06'),
('commonName',
u'VeriSign Class 3 Extended Validation SSL SGC CA')),
'notAfter': 'May 8 23:59:59 2009 GMT',
'notBefore': 'May 9 00:00:00 2007 GMT',
'subject': (('serialNumber', u'2497886'),
('1.3.6.1.4.1.311.60.2.1.3', u'US'),
('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),
('countryName', u'US'),
('postalCode', u'94043'),
('stateOrProvinceName', u'California'),
('localityName', u'Mountain View'),
('streetAddress', u'487 East Middlefield Road'),
('organizationName', u'VeriSign, Inc.'),
('organizationalUnitName', u'Production Security Services'),
('organizationalUnitName',
u'Terms of use at www.verisign.com/rpa (c)06'),
('commonName', u'www.verisign.com')),
'version': 2}
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 > rely on the stdlib API to build on top of. We couldn't do that for the version > targeted to Pythons 2.x because we could only rely on its presence for 2.6+. I > don't mind maintaining two versions of numpy, one for Python 2.x and one for > 3.x, but I don't care to maintain three. I just had a discussion with Glyph "Twisted" Lefkowitz about this. He warns that if every project using Python uses 3.0's incompatibility as an excuse to make their own library/package/project incompatible as well, we will end up with total pandemonium (my paraphrase). I think he has a good point -- we shouldn't be injecting any more instability into the world than absolutely necessary. In any case, the rift is more likely to be between 2.5 and 2.6, since 2.6 will provide backports of most 3.0 features (though without some of the accompanying cleanups, in order to also provide strong backwards compatibility). To be honest, I also doubt the viability of designing and implementing something that would satisfy Greg Ewing's goals *and* be stable enough in the standard library, in under a year. But as I said before, I don't see much point in arguing much further until I see the PEP. I may yet be convinced, but it will have to be a good design and a well-argued proposal. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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-discussion > Accepted, that's probably the best place for this to continue. Greg's suggestion sounds plausible to me, but needs to be fleshed out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
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 numpy for Pythons 3.x to >> always >> rely on the stdlib API to build on top of. We couldn't do that for the >> version >> targeted to Pythons 2.x because we could only rely on its presence for 2.6+. >> I >> don't mind maintaining two versions of numpy, one for Python 2.x and one for >> 3.x, but I don't care to maintain three. > > I just had a discussion with Glyph "Twisted" Lefkowitz about this. He > warns that if every project using Python uses 3.0's incompatibility as > an excuse to make their own library/package/project incompatible as > well, we will end up with total pandemonium (my paraphrase). I think > he has a good point -- we shouldn't be injecting any more instability > into the world than absolutely necessary. I agree. I didn't mean to imply that the 3.x version of numpy would be incompatible to users of it, just that the codebase that implements it will be different, whether it is automatically or manually translated. Of course, if the API is introduced in 3.(x>0), we end up with the same problem I wanted to avoid. Ah well. See you on the flip side of the PEP. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
>>> 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 or more attribute values.'' Ah, ok. But then, the DN is not a *set* of such attributes, but a sequence. > The question is, how would a multiple-valued attribute be represented > in a certificate Name? I'm presuming it would appear as multiple > attributes with the same "type", but different values. Within a single RelativeDistinguishedName, yes. > Order is important in the directory tree, but not (I think) in the DN; > that name is just an unordered set of attributes, because the > hierarchy information has already been lost (the RDN elements cannot > be distinguished from each other using only the internal certificate > information). Hmm. The directory tree only exists through the order in the DN. E.g from http://java.sun.com/products/jndi/tutorial/ldap/models/x500.html "The X.500 namespace is hierarchical. An entry is unambiguously identified by a distinguished name (DN). A distinguished name is the concatenation of selected attributes from each entry, called the relative distinguished name (RDN), in the tree along a path leading from the root down to the named entry." If the RDNs within a DN would not be ordered, you would not get a hierarchical tree, and you could not identify entries unambiguously. > 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. Ok. I think this will still not support multi-valued RDNs properly, but those are uncommon in PKI. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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.verisign.com/rpa (c)06'),
> ('commonName',
>u'VeriSign Class 3 Extended Validation SSL SGC CA')),
Can you please take a look at the attached certificates? How are they
represented? The DNs of these are structurally different, one being
/DC=org/DC=python/CN=foo/CN=bar and the other
/DC=org/DC=python/CN=foo2+CN=bar2
Regards,
Martin
ca1.crt
Description: application/x509-ca-cert
ca2.crt
Description: application/x509-ca-cert
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
