Re: [Python-Dev] [Python-checkins] svn dead?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 11, 2007, at 9:15 AM, Kristján Valur Jónsson wrote: The SVN repository hasn‘t answered http requests since this morning. Anyone know what is up with that? Known breakage. We're working on it. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRhzx9HEjvBPtnXfVAQJwEQQApPQumTtLJPhlRU9a44dOuRI9DFGMQePD 6Hbsux0HcKvcLpR5QQlsUrKEAyGOt2qDm1YpoWM3uwSN68JnnlAc0iiYUQe1s8/U pRBy18eIhd9mGR2F2k9ZdDX0tqDapyVlc5bDb2jAaWSMwMO0AAUXyz4gtIP7thDW b9vZ18YXnvQ= =9riM -END PGP SIGNATURE- ___ 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] [Python-checkins] svn dead?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 11, 2007, at 10:34 AM, Barry Warsaw wrote: On Apr 11, 2007, at 9:15 AM, Kristján Valur Jónsson wrote: The SVN repository hasn‘t answered http requests since this morning. Anyone know what is up with that? Known breakage. We're working on it. svn.python.org is back online now (both http and https). I'll take this opportunity to mention that we've ordered a new ssl cert for our expired one on https. It hasn't arrived yet, but should within a few days. I'll make another announcement when the new cert is installed. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRhz6fXEjvBPtnXfVAQJKYAQAhtF4kA/5HeEvSZhktR3zAHkCZMjDcs1M sPeaAOOF55Pej0HagUi6haYcxoGeFOiGYq0pVzhu2FnuuUIi5LIOumn65w1s7xci z14OhYquTOMTyY2leyZdIj8eywg9ZMtKPXHS5spCm912/9gyuqYI6X9pkPakSRZ/ 0kD1/DmVvhE= =h93N -END PGP SIGNATURE- ___ 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] svn.python.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 11, 2007, at 11:10 AM, Barry Warsaw wrote: I'll take this opportunity to mention that we've ordered a new ssl cert for our expired one on https. It hasn't arrived yet, but should within a few days. I'll make another announcement when the new cert is installed. The new certificate has been installed. It's good until 2010. Please let me know if you have any problems with it. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRh0jXnEjvBPtnXfVAQKuQwP/QZr/mP6bppUDw4Lz1CoKeWlICTSk0Qg/ g+RdFJFXgpwEwWUPRc8w6Cg7yxQZkpaWzoI1+wQRf10G6sw0JUWzN6A2wgBc0lNy 7W2sFFghjQ55gFqoYIGDs3dhLlKcNHhyhTWPFKTw5cnQ41GV9fVLXVtuMqGzeylg dFGUcXqazdU= =jv2x -END PGP SIGNATURE- ___ 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] RELEASED Python 2.5.1, release candidate 1
Anthony Baxter schrieb: On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.1 (release candidate 1). On the 2.5.1 page http://www.python.org/download/releases/2.5.1/ several things are wrong: - The download link for the AMD64 windows installer is missing; probably http://www.python.org/ftp/python/2.5.1/python-2.5.1c1.amd64.msi - The links in the last section (Files, MD5 checksums, signatures and sizes) are all wrong. Example: http://www.python.org/ftp/python/python-2.5.1c1.amd64.msi/Python-2.5.1c1.tgz Thomas ___ 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] RELEASED Python 2.5.1, release candidate 1
On 4/11/07, Thomas Heller [EMAIL PROTECTED] wrote: On the 2.5.1 page http://www.python.org/download/releases/2.5.1/ several things are wrong: Can someone help fix this? I think Anthony is sleeping right now and generally pretty busy. Thanks, n ___ 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] RELEASED Python 2.5.1, release candidate 1
The title for the highlights page also says Python 2.4 Gustavo On 4/11/07, Thomas Heller [EMAIL PROTECTED] wrote: Anthony Baxter schrieb: On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.1 (release candidate 1). On the 2.5.1 page http://www.python.org/download/releases/2.5.1/ several things are wrong: - The download link for the AMD64 windows installer is missing; probably http://www.python.org/ftp/python/2.5.1/python-2.5.1c1.amd64.msi - The links in the last section (Files, MD5 checksums, signatures and sizes) are all wrong. Example: http://www.python.org/ftp/python/python-2.5.1c1.amd64.msi/Python-2.5.1c1.tgz Thomas ___ 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/gustavotabares%40gmail.com ___ 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] Python 2.5.1c1 pickle problem
When pickling instances of an object derived from dict, the pickle in Python 2.5.1c1 calls the object's __getitem__() method. In contrast, earlier versions of Python incl. 2.5 don't call that method. Below is a minimal example with outputs. Is the difference in behavior an oversight or new feature? I couldn't find anything directly related in the release notes. The difference in behavior breaks some of our code. Thanks! Ralf class user(dict): def __getitem__(self, key): print GETITEM, key if (__name__ == __main__): import sys print sys.version u = user() u[1] = 2 import pickle pickle.dumps(u) print Done. 2.5.1c1 (r251c1:54692, Apr 11 2007, 16:15:52) [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] GETITEM 1 Done. 2.5 (r25:51908, Apr 11 2007, 16:11:19) [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] Done. 2.4.2 (#1, Feb 12 2006, 03:45:41) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] Done. 2.3.4 (#1, Oct 26 2004, 16:45:38) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] Done. 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] Done. No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail ___ 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] PEP 3118: Extended buffer protocol (new version)
On 4/9/07, Travis Oliphant [EMAIL PROTECTED] wrote:
Travis, all this is far better and simpler than previous approaches...
Just a few comments
The bufferinfo structure is::
struct bufferinfo {
void *buf;
Py_ssize_t len;
int readonly;
char *format;
int ndims;
Py_ssize_t *shape;
Py_ssize_t *strides;
Py_ssize_t *suboffsets;
void *internal;
};
1) I assume that 'bufferinfo' structure will be part of public Python
API. In such a case, I think it should be renamed and prefixed.
Something like 'PyBufferInfo' sounds good?
2) I also think 'bufferinfo' could also have an 'itemsize' field
filled if Py_BUF_ITEMSIZE flag is passed. What do you think? Exporters
can possibly fill this field more efficiently than next parsing
'format' string, it can also save consumers from an API call.
3) It does make sense to make 'format' be 'const char *' ?
4) I am not sure about this, but perhaps 'buferingo' should save the
flags passed to 'getbuffer' in a 'flags' field. This can be possibly
needed at 'releasebuffer' call.
typedef struct {
PyObject_HEAD
PyObject *base;
struct bufferinfo view;
int itemsize;
int flags;
} PyMemoryViewObject;
5) If my previous comments go in, so 'PyMemoryViewObject' will not
need 'itemsize' and 'flags' fields (they are in 'bufferinfo'
structure).
6) Perhaps 'view' field can be renamed to 'info'.
int PyObject_SizeFromFormat(char *)
7) Why not 'const char *' here?
int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t *len,
int fortran)
Return a contiguous chunk of memory representing the buffer. If a
copy is made then return 1. If no copy was needed return 0.
8) If a copy was made, What should consumers call to free memory?
If the object is multi-dimensional, then if
fortran is 1, the first dimension of the underlying array will vary
the fastest in the buffer. If fortran is 0, then the last dimension
will vary the fastest (C-style contiguous). If fortran is -1, then it
does not matter and you will get whatever the object decides is more
efficient.
9) What about using a char, like 'c' or 'C', and 'f' or 'F', and 0 or
'a' or 'A' (any) ?
int PyObject_CopyToObject(PyObject *obj, void *buf, Py_ssize_t len,
int fortran)
10) Better name? Perhaps PyObject_CopyBuffer or PyObject_CopyMemory?
int PyObject_SizeFromFormat(char *)
int PyObject_IsContiguous(struct bufferinfo *view, int fortran);
void PyObject_FillContiguousStrides(int *ndims, Py_ssize_t *shape,
int itemsize,
Py_ssize_t *strides, int fortran)
int PyObject_FillBufferInfo(struct bufferinfo *view, void *buf,
Py_ssize_t len,
int readonly, int infoflags)
11) Perhaps the 'PyObject_' prefix is wrong, as those functions does
not operate with Python objects.
Regards,
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
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] PEP 3118: Extended buffer protocol (new version)
Lisandro Dalcin wrote: 4) I am not sure about this, but perhaps 'buferingo' should save the flags passed to 'getbuffer' in a 'flags' field. This can be possibly needed at 'releasebuffer' call. The object isn't necessarily providing all the things that were requested in the flags, so it's going to have to keep its own track of what has been allocated. 11) Perhaps the 'PyObject_' prefix is wrong, as those functions does not operate with Python objects. Yes, PyBuffer_ would be a better prefix for these, I think. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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] PEP 3118: Extended buffer protocol (new version)
From PEP 3118:
A memory-view object is an extended buffer object that
should replace the buffer object in Python 3K.
typedef struct {
PyObject_HEAD
PyObject *base;
struct bufferinfo view;
int itemsize;
int flags;
} PyMemoryViewObject;
If the purpose is to provide Python-level access to an
object via its buffer interface, then keeping a bufferinfo
struct in it is the wrong implementation strategy, since it
implies keeping the base object's memory locked as long as
the view object exists.
That was the mistake made by the original buffer object,
and the solution is not to hold onto the info returned by
the base object's buffer interface, but to make a new
buffer request for each Python-level access.
If that's not the purpose of this object, you need to
explain what its purpose actually is.
Also some of what you say about this object is rather
unclear, e.g. It exports a view using the base object.
I don't know what that is supposed to mean.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[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] PEP 3118: Extended buffer protocol (new version)
Greg Ewing wrote:
From PEP 3118:
A memory-view object is an extended buffer object that
should replace the buffer object in Python 3K.
typedef struct {
PyObject_HEAD
PyObject *base;
struct bufferinfo view;
int itemsize;
int flags;
} PyMemoryViewObject;
If the purpose is to provide Python-level access to an
object via its buffer interface, then keeping a bufferinfo
struct in it is the wrong implementation strategy, since it
implies keeping the base object's memory locked as long as
the view object exists.
Yes, but that was the intention. The MemoryView Object is basically an
N-d array object.
That was the mistake made by the original buffer object,
and the solution is not to hold onto the info returned by
the base object's buffer interface, but to make a new
buffer request for each Python-level access.
I could see this approach also, but if we went this way then the memory
view object should hold slice information so that it can be a sliced
view of a memory area.
Because slicing NumPy array's already does it by holding on to a view, I
guess having an object that doesn't hold on to a view in Python but
re-gets it every time it is needed, would be useful.
In that case:
typedef struct {
PyObject_HEAD
PyObject *base;
int ndims;
PyObject **slices; /* or 3 Py_ssize_t arrays */
int flags;
} PyMemoryViewObject;
would be enough to store, I suppose.
-Travis
___
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] PEP 3118: Extended buffer protocol (new version)
Travis Oliphant wrote: Carl Banks wrote: Travis Oliphant wrote: Py_BUF_READONLY The returned buffer must be readonly and the underlying object should make its memory readonly if that is possible. I don't like the if possible thing. If it makes no guarantees, it pretty much useless over Py_BUF_SIMPLE. O.K. Let's make it raise an error if it can't set it read-only. The thing that bothers me about this whole flags setup is that different flags can do opposite things. Some of the flags RESTRICT the kind of buffers that can be exported (Py_BUF_WRITABLE); other flags EXPAND the kind of buffers that can be exported (Py_BUF_INDIRECT). That is highly confusing and I'm -1 on any proposal that includes both behaviors. (Mutually exclusive sets of flags are a minor exception: they can be thought of as either RESTICTING or EXPANDING, so they could be mixed with either.) I originally suggested a small set of flags that expand the set of allowed buffers. Here's a little Venn diagram of buffers to illustrate what I was thinking: http://www.aerojockey.com/temp/venn.png With no flags, the only buffers allowed to be returned are in the All circle but no others. Add Py_BUF_WRITABLE and now you can export writable buffers as well. Add Py_BUF_STRIDED and the strided circle is opened to you, and so on. My recommendation is, any flag should turn on some circle in the Venn diagram (it could be a circle I didn't draw--shaped arrays, for example--but it should be *some* circle). Py_BUF_FORMAT The consumer will be using the format string information so make sure thatmember is filled correctly. Is the idea to throw an exception if there's some other data format besides b, and this flag isn't set? It seems superfluous otherwise. The idea is that a consumer may not care about the format and the exporter may want to know that to simplify the interface.In other words the flag is a way for the consumer to communicate that it wants format information (or not). I'm -1 on using the flags for this. It's completely out of character compared to the rest of the flags. All other flags are there for the benefit of the consumer; this flag is useless to the consumer. More concretely, all the rest of the flags are there to tell the exporter what kind of buffer they're prepared to accept. This flag, alone, does not do that. Even the benefits to the exporter are dubious. This flag can't reduce code complexity, since all buffer objects have to be prepared to furnish type information. At best, this flag is a rare optimization. In fact, most buffers are going to point format to a constant string, regardless of whether this flag was passed or not: bufinfo-format = b; If the exporter wants to raise an exception if the format is not requested is up to the exporter. That seems like a bad idea. Suppose I have a contiguous numpy array of floats and I want to view it as a sequence of bytes. If the exporter's allowed to raise an exception for this, any consumer that wanted a data-neutral view of the data would still have to pass Py_BUF_FORMAT to guard against this. Wouldn't that be ironic? Py_BUF_SHAPE The consumer can (and might) make use of using the ndims and shape members of the structure so make sure they are filled in correctly.Py_BUF_STRIDES (implies SHAPE) The consumer can (and might) make use of the strides member of the structure (as well as ndims and shape) Is there any reasonable benefit for allowing Py_BUF_SHAPE without Py_BUF_STRIDES? Would the array be C- or Fortran-like? Yes, I could see a consumer not being able to handle simple striding but could handle shape information. Many users of NumPy arrays like to think of the array as an N-d array but want to ignore striding. Ok, but is the indexing row-major or column-major? That has to be decided. Carl Banks ___ 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] Python 2.5.1c1 pickle problem
The pickle issue may be related to revision 53655 fixing a psuedo-bug (it was arguable whether current or prior behavior was most desirable). Will look at this more and will report back. 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
[Python-Dev] Just saying hello
Hi I just got accepted on the google summer of code to work on a project for python. I just wanted to say hello to everyone out there as i know i will end up asking a few questions before the summers over. -- Ryan Kelley NETS - University of Rhode Island Network Security http://www.uri.edu/security http://www.uri.edu/security/sentinel http://www.uri.edu/virus ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
